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

On Wednesday 16 February 2011, at 00.33.49, Jens M Andreasen
<jens.andreasen@email-addr-hidden> 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   |
'---------------------------------------------------------------------'
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev