Home |
Search |
Today's Posts |
#1
Posted to rec.audio.pro
|
|||
|
|||
A little brain dead right now, so I need math help.
I know how this stuff works, but I can't figure this out
right now with my vodka mind. I'm using Reaper, and I set the sample rate of the ASIO sound card to 96k. I set the ASIO buffer size to 128 samples. Reaper reports, in the upper right hand corner, what I assume to be the latency, as 2.8ms. So I'm doing all this math and can't arrive at that number myself. What am I missing? I was thinking, ok, 96000 samples takes a second, so divide that by 128 and get the number buffers per second. Ok, that's 750. Then wouldn't the reciprocal be the length of time it takes to empty the buffer? I get .0013. Where id the 2.8ms that Reaper reports come from. Sorry, math is not something that I'm expert at. I know enough to hurt myself. Thanks for any enlightenment. Thanks, Tobiah |
#2
Posted to rec.audio.pro
|
|||
|
|||
A little brain dead right now, so I need math help.
I got 1.3ms also.
Maye there is 1.5 ms latency built on so when you add the 1.3 ms buffers you get 2.8 ms total. What number does it report when you set the buffers to 0? Or 1000? Mark |
#3
Posted to rec.audio.pro
|
|||
|
|||
A little brain dead right now, so I need math help.
Some of the latency may come from causes other than buffering. The computer may spend a little time crunching the numbers too.
Peace, Paul |
#4
Posted to rec.audio.pro
|
|||
|
|||
A little brain dead right now, so I need math help.
Tobiah wrote:
I know how this stuff works, but I can't figure this out right now with my vodka mind. I'm using Reaper, and I set the sample rate of the ASIO sound card to 96k. I set the ASIO buffer size to 128 samples. Reaper reports, in the upper right hand corner, what I assume to be the latency, as 2.8ms. So I'm doing all this math and can't arrive at that number myself. What am I missing? Get Excel up. If you don't have Excel, use graph paper. Set # of samples to 2, 4, 8, 16, 32, 64. Plot the calculated latency vs. # of samples. It's probably a y=mx+b. where you are looking for b and m, y is the latency and x is # of samples. I was thinking, ok, 96000 samples takes a second, so divide that by 128 and get the number buffers per second. Ok, that's 750. Then wouldn't the reciprocal be the length of time it takes to empty the buffer? I get .0013. Where id the 2.8ms that Reaper reports come from. Sorry, math is not something that I'm expert at. I know enough to hurt myself. Thanks for any enlightenment. Thanks, Tobiah -- Les Cargill |
#5
Posted to rec.audio.pro
|
|||
|
|||
A little brain dead right now, so I need math help.
PStamler wrote:
Some of the latency may come from causes other than buffering. The computer may spend a little time crunching the numbers too. Peace, Paul Are there any plugins involved, any processing? -- shut up and play your guitar * HankAlrich.Com HankandShaidriMusic.Com YouTube.Com/WalkinayMusic |
#6
Posted to rec.audio.pro
|
|||
|
|||
A little brain dead right now, so I need math help.
четвртак, 11. децембар 2014. 02.26.14 UTC+1, Tobiah је написао/ла:
I know how this stuff works, but I can't figure this out right now with my vodka mind. I'm using Reaper, and I set the sample rate of the ASIO sound card to 96k. I set the ASIO buffer size to 128 samples. Reaper reports, in the upper right hand corner, what I assume to be the latency, as 2.8ms. So I'm doing all this math and can't arrive at that number myself. What am I missing? I was thinking, ok, 96000 samples takes a second, so divide that by 128 and get the number buffers per second. Ok, that's 750. Then wouldn't the reciprocal be the length of time it takes to empty the buffer? I get .0013. Where id the 2.8ms that Reaper reports come from. Sorry, math is not something that I'm expert at. I know enough to hurt myself. Thanks for any enlightenment. Thanks, Tobiah Latency of OS + Latency of DAW + Latency of (all the ) hardware. |
#7
Posted to rec.audio.pro
|
|||
|
|||
A little brain dead right now, so I need math help.
How many channels are you recording? If you have only one CPU, you can buffer
only one channel at any instant. For two channels and 96k sampling rate, that would be 2.7ms total. QED? |
#8
Posted to rec.audio.pro
|
|||
|
|||
A little brain dead right now, so I need math help.
On 12/10/2014 8:26 PM, Tobiah wrote:
I was thinking, ok, 96000 samples takes a second, so divide that by 128 and get the number buffers per second. Ok, that's 750. Then wouldn't the reciprocal be the length of time it takes to empty the buffer? I get .0013. Where id the 2.8ms that Reaper reports come from. Your arithmetic is OK, but there's more to latency than the size of the sample buffer. I don't know exactly how Reaper works internally, but at some point it measures the actual delay between input and output so that it can properly compensate for that delay (by automatically re-positioning the just-recorded track) when you're doing a punch-in or overdub. The un-accounted-for time has to do with how long it takes the computer to pass the data through the driver. -- "Today's production equipment is IT based and cannot be operated without a passing knowledge of computing, although it seems that it can be operated without a passing knowledge of audio" - John Watkinson Drop by http://mikeriversaudio.wordpress.com now and then |
#9
Posted to rec.audio.pro
|
|||
|
|||
A little brain dead right now, so I need math help.
On 12/10/2014 08:50 PM, hank alrich wrote:
PStamler wrote: Some of the latency may come from causes other than buffering. The computer may spend a little time crunching the numbers too. Peace, Paul Are there any plugins involved, any processing? No, it was actually just a blank project with no tracks. |
#10
Posted to rec.audio.pro
|
|||
|
|||
A little brain dead right now, so I need math help.
On 12/11/2014 03:37 AM, William Sommerwerck wrote:
How many channels are you recording? If you have only one CPU, you can buffer only one channel at any instant. For two channels and 96k sampling rate, that would be 2.7ms total. QED? It's a Quad core machine, but I don't think I agree with you about the buffers. It wouldn't make sense that the latency would be proportional to the channel count. |
#11
Posted to rec.audio.pro
|
|||
|
|||
A little brain dead right now, so I need math help.
"Tobiah" wrote in message ...
On 12/11/2014 03:37 AM, William Sommerwerck wrote: How many channels are you recording? If you have only one CPU, you can buffer only one channel at any instant. For two channels and 96k sampling rate, that would be 2.7ms total. QED? It's a quad core machine, but I don't think I agree with you about the buffers. It wouldn't make sense that the latency would be proportional to the channel count. Why not? A processor can only perform one operation at a time. Wouldn't it take 16 times as long to buffer 32 channels as it would to buffer two? Of course, in a 64-bit OS, you should be able to buffer four 16-bit samples at the same time. But I think I'm basically correct about this. Have you asked the company who wrote the software? |
#12
Posted to rec.audio.pro
|
|||
|
|||
A little brain dead right now, so I need math help.
Why not? A processor can only perform one operation at a time. Wouldn't it take 16 times as long to buffer 32 channels as it would to buffer two? yes 16 channels may take 16 times longer than 1 channel , BUT as long as that the time to move the samples for all N channels is less than 1/44.1 kHz then the machine can move all those samples (and more) in the alloted time. It will usually have time left over to idle around and take a break. The machine does a lot more than just move samples around so it better be able to get it all done. Of course, if you add more and more channels and more and more processing and other tasks to the point where it can't get it all done in 1 / 44.1 kHz, then yes you start to get drop outs etc. Mark |
#13
Posted to rec.audio.pro
|
|||
|
|||
A little brain dead right now, so I need math help.
wrote in message ...
BUT as long as that the time to move the samples for all N channels is less than 1/44.1 kHz [in this case, 1/96kHz]... ...then the machine can move all those samples (and more) in the allotted time. It will usually have time left over to idle around and take a break. And a sip of Mom's Robot Oil. What, then, are the mathematical and practical meanings of "latency"? |
#14
Posted to rec.audio.pro
|
|||
|
|||
A little brain dead right now, so I need math help.
On 12/12/2014 9:18 AM, William Sommerwerck wrote:
What, then, are the mathematical and practical meanings of "latency"? I wrote a full article about that. It's on my web site, and was in an older issue of Recording Magazine. Short answers: 1. If your program reports just plain latency, it's a number you'll never achieve in practice 2. If the program reports input and output latency separately, that's a clue that they understand what they're talking about - but still your actual practical latency will be greater than the sum. 3. The only latency that really matters is the delay between mic/line input and monitor output. It only matters where it matters, and that's when you're recording and you're forced, due to a lack of proper studio hardware, to monitor the source through the computer. This is where people disagree as to how much is too much, or how little is satisfactory. It's one of those "it depends" things. 4. When it comes to punch-ins, any civilized DAW these days will know the input and output delays and put the newly recorded audio in the right place on the time line. Same goes for when you're mixing with plug-ins which add delay of their own. 5. It's easy to measure input to output delay, and then you'll know what it really is. Play around with settings and you can see how much a change in buffer size affects the delay between line/mic input and monitor output. -- "Today's production equipment is IT based and cannot be operated without a passing knowledge of computing, although it seems that it can be operated without a passing knowledge of audio" - John Watkinson Drop by http://mikeriversaudio.wordpress.com now and then |
#15
Posted to rec.audio.pro
|
|||
|
|||
A little brain dead right now, so I need math help.
On 12/12/2014 06:18 AM, William Sommerwerck wrote:
wrote in message ... BUT as long as that the time to move the samples for all N channels is less than 1/44.1 kHz [in this case, 1/96kHz]... Right. One may assert that a single core CPU can only do one thing at once, but it can do a jillion things in a jiffy. The buffer is essentially there for when the CPU gets sidetracked servicing another piece of hardware or something. If the buffer is large enough, the soundcard will be able to feed itself for a bit until the CPU gets around to pumping samples again. As far as I can tell, this buffer size is the largest contributor to I/O latency. But it's a prescriptive setting. I specify how much latency I think I can live with, and if all goes well, the CPU will never be out to lunch when the buffer approaches empty. Adding tracks to the mix does not change the timing of anything. It simply makes the CPU work harder in order to make the deadline of being around when the buffers approach empty. If my CPU is fast enough, many tracks can be handled at once with the same buffer-size/latency (again disregarding other causes of latency). At some point, the CPU will not be able to handle any more tracks with any buffer size when the absolute sample pushing capability has been exceeded. Then, rather than latency increasing, somehow magically distorting time and giving the CPU more time to do it's job, the stream fails and we get breaks in the audio. All to say that increasing channels or tracks does not increase latency. It only increases your chance of overloading your CPU. ...then the machine can move all those samples (and more) in the allotted time. It will usually have time left over to idle around and take a break. And a sip of Mom's Robot Oil. What, then, are the mathematical and practical meanings of "latency"? |
#16
Posted to rec.audio.pro
|
|||
|
|||
A little brain dead right now, so I need math help.
"Tobiah" wrote in message ...
clear explanation snipped Now I (think I) understand. Latency is a worst-case situation, the maximum amount of I/O delay the user will tolerate. It is not a measure of how long it takes to "move things around" under non-stressful conditions. |
#17
Posted to rec.audio.pro
|
|||
|
|||
A little brain dead right now, so I need math help.
On 12/12/2014 08:37 AM, William Sommerwerck wrote:
"Tobiah" wrote in message ... clear explanation snipped Now I (think I) understand. Latency is a worst-case situation, the maximum amount of I/O delay the user will tolerate. It is not a measure of how long it takes to "move things around" under non-stressful conditions. Not worst case; the latency is going to be constant given a particular buffer setting. If I set it so that latency is 10ms, I will never get a faster round trip than that. Normally every sample will take exactly that long to make if from input to output. We want that number to be smaller, and the CPU doesn't have to work any harder (well a tiny bit) when the latency is low. It just means that it might get caught doing something else for a piece of hardware of software that thinks that *it's* cpu attention is absolutely necessary when that short buffer comes to and end. All that is aside from how many effects or channels we use, really. As long as there is enough CPU to process everything at the current sample rate, everything works. If there is not, then a larger buffer/ more latency will only put off the inevitable, and we will eventually hear a break in the sound. |
#18
Posted to rec.audio.pro
|
|||
|
|||
A little brain dead right now, so I need math help.
William Sommerwerck wrote:
"Tobiah" wrote in message ... On 12/11/2014 03:37 AM, William Sommerwerck wrote: How many channels are you recording? If you have only one CPU, you can buffer only one channel at any instant. For two channels and 96k sampling rate, that would be 2.7ms total. QED? It's a quad core machine, but I don't think I agree with you about the buffers. It wouldn't make sense that the latency would be proportional to the channel count. Why not? A processor can only perform one operation at a time. Wouldn't it take 16 times as long to buffer 32 channels as it would to buffer two? You're not compute bound, so no. It'll take 16 times as long somewhere but that will be small potatoes in the larger scheme of things. Of course, in a 64-bit OS, you should be able to buffer four 16-bit samples at the same time. But I think I'm basically correct about this. They'll be blocked into one chunk over USB or Firewire depending on how you configure the buffering. Mo' samples, mo chunk. Have you asked the company who wrote the software? HA! -- Les Cargill |
#19
Posted to rec.audio.pro
|
|||
|
|||
A little brain dead right now, so I need math help.
William Sommerwerck wrote:
wrote in message ... BUT as long as that the time to move the samples for all N channels is less than 1/44.1 kHz [in this case, 1/96kHz]... ...then the machine can move all those samples (and more) in the allotted time. It will usually have time left over to idle around and take a break. And a sip of Mom's Robot Oil. Mmmm. Mom's. What, then, are the mathematical and practical meanings of "latency"? So the machinery on the end of the wire has to assemble samples. It puts them samples in "boxes" of varying size before they go to the "loading dock" to be transmitted via , say USB , to the host computer, which unpacks 'em and stores them, or sends them *back* out USB to the output side. -- Les Cargill |
#20
Posted to rec.audio.pro
|
|||
|
|||
A little brain dead right now, so I need math help.
Of course, in a 64-bit OS, you should be able to buffer four 16-bit
samples at the same time. But I think I'm basically correct about this. It's worth pointing out that a 64-bit CPU/OS does not equate to double the throughput in most operations compared to 32-bit. Depending on how efficient the programmer/compiler, there will be an advantage, but when you talk about shoving samples around, you generally can't just assume that four 16 bit samples will now fit where two used to. The CPU still marches to the clock cycle conductor, and when handling discreet values like samples, particularly when we only really need 32-bit ones, is going to be only marginally faster on a 64-bit machine. Otherwise it would be like saying that we could improve amazon.com's throughput if only they would use larger boxes for everything. Nope, because of the logic necessary to properly deliver the payload, larger boxes would do very little. This is all very rough, and the last time I programmed to the metal was on a Z80, so take it with a grain of salt. Another way of what I'm saying, is that for most applications, a 64 bit anything is going to be only marginally faster than a 32 bit of the same thing. The clock speed is what really moves things along. |
#21
Posted to rec.audio.pro
|
|||
|
|||
A little brain dead right now, so I need math help.
On 12/10/2014 7:15 PM, PStamler wrote:
Some of the latency may come from causes other than buffering. The computer may spend a little time crunching the numbers too. Peace, Paul Yes, I hadn't thought about that much, although Mike made this point abundantly clear. I suppose there are basically buffers everywhere (visualizing Buzz Lightyear). Even devices that claim 'direct monitoring' use the phrase 'Near zero latency' or similar perhaps because they normally still do a AD/DA stage which is certainly not zero latency, or because they account for the speed of the electrons down the wire, but that would be absurd. |
#22
Posted to rec.audio.pro
|
|||
|
|||
A little brain dead right now, so I need math help.
It's a quad core machine, but I don't think I agree with you about the buffers. It wouldn't make sense that the latency would be proportional to the channel count. Why not? A processor can only perform one operation at a time. Wouldn't it take 16 times as long to buffer 32 channels as it would to buffer two? You're not compute bound, so no. It'll take 16 times as long somewhere but that will be small potatoes in the larger scheme of things. This. |
#23
Posted to rec.audio.pro
|
|||
|
|||
A little brain dead right now, so I need math help.
On 12/12/2014 9:13 PM, Tobiah wrote:
I suppose there are basically buffers everywhere (visualizing Buzz Lightyear). Even devices that claim 'direct monitoring' use the phrase 'Near zero latency' or similar perhaps because they normally still do a AD/DA stage which is certainly not zero latency, or because they account for the speed of the electrons down the wire, but that would be absurd. Buffers actually have a purpose other than to cause annoying delays. They store data coming in from the driver until the processor is ready to use it, and provide a place for it to relax if the driver spits out data before it's ready to be used. If the buffers are too small, you lose data. If they're larger than it needs to be, you have more delay in the system than you need. But you do need some delay since data flow isn't continuous. Delay due to A/D and D/A conversion is sometimes buffered, sometimes not. Converters from 10-15 years ago usually had a round trip time of 1.5 to 3 milliseconds. The ones in common use today cut that by a factor of 10 to 20, so "near zero latency" can indeed be pretty close to zero for an interface that has a DSP mixer for monitoring and the input source audio doesn't need to make a trip through the computer in order to get to the monitor output. If your interface connects to the computer via USB, which operates in its own fits and starts, the driver usually includes a buffer right at the USB port in addition to the buffers between the driver and the DAW program. It took them a while to figure that out, so it's a fairly recent addition and not every device includes, or needs it. If it's included, the USB port buffer is usually engaged by default when the driver is installed, and it's usually pretty generous. This is so the manufacturer doesn't get flooded with tech support calls about stuttering and dropouts when the interface is first installed. It takes a novice user a while to discover that there's too much latency, and then when he goes on line to see what to do about it, he gets the advice to make the buffers smaller, but he doesn't know about the USB buffer. Pssssst . . . It's still a bit of a secret. -- "Today's production equipment is IT based and cannot be operated without a passing knowledge of computing, although it seems that it can be operated without a passing knowledge of audio" - John Watkinson Drop by http://mikeriversaudio.wordpress.com now and then |
#24
Posted to rec.audio.pro
|
|||
|
|||
A little brain dead right now, so I need math help.
I wish I'd never said anything.
|
#25
Posted to rec.audio.pro
|
|||
|
|||
A little brain dead right now, so I need math help.
William Sommerwerck wrote:
I wish I'd never said anything. Tough cookie, kiddo, and thanks for speaking up. Seriously. Great blather derived from that, and now I feel all latent. ;-) -- shut up and play your guitar * HankAlrich.Com HankandShaidriMusic.Com YouTube.Com/WalkinayMusic |
#26
Posted to rec.audio.pro
|
|||
|
|||
A little brain dead right now, so I need math help.
"hank alrich" wrote in message ...
William Sommerwerck wrote: I wish I'd never said anything. Tough cookie, kiddo, and thanks for speaking up. Seriously. Great blather derived from that, and now I feel all latent. I just checked the OED, and can't find any definition of "latent" that seems to fit the content. "Latent learning" (learning that has taken place without conscious purpose and that is not manifested until there is a goal to be achieved) seemed closest. |
#27
Posted to rec.audio.pro
|
|||
|
|||
A little brain dead right now, so I need math help.
On 12/14/2014 6:44 AM, William Sommerwerck wrote:
I just checked the OED, and can't find any definition of "latent" that seems to fit the content. "Latent learning" (learning that has taken place without conscious purpose and that is not manifested until there is a goal to be achieved) seemed closest. We have a lot of dumb terms in this business. Latency is one. If you have something to advertise or complain about, you make up or adopt a term for it. I can sort of see "latency" in this context, as it's something that has happened that you don't see the effect of immediately, but after some time (a couple of milliseconds) it comes around to bite you. -- "Today's production equipment is IT based and cannot be operated without a passing knowledge of computing, although it seems that it can be operated without a passing knowledge of audio" - John Watkinson Drop by http://mikeriversaudio.wordpress.com now and then |
#28
Posted to rec.audio.pro
|
|||
|
|||
A little brain dead right now, so I need math help.
William Sommerwerck wrote:
"hank alrich" wrote in message ... William Sommerwerck wrote: I wish I'd never said anything. Tough cookie, kiddo, and thanks for speaking up. Seriously. Great blather derived from that, and now I feel all latent. I just checked the OED, and can't find any definition of "latent" that seems to fit the content. "Latent learning" (learning that has taken place without conscious purpose and that is not manifested until there is a goal to be achieved) seemed closest. Physics has used the term "latent heat". -- Les Cargill |
#29
Posted to rec.audio.pro
|
|||
|
|||
A little brain dead right now, so I need math help.
On 12/14/2014 3:44 AM, William Sommerwerck wrote:
"hank alrich" wrote in message ... William Sommerwerck wrote: I wish I'd never said anything. Tough cookie, kiddo, and thanks for speaking up. Seriously. Great blather derived from that, and now I feel all latent. I just checked the OED, and can't find any definition of "latent" that seems to fit the content. "Latent learning" (learning that has taken place without conscious purpose and that is not manifested until there is a goal to be achieved) seemed closest. I found: the delay between the receipt of a stimulus by a sensory nerve and the response to it. |
Reply |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Forum | |||
Grateful Dead Engineer Owsley Stanley Dead at 76 | Pro Audio | |||
Do the math!!! 44.1 to 48k | Pro Audio | |||
Is Locksmithing as dead as Linux? Or is it as dead as recording studios? | Pro Audio | |||
Is Locksmithing as dead as Linux? Or is it as dead as recording studios? | Pro Audio | |||
Is Locksmithing as dead as Linux? Or is it as dead as recording studios? | Pro Audio |