[LAD] Allocating 96 but reading 16 (multple times)

[David Olofson]

On Wednesday 16 February 2011, at 00.33.49, Jens M Andreasen 
<jens.andreasen at comhem.se> wrote:
[...]
> (blocking) 96 frames at a time - makes sense, yes?
[...]

Theoretically, yes, but 96 is a rather odd value in these circumstances. Most 
drivers will deal only in power-of-two sized buffers, so that would be 64, 128 
or something.

So, looking at the input side, you have to wait for *at least* 96 frames to 
come in before read() can wake up, and as most drivers/sound cards have IRQs 
only for complete DMA buffers, that probably means you wait for something like 
two 64 frame buffers to arrive before you get your first block. This means you 
wake up one "buffer cycle" too late! Obviously, at this point, you're in a 
real hurry to get the output to write(), not to miss the deadline. If you're 
doing full duplex with minimal buffering, you've already missed it, and your 
latency will be shifted to 64 frames higher than intended.

What happens when your code deals with smaller numbers of frames is that 
you're approaching the "one frame at a time" streaming case, which 
automatically results in blocking at the right places (that is, on DMA buffer 
or boundaries), only with a lot of overhead.


-- 
//David Olofson - Consultant, Developer, Artist, Open Source Advocate

.--- Games, examples, libraries, scripting, sound, music, graphics ---.
|   http://consulting.olofson.net          http://olofsonarcade.com   |
'---------------------------------------------------------------------'