On Wednesday 16 February 2011, at 00.33.49, Jens M Andreasen <jens.andreasen(a)comhem.se> wrote: [...] [...] 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 | '---------------------------------------------------------------------'