On 10/9/06, David Brownell <[EMAIL PROTECTED]> wrote: > On Monday 09 October 2006 10:10 am, Christopher "Monty" Montgomery wrote: > > > > > > You have not ** YET ** tried to do it the way that's known to work, > > > so it's no surprise you've been seeing the failures which lead to > > > the requirement to use double buffering. > > > > Uh... I've been trying to use the existing drivers for about 5 years. > > Never worked. > > Never tried to do it the right way either, it seems, so that's not > in the least surprising. You're seeing two classes of problems:
Well, I'm 'just using ALSA'. Set the fragment size low, zero watermark and off we go. If alsa (well, usbaudio) is DTRT, that's naught to do with me. Well, it was before. > Both are fixable, but they're at different levels of the system. Right, there's work to be done at several levels, starting at the foundations, where we're arguing no. No debate there. > Do you even understand what I mean when I talk about IRQ latency? I'll point out that I did ask for an explanation. Unless SF lost that mail. > It's > orthogonal to how deep your (double) buffering is. Adding deeper buffers > can't possibly give you IRQ latency guarantees. I doo see that there are more latencies than just the buffers. But I do need a more thorough explanation as to how exactly the IRQ latencies will play out. > To repeat for at least the third time, this is how it works: if > system IRQ latency is 2 msec, then you need at least 2msec data queued > AT ALL TIMES to make sure you don't get drop-outs. You get that by > double-buffering ... each buffer is 2 msec, so that when one of them > completes, the other can empty without causing dropouts. If you ever > get to the point where nothing is queued, you get drop-outs. Simple. OK. So our minimum IRQ latency is... 1msec, but that's pushing it. Correct so far? I imagine there's much more to it than that ;-) If the irq latency is 1msec and the buffers are 1msec x 2, the buffering is 2msec deep. So, pressure wave enters microphone -> samples in a buffer handed back to application is on the order of 2 msec. We then process these samples and send them for playback, where there's another 2msec (of buffer) before they are sent to an amplifier to be turned back into sound. That's 4msec. IRQ latencies affect that, of course, but mostly in the sense of 'will/won't work'. Monty ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
