>>On Monday 09 October 2006 9:44 am, [EMAIL PROTECTED] wrote: >> > On 10/9/06, David Brownell <[EMAIL PROTECTED]> wrote: >> > > On Monday 09 October 2006 9:11 am, [EMAIL PROTECTED] wrote: >> > > > FWIW, if we really could get 5ms latency with a 4ms buffering >> > > > requirement, that counts as 'good enough for now' and probably >>'good >> > > > enough for the forseeable future'. >> > > >> > > 5 ms latency and 4 ms buffering means 1 ms dropout, yes? >> > > >> > > If you want 4 ms buffering, try breaking it into two URBs. >> > >> > Will we actually acheive that 1ms? >> >>Come on, do the very simple math there. IRQ latency == 5 msec, >>but only 4 msec queued. 5 - 4 = 1. This is not string theory. >> >>That obviously means that when you get the max IRQ latency, you >>are guaranteed to have 1 msec of dropout. And you're likely to >>start getting it before that max latency too, given other isues. >> >>And to be excessively clear here, that 1 ms dropout is a bad >>thing, and entirely attributable to insufficient, and single, >>buffering ... that is, to bugs in the driver providing those >>URBs. >>
And another fly in the ointment. The sample rate being used may affect the possible latency. I spent a few minutes looking at the sound driver for usb, and I got lost in strides and urb lengths. However, I know that the older Philips audio devices only supported 44100, 22050, 11025 audio rates. You will notice that these are not evenly divisible by 1000 as in the 1ms full speed frame rate. This means that to play at these rates, N frames of size "NS" need to be sent and then 1 frame of size "NS"+1. For example, audio played at 44100 hz will send 9 frames of 44 samples (times samplesize!) and then one frame of 45 samples. 22050 hz will send 19 frames of 22 samples and 1 frame of 23 samples. 11025 hz will send 39 frames of 11 samples and 1 frame of 12 samples. If audio is not sent at the proper rate the music will be off-pitch, and some audio chips would actually hang if they could not handle the rate. So unless you are playing audio at some even sample rate, say 48,000 HZ, being able to change stuff at a 2ms boundary will trigger artifacts with the samples too. To me 2ms seems awfully fast for required audio response. On the other hand, if we are handling 44100 HZ playback we must be able to handle urbs that are only 10ms long because that is the only way to get one "funny" packet out of a set of 10 audio packets. (And I could not figure out how the sound/isoc urb handler did even this). Regards, Steve ------------------------------------------------------------------------- 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
