3 ms·

> Since the one coming from the hardware is completely fictitious Why do you say this? The USB audio card (or similar) is generating blocks of audio at a fixed

by FigBug 11y ago

> Since the one coming from the hardware is completely fictitious Why do you say this? The USB audio card (or similar) is generating blocks of audio at a fixed rate, no? Maybe for video playback or games you need to synchronize audio and video, but there is no need to do that for music production apps. If you are writing some sort of synth, as soon as you receive a midi note or a tap, trigger the synth and the note will play in the next audio block. No need to wait for the GUI to update. If you are doing some sort of effect, grab the input data, process and have it ready for the next block out. I don't understand why you need a second loop.

jblow 11y ago
Well, it depends on how that specific hardware is designed, but we could say that hardware that is designed to generate only fixed blocks of audio is very poor from a latency perspective. I think you will find, though, that most hardware isn't this way, and to the extent this problem exists, it is usually an API or driver model problem. If you're talking about a sound card for a PC, probably it is filling a ring buffer and it's the operating system (or application)'s job to DMA the samples before the ring buffer fills up, but how many samples is dependent upon when you do the transfer. But the hardware side of things is not something I know much about. > If you are writing some sort of synth, as soon as you receive a midi note or a tap, trigger the synth and the note will play in the next audio block Yeah, and waiting for "the next audio block" to start is additional latency that you shouldn't have to suffer. > If you are doing some sort of effect, grab the input data, process and have it ready for the next block out. I don't understand why you need a second loop. The block of audio data you are postulating is the result of one of the loops: the loop in the audio driver that fills the block and then issues the block to user level when the block is full. My whole point is you almost never want to do it that way.
- FigBug 11y ago
  Can you recommend some good code / APIs to check out that don't do it block based? I usually use JUCE which is block based, and I assumed it was just a thin wrapper around the OS APIs which we also block based.

by FigBug 11y ago

jblow 11y ago

Well, it depends on how that specific hardware is designed, but we could say that hardware that is designed to generate only fixed blocks of audio is very poor from a latency perspective. I think you will find, though, that most hardware isn't this way, and to the extent this problem exists, it is usually an API or driver model problem. If you're talking about a sound card for a PC, probably it is filling a ring buffer and it's the operating system (or application)'s job to DMA the samples before the ring buffer fills up, but how many samples is dependent upon when you do the transfer. But the hardware side of things is not something I know much about. > If you are writing some sort of synth, as soon as you receive a midi note or a tap, trigger the synth and the note will play in the next audio block Yeah, and waiting for "the next audio block" to start is additional latency that you shouldn't have to suffer. > If you are doing some sort of effect, grab the input data, process and have it ready for the next block out. I don't understand why you need a second loop. The block of audio data you are postulating is the result of one of the loops: the loop in the audio driver that fills the block and then issues the block to user level when the block is full. My whole point is you almost never want to do it that way.

FigBug 11y ago
Can you recommend some good code / APIs to check out that don't do it block based? I usually use JUCE which is block based, and I assumed it was just a thin wrapper around the OS APIs which we also block based.