On 10/7/06, David Brownell <[EMAIL PROTECTED]> wrote: > NOTE: I updated $SUBJECT to be accurate.
yes, thank you. > A quick search of email that I exchanged with you on this topic only > includes the following, from 4-June-2006: > > >>> The EL2NSYNC will happen on occasion, e.g. "fell behind" by having the > >>> stream's transfer queue get empty in such a way (long irq latency, > >>> insufficient iso urbs queued, etc) that some of the slots didn't have > >>> a transfer ready (in the iso schedule). Not that I entirely trust that > >>> modulo arithmetic there, but I've seen those failures when testing. > > That doesn't come across to me as a "different conclusion" at all... You say 'fell behind', I say 'xrun'... Did I come away with the wrong interpretation? > What would the upper layer do with that information though? Your > patch just ignored it. So I don't see the point of reporting it... It ignored it only in that specific case; because it was in snd_pcm_prepare, we knew no transfer we cared about was going on, and as such, ignoring it was entirely correct. We *do* care about any missed slots or xruns once the stream is flowing. We care very much. Right now, usbaudio is demonstrably deaf to any xruns so long as its own buffers didn't empty. > One indication is clearly that urb->start_frame would hiccup. But > I don't think the audio drivers track that... Alan mentioned that too I think. Is that a useful path for immediate notification at submission, or would it only relay at completion? The problem with relaying at completion is adding unnecessary latency to the report... "oh by the way, an underrun happened at some point a few packets ago..." as opposed to "there is a gap happening right now" (which is what EL2NSYNC gave us). > If ALSA needs such an indication, your patch didn't add one ... ALSA > would never have seen any XRUN indication in the first place. I didn't mean to suggest that the patchset was a completed work. There's no rebalancer, I've not really inspected several annoying usbaudio bugs, etc. > How deep was the I/O queue that ALSA feeds? My rule of thumb for max > IRQ latency of N msec has always been to queue 2*N msec of URBs. What do I have or what do I want? I *want* 2-5ms from sample to playback. MacOSX can do it. Windows can do it. We can't, at least not yet. Of course, that depends on application; I'm talking about the low end of the envelope. I'm normally running with about 32ms of measured latency right now. XMMS could be a full second without caring... Or did I misunderstand the question? > If it has to happen then, the notification has to be an error return > such as EL2NSYNC, which will also indicate "didn't queue the URB". > You would then need some kind of URB submission flag to override > such reports so the schedule slot isn't abandoned, right? I like the EL2NSYNC approach, obviously. I thought there had been objection to it and a desire to use something else (ie, that there is already a preestablished convention). 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
