4 ms·

It DOES mean there is 100ms of latency. Anything above 10ms (some say max. 20ms) for real-time audio processing (especially musical instruments) is prohibitive

by scoutt 6y ago

It DOES mean there is 100ms of latency. Anything above 10ms (some say max. 20ms) for real-time audio processing (especially musical instruments) is prohibitive. Imagine an electronic drum set: if you hit the snare and the audio is output 100ms later from the speakers, I bet you'll notice it :)

deleted 6y ago
[deleted]
ubercow13 6y ago
Ah but GP wasn't talking about real-time in that context ("And if you're not..."). You can still have 100ms buffer without 100ms latency: within 10ms of the drum being hit, write 100ms of the drum sample into the playback buffer and immediately trigger its playback (or write it into the buffer starting at the cursor position that is just about to be played). The only trouble is when you need to modify some of that 100ms before it is played back, for example if the user hits another drum 50ms later. In that case it becomes more complex, you'd have to overwrite some of the existing buffer with a new mix of both drum samples. The complexity is not worth it for that kind of app. For a simple app like a video player, the audio stream is much more predictable so you can buffer more. Volume changes and pausing can still be applied with no perceivable latency by modifying the existing buffered data [1] [1] https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/Developer/Rewinding/ https://www.freedesktop.org/wiki/Software/PulseAudio/Documen...
- scoutt 6y ago
  > within 10ms of the drum being hit, write 100ms of the drum sample into the playback buffer You can do that if you can predict the future and fill the buffer with data you don't know (samples from the future). Otherwise, you still have to wait for 100ms of samples to output. So if you have to wait 100ms for the samples, then the output happens after 100ms, hence 100ms of latency. 100ms samples can be fine for a video player. For real-time you (usually) do this: 2 buffers of 10ms each. While one buffer is playing, you fill another buffer with real-time data. After 10ms has passed, you start playing the buffer with real-time data, while the other buffer gets filled.
  - deleted 6y ago
    [deleted]
  - ubercow13 6y ago
    The point is that in a video player, you can predict the future: the video will continue playing. > Otherwise, you still have to wait for 100ms of samples to output No, you don’t, not if you can write into the buffer at an arbitrary point. This is what the whole page I linked is about.

by scoutt 6y ago

deleted 6y ago

[deleted]

ubercow13 6y ago

Ah but GP wasn't talking about real-time in that context ("And if you're not..."). You can still have 100ms buffer without 100ms latency: within 10ms of the drum being hit, write 100ms of the drum sample into the playback buffer and immediately trigger its playback (or write it into the buffer starting at the cursor position that is just about to be played). The only trouble is when you need to modify some of that 100ms before it is played back, for example if the user hits another drum 50ms later. In that case it becomes more complex, you'd have to overwrite some of the existing buffer with a new mix of both drum samples. The complexity is not worth it for that kind of app. For a simple app like a video player, the audio stream is much more predictable so you can buffer more. Volume changes and pausing can still be applied with no perceivable latency by modifying the existing buffered data [1] [1] https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/Developer/Rewinding/ https://www.freedesktop.org/wiki/Software/PulseAudio/Documen...

scoutt 6y ago
> within 10ms of the drum being hit, write 100ms of the drum sample into the playback buffer You can do that if you can predict the future and fill the buffer with data you don't know (samples from the future). Otherwise, you still have to wait for 100ms of samples to output. So if you have to wait 100ms for the samples, then the output happens after 100ms, hence 100ms of latency. 100ms samples can be fine for a video player. For real-time you (usually) do this: 2 buffers of 10ms each. While one buffer is playing, you fill another buffer with real-time data. After 10ms has passed, you start playing the buffer with real-time data, while the other buffer gets filled.
- deleted 6y ago
  [deleted]
- ubercow13 6y ago
  The point is that in a video player, you can predict the future: the video will continue playing. > Otherwise, you still have to wait for 100ms of samples to output No, you don’t, not if you can write into the buffer at an arbitrary point. This is what the whole page I linked is about.