Re: BUG: USB audio discontinuities with 'UHCI: implement new semantics for URB_ISO_ASAP'
On Wed, 8 May 2013, Joe Rayhawk wrote: For what it's worth, the following -stable patch ALSA: USB: adjust for changed 3.8 USB API c75c5ab575af7db707689cdbb5a5c458e9a034bb fixes the discontinuous playback on period sizes between 139 and 192, but the discontinuous playback on period sizes between 48 and 138 has been replaced by rather worse kernel blocking and kernel errors: jrayhawk@richardiv:~$ sudo tail -F -n 0 /var/log/kern.log [1] 4490 jrayhawk@richardiv:~$ time perl -e 'print pack H*, 00FF x 2048' | aplay --period-size=192 -r 48000 -f S16_LE -c2 -D hw:0,0 Playing raw data 'stdin' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo real 0m0.053s user 0m0.008s sys 0m0.000s jrayhawk@richardiv:~$ time perl -e 'print pack H*, 00FF x 2048' | aplay --period-size=48 -r 48000 -f S16_LE -c2 -D hw:0,0 Playing raw data 'stdin' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo May 8 17:01:56 richardiv kernel: [ 1680.923474] cannot submit urb (err = -18) May 8 17:01:56 richardiv kernel: [ 1680.924472] cannot submit urb (err = -18) real 0m10.023s user 0m0.008s sys 0m0.004s I don't know if you want to investigate this in any detail. If you do, please post a usbmon trace of a failed playback. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BUG: USB audio discontinuities with 'UHCI: implement new semantics for URB_ISO_ASAP'
On Tue, Apr 23, 2013 at 05:09:35PM +0200, Clemens Ladisch wrote: Alan Stern wrote: On Tue, 23 Apr 2013, Clemens Ladisch wrote: Why is having a queue of two URB with one packet each suddenly not allowed? It _is_ allowed when URB_ISO_ASAP is clear. I have never fully understood why the audio driver sets that flag. By setting it, you are telling the host controller driver that you are willing to give up reduced latency in order to avoid underruns. This flag was needed to avoid having to set urb-start_frame. With the changed queueing API, the audio driver needs to change too. I'll look into this ... For what it's worth, the following -stable patch ALSA: USB: adjust for changed 3.8 USB API c75c5ab575af7db707689cdbb5a5c458e9a034bb fixes the discontinuous playback on period sizes between 139 and 192, but the discontinuous playback on period sizes between 48 and 138 has been replaced by rather worse kernel blocking and kernel errors: jrayhawk@richardiv:~$ sudo tail -F -n 0 /var/log/kern.log [1] 4490 jrayhawk@richardiv:~$ time perl -e 'print pack H*, 00FF x 2048' | aplay --period-size=192 -r 48000 -f S16_LE -c2 -D hw:0,0 Playing raw data 'stdin' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo real0m0.053s user0m0.008s sys 0m0.000s jrayhawk@richardiv:~$ time perl -e 'print pack H*, 00FF x 2048' | aplay --period-size=48 -r 48000 -f S16_LE -c2 -D hw:0,0 Playing raw data 'stdin' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo May 8 17:01:56 richardiv kernel: [ 1680.923474] cannot submit urb (err = -18) May 8 17:01:56 richardiv kernel: [ 1680.924472] cannot submit urb (err = -18) real0m10.023s user0m0.008s sys 0m0.004s signature.asc Description: Digital signature
Re: BUG: USB audio discontinuities with 'UHCI: implement new semantics for URB_ISO_ASAP'
Alan Stern wrote: It is now unnecessary to set urb-start_frame; in fact that field is now output-only. (To be fair, I haven't checked _all_ the HCDs in this regard, just uhci-hcd, ohci-hcd, and ehci-hcd. However, if any other HCD requires urb-start_frame to be set then that HCD should be considered buggy and should be fixed.) That would be fhci, imx21, isp1362, and musb. The other HCDs (including xhci) often have obsolete comments of the form always assume URB_ISO_ASAP and do not implement the new semantics either. Regards, Clemens -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BUG: USB audio discontinuities with 'UHCI: implement new semantics for URB_ISO_ASAP'
Alan Stern wrote: On Fri, 19 Apr 2013, Joe Rayhawk wrote: On Fri, Apr 19, 2013 at 02:18:24PM -0400, Alan Stern wrote: On Fri, 19 Apr 2013, Clemens Ladisch wrote: Alan Stern wrote: + next = uhci-frame_number + 2; That 2 is the minimum latency, in frames (one frame per ms). One frame worked fine with the old driver. What is the reason for this regression? Perhaps that was a mistake. Joe, you can try changing the 2 above to a 1 to see if it fixes the problem. Hey, that worked great! Audio's coming through continuously, now. This change could be added to the driver, but I would prefer not to. Why do you think it is necessary to have a minimum latency of 2 ms? Again, the old algorithm worked fine. While such short queues are not used by default, they are necessary to get low latencies for real-time audio applications. Keeping this change would keep this regression for quite a few people. In any case, it would be best What criteria are you using to evaluate the benefit of this? Do you want to reduce the chance of queue underruns? Interrupts? Power usage? if the usb-audio driver were changed to keep the pipeline length at least 2 ms at all times. Why is having a queue of two URB with one packet each suddenly not allowed? Regards, Clemens -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BUG: USB audio discontinuities with 'UHCI: implement new semantics for URB_ISO_ASAP'
On Tue, 23 Apr 2013, Clemens Ladisch wrote: Alan Stern wrote: On Fri, 19 Apr 2013, Joe Rayhawk wrote: On Fri, Apr 19, 2013 at 02:18:24PM -0400, Alan Stern wrote: On Fri, 19 Apr 2013, Clemens Ladisch wrote: Alan Stern wrote: + next = uhci-frame_number + 2; That 2 is the minimum latency, in frames (one frame per ms). One frame worked fine with the old driver. What is the reason for this regression? Perhaps that was a mistake. Joe, you can try changing the 2 above to a 1 to see if it fixes the problem. Hey, that worked great! Audio's coming through continuously, now. This change could be added to the driver, but I would prefer not to. Why do you think it is necessary to have a minimum latency of 2 ms? To avoid underruns. Perhaps this is unnecessary caution on my part. Again, the old algorithm worked fine. While such short queues are not used by default, they are necessary to get low latencies for real-time audio applications. Keeping this change would keep this regression for quite a few people. Okay, I will change the 2 to 1 since you think that is best. In any case, it would be best What criteria are you using to evaluate the benefit of this? Do you want to reduce the chance of queue underruns? Interrupts? Power usage? Chance of underruns. if the usb-audio driver were changed to keep the pipeline length at least 2 ms at all times. Why is having a queue of two URB with one packet each suddenly not allowed? It _is_ allowed when URB_ISO_ASAP is clear. I have never fully understood why the audio driver sets that flag. By setting it, you are telling the host controller driver that you are willing to give up reduced latency in order to avoid underruns. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BUG: USB audio discontinuities with 'UHCI: implement new semantics for URB_ISO_ASAP'
Alan Stern wrote: On Tue, 23 Apr 2013, Clemens Ladisch wrote: Why is having a queue of two URB with one packet each suddenly not allowed? It _is_ allowed when URB_ISO_ASAP is clear. I have never fully understood why the audio driver sets that flag. By setting it, you are telling the host controller driver that you are willing to give up reduced latency in order to avoid underruns. This flag was needed to avoid having to set urb-start_frame. With the changed queueing API, the audio driver needs to change too. I'll look into this ... Regards, Clemens -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BUG: USB audio discontinuities with 'UHCI: implement new semantics for URB_ISO_ASAP'
On Tue, 23 Apr 2013, Clemens Ladisch wrote: Alan Stern wrote: On Tue, 23 Apr 2013, Clemens Ladisch wrote: Why is having a queue of two URB with one packet each suddenly not allowed? It _is_ allowed when URB_ISO_ASAP is clear. I have never fully understood why the audio driver sets that flag. By setting it, you are telling the host controller driver that you are willing to give up reduced latency in order to avoid underruns. This flag was needed to avoid having to set urb-start_frame. Ah, okay. It is now unnecessary to set urb-start_frame; in fact that field is now output-only. (To be fair, I haven't checked _all_ the HCDs in this regard, just uhci-hcd, ohci-hcd, and ehci-hcd. However, if any other HCD requires urb-start_frame to be set then that HCD should be considered buggy and should be fixed.) With the changed queueing API, the audio driver needs to change too. I'll look into this ... Let me know if you have any questions. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BUG: USB audio discontinuities with 'UHCI: implement new semantics for URB_ISO_ASAP'
On Fri, 19 Apr 2013, Joe Rayhawk wrote: On Fri, Apr 19, 2013 at 02:18:24PM -0400, Alan Stern wrote: On Fri, 19 Apr 2013, Clemens Ladisch wrote: Alan Stern wrote: + next = uhci-frame_number + 2; That 2 is the minimum latency, in frames (one frame per ms). One frame worked fine with the old driver. What is the reason for this regression? Perhaps that was a mistake. Joe, you can try changing the 2 above to a 1 to see if it fixes the problem. Hey, that worked great! Audio's coming through continuously, now. This change could be added to the driver, but I would prefer not to. In any case, it would be best if the usb-audio driver were changed to keep the pipeline length at least 2 ms at all times. Clemens, what do you suggest? Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BUG: USB audio discontinuities with 'UHCI: implement new semantics for URB_ISO_ASAP'
On Thu, 18 Apr 2013, Joe Rayhawk wrote:
On Thu, Apr 18, 2013 at 12:42:00PM -0400, Alan Stern wrote:
On Wed, 17 Apr 2013, Joe Rayhawk wrote:
Small buffer/period sizes on usb audio playback though UHCI works fine on
v3.7 but causes audio discontinuities/delays on v3.8 and v3.9-rc7.
Can you provide a usbmon trace showing the problems? And maybe also a
similar trace made under a 3.7 kernel, where the problem doesn't occur?
root@richardiv:~# uname -a; cat /sys/kernel/debug/usb/usbmon/6u perl -e
'print pack H*, 00FF x 2048' | aplay --period-size=48 -r 44100 -f S16_LE
-c2 -D hw:1,0; kill %1
Linux richardiv 3.7-trunk-amd64 #1 SMP Debian 3.7.1-1~experimental.1 x86_64
GNU/Linux
[1] 4407
Playing raw data 'stdin' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo
I don't know exactly what that --period-size=48 parameter is supposed
to accomplish. The man page talks about time between interrupts, but
this doesn't seem to be related at all to what the usbmon trace shows.
In this test, the audio driver ended up using two 1-ms buffers.
8801549cc780 288953559 S Zo:6:007:1 -115:1:0 1 -18:0:176 176 =
8801549cca80 288953569 S Zo:6:007:1 -115:1:0 1 -18:0:176 176 =
Here the pipeline is started by writing two buffers of zeros.
8801549cc780 288964489 C Zo:6:007:1 0:1:217621:0 1 0:0:176 176
8801549cc780 288964505 S Zo:6:007:1 -115:1:217621 1 -18:0:176 176 =
00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff
8801549cca80 288965508 C Zo:6:007:1 0:1:217622:0 1 0:0:176 176
8801549cca80 288965527 S Zo:6:007:1 -115:1:217622 1 -18:0:176 176 =
00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff
In the remainder, each time a buffer completes, a new one is
submitted. This implies a latency of less than 1 ms. Evidently that
works okay on your system, but it won't work everywhere.
8801549cc780 288966486 C Zo:6:007:1 0:1:217623:0 1 0:0:176 176
8801549cc780 288966503 S Zo:6:007:1 -115:1:217623 1 -18:0:176 176 =
00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff
8801549cca80 288967488 C Zo:6:007:1 0:1:217624:0 1 0:0:176 176
8801549cca80 288967507 S Zo:6:007:1 -115:1:217624 1 -18:0:176 176 =
00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff
8801549cc780 288968508 C Zo:6:007:1 0:1:217625:0 1 0:0:176 176
8801549cc780 288968523 S Zo:6:007:1 -115:1:217625 1 -18:0:176 176 =
00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff
8801549cca80 288969485 C Zo:6:007:1 0:1:217626:0 1 0:0:176 176
8801549cca80 288969499 S Zo:6:007:1 -115:1:217626 1 -18:0:176 176 =
00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff
8801549cc780 288970507 C Zo:6:007:1 0:1:217627:0 1 0:0:176 176
8801549cc780 288970520 S Zo:6:007:1 -115:1:217627 1 -18:0:176 176 =
00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff
8801549cca80 288971487 C Zo:6:007:1 0:1:217628:0 1 0:0:176 176
...
I won't include the whole log. It's worth noticing that the URB
completion lines (the lines with C) show no -EXDEV (-18) errors, and
the frame numbers increase sequentially (217623, 217624, 217625,
...). This is consistent with the sound being produced correctly.
root@richardiv:~# # Generated only opening and closing clicks
root@richardiv:~# uname -a; cat /sys/kernel/debug/usb/usbmon/4u perl -e
'print pack H*, 00FF x 2048' | aplay --period-size=48 -r 44100 -f S16_LE
-c2 -D hw:1,0; kill %1
Linux richardiv 3.8-trunk-amd64 #1 SMP Debian 3.8-1~experimental.1 x86_64
GNU/Linux
880143c80d80 3864232940 C Zo:4:002:1 0:1:1057125:0 1 0:0:176 176
880143c80d80 3864232956 S Zo:4:002:1 -115:1:1057125 1 -18:0:176 176 =
00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff
880143c80180 3864233934 C Zo:4:002:1 0:1:1057126:0 1 0:0:176 176
880143c80180 3864233955 S Zo:4:002:1 -115:1:1057126 1 -18:0:176 176 =
00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff
880143c80d80 3864235913 C Zo:4:002:1 0:1:1057128:0 1 0:0:176 176
880143c80d80 3864235932 S Zo:4:002:1 -115:1:1057128 1 -18:0:176 176 =
00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff
880143c80180 3864236910 C Zo:4:002:1 0:1:1057129:0 1 0:0:176 176
880143c80180 3864236927 S Zo:4:002:1 -115:1:1057129 1 -18:0:176 176 =
00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff
880143c80d80 3864238939 C Zo:4:002:1 0:1:1057131:0 1 0:0:176 176
...
This trace shows that the frame numbers do not increase sequentially:
1057125, 1057126, 1057128, 1057129, 1053131, ... This is because the
new driver is a little more conservative than the old driver,
requiring latencies to be larger than 1 ms.
Re: BUG: USB audio discontinuities with 'UHCI: implement new semantics for URB_ISO_ASAP'
Alan Stern wrote: ... This trace shows that the frame numbers do not increase sequentially: 1057125, 1057126, 1057128, 1057129, 1053131, ... This is because the new driver is a little more conservative than the old driver, requiring latencies to be larger than 1 ms. You can see this explicitly in one of the new lines added by the commit you found: + next = uhci-frame_number + 2; That 2 is the minimum latency, in frames (one frame per ms). One frame worked fine with the old driver. What is the reason for this regression? Anyway, the solution is simple: The audio driver needs either to submit buffers that are at least 2 ms long, or to use more than two buffers (or both). The audio driver already has the infrastructure to cope for hardware restrictions like this, it just needs to *know* about them. How can it detect that it runs on the OHCI/UHCI drivers? Regards, Clemens -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BUG: USB audio discontinuities with 'UHCI: implement new semantics for URB_ISO_ASAP'
On Fri, 19 Apr 2013, Clemens Ladisch wrote: Alan Stern wrote: ... This trace shows that the frame numbers do not increase sequentially: 1057125, 1057126, 1057128, 1057129, 1053131, ... This is because the new driver is a little more conservative than the old driver, requiring latencies to be larger than 1 ms. You can see this explicitly in one of the new lines added by the commit you found: + next = uhci-frame_number + 2; That 2 is the minimum latency, in frames (one frame per ms). One frame worked fine with the old driver. What is the reason for this regression? The semantics of URB_ISO_ASAP changed; now the driver interprets as meaning the earliest time that is certain to work. Since I wasn't sure that a 1-ms latency would always work, I increased the minimum to 2. Perhaps that was a mistake. Joe, you can try changing the 2 above to a 1 to see if it fixes the problem. Anyway, the solution is simple: The audio driver needs either to submit buffers that are at least 2 ms long, or to use more than two buffers (or both). The audio driver already has the infrastructure to cope for hardware restrictions like this, it just needs to *know* about them. How can it detect that it runs on the OHCI/UHCI drivers? That is a very good question. In fact, the audio driver shouldn't care about what kind of driver is used at the lower level; all it should care about are bounds on the latency. The kernel's USB API doesn't provide this information, unfortunately. There should be a way for drivers to find out, for any USB device: A. The maximum delay time needed for starting a new isochronous stream; B. The minimum advance time required for submitting a new URB to an existing isochronous stream (i.e., the minimum pipeline size); C. The maximum time into the future that isochronous URBs can be scheduled (the maximum pipeline size). I don't think there's any way to add this information into all of the existing host controller drivers, though. For now, the best approach is to be conservative. I believe all the existing USB host controller drivers will work okay if you assume the following values: A: 50 ms; B: 2 ms; C: 200 ms. The audio driver probably doesn't care about A; you try to start a new stream and it gets going whenever the HCD chooses. You may or may not care about C. B is the important one for this discussion. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BUG: USB audio discontinuities with 'UHCI: implement new semantics for URB_ISO_ASAP'
On Fri, Apr 19, 2013 at 02:18:24PM -0400, Alan Stern wrote:
On Fri, 19 Apr 2013, Clemens Ladisch wrote:
Alan Stern wrote:
+ next = uhci-frame_number + 2;
That 2 is the minimum latency, in frames (one frame per ms).
One frame worked fine with the old driver. What is the reason for
this regression?
Perhaps that was a mistake. Joe, you can try changing the 2 above to a
1 to see if it fixes the problem.
Hey, that worked great! Audio's coming through continuously, now.
root@richardiv:~# uname -a; cat /sys/kernel/debug/usb/usbmon/4u perl -e
'print pack H*, 00FF x 2048' | aplay --period-size=48 -r 44100 -f S16_LE
-c2 -D hw:1,0; kill %1
Linux richardiv 3.9.0-rc7-nextframe #8 SMP Fri Apr 19 16:29:37 PDT 2013 x86_64
GNU/Linux
[1] 4598
Playing raw data 'stdin' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo
880154aba440 3793290194 S Co:4:005:0 s 01 0b 0001 0001 0
880154aba440 3793292190 C Co:4:005:0 0 0
8801515a20c0 3793292289 S Co:4:005:0 s 22 01 0100 0001 0003 3 = 44ac00
8801515a20c0 3793293167 C Co:4:005:0 0 3
8801515a20c0 3793293206 S Ci:4:005:0 s a2 81 0100 0001 0003 3
8801515a20c0 3793294188 C Ci:4:005:0 0 3 = 44ac00
880142054dc0 3793294216 S Zo:4:005:1 -115:1:0 1 -18:0:176 176 =
8801420541c0 3793294221 S Zo:4:005:1 -115:1:0 1 -18:0:176 176 =
880142054dc0 3793305177 C Zo:4:005:1 0:1:362330:0 1 0:0:176 176
880142054dc0 3793305202 S Zo:4:005:1 -115:1:362330 1 -18:0:176 176 =
00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff
8801420541c0 3793306165 C Zo:4:005:1 0:1:362331:0 1 0:0:176 176
8801420541c0 3793306186 S Zo:4:005:1 -115:1:362331 1 -18:0:176 176 =
00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff
880142054dc0 3793307191 C Zo:4:005:1 0:1:362332:0 1 0:0:176 176
880142054dc0 3793307208 S Zo:4:005:1 -115:1:362332 1 -18:0:176 176 =
00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff
8801420541c0 3793308190 C Zo:4:005:1 0:1:362333:0 1 0:0:176 176
8801420541c0 3793308203 S Zo:4:005:1 -115:1:362333 1 -18:0:176 176 =
00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff
880142054dc0 3793309191 C Zo:4:005:1 0:1:362334:0 1 0:0:176 176
880142054dc0 3793309209 S Zo:4:005:1 -115:1:362334 1 -18:0:176 176 =
00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff
8801420541c0 3793310194 C Zo:4:005:1 0:1:362335:0 1 0:0:176 176
8801420541c0 3793310211 S Zo:4:005:1 -115:1:362335 1 -18:0:176 176 =
00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff
880142054dc0 3793311192 C Zo:4:005:1 0:1:362336:0 1 0:0:176 176
880142054dc0 3793311211 S Zo:4:005:1 -115:1:362336 1 -18:0:176 176 =
00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff
8801420541c0 3793312194 C Zo:4:005:1 0:1:362337:0 1 0:0:176 176
8801420541c0 3793312212 S Zo:4:005:1 -115:1:362337 1 -18:0:180 180 =
00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff
880142054dc0 3793313172 C Zo:4:005:1 0:1:362338:0 1 0:0:176 176
880142054dc0 3793313188 S Zo:4:005:1 -115:1:362338 1 -18:0:176 176 =
00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff
8801420541c0 3793314192 C Zo:4:005:1 0:1:362339:0 1 0:0:180 180
8801420541c0 3793314209 S Zo:4:005:1 -115:1:362339 1 -18:0:176 176 =
00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff
880142054dc0 3793315192 C Zo:4:005:1 0:1:362340:0 1 0:0:176 176
880142054dc0 3793315210 S Zo:4:005:1 -115:1:362340 1 -18:0:176 176 =
00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff
8801420541c0 3793316192 C Zo:4:005:1 0:1:362341:0 1 0:0:176 176
8801420541c0 3793316209 S Zo:4:005:1 -115:1:362341 1 -18:0:176 176 =
00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff
880142054dc0 3793317196 C Zo:4:005:1 0:1:362342:0 1 0:0:176 176
880142054dc0 3793317207 S Zo:4:005:1 -115:1:362342 1 -18:0:176 176 =
00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff
8801420541c0 3793318191 C Zo:4:005:1 0:1:362343:0 1 0:0:176 176
8801420541c0 3793318209 S Zo:4:005:1 -115:1:362343 1 -18:0:176 176 =
00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff
880142054dc0 3793319193 C Zo:4:005:1 0:1:362344:0 1 0:0:176 176
880142054dc0 3793319211 S Zo:4:005:1 -115:1:362344 1 -18:0:176 176 =
00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff
8801420541c0 3793320191 C Zo:4:005:1 0:1:362345:0 1 0:0:176 176
8801420541c0 3793320208 S Zo:4:005:1 -115:1:362345 1 -18:0:176 176 =
00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff
880142054dc0 3793321196 C Zo:4:005:1 0:1:362346:0 1 0:0:176 176
Re: BUG: USB audio discontinuities with 'UHCI: implement new semantics for URB_ISO_ASAP'
On Wed, 17 Apr 2013, Joe Rayhawk wrote: Small buffer/period sizes on usb audio playback though UHCI works fine on v3.7 but causes audio discontinuities/delays on v3.8 and v3.9-rc7. I've bisected the behavior down to c44b225077bb1fb25ed5cd5c4f226897b91bedd4 'UHCI: implement new semantics for URB_ISO_ASAP' Tested on two UHCI hosts and three usb-audio devices, all from different vendors. Can you provide a usbmon trace showing the problems? And maybe also a similar trace made under a 3.7 kernel, where the problem doesn't occur? Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
BUG: USB audio discontinuities with 'UHCI: implement new semantics for URB_ISO_ASAP'
Small buffer/period sizes on usb audio playback though UHCI works fine on v3.7 but causes audio discontinuities/delays on v3.8 and v3.9-rc7. I've bisected the behavior down to c44b225077bb1fb25ed5cd5c4f226897b91bedd4 'UHCI: implement new semantics for URB_ISO_ASAP' Tested on two UHCI hosts and three usb-audio devices, all from different vendors. Please CC me on replies. $ speaker-test -t sine -c 2 -D hw:2,0 -p 3990 # Produces smooth sine wave speaker-test 1.0.25 Playback device is hw:2,0 Stream parameters are 48000Hz, S16_LE, 2 channels Sine wave rate is 440.Hz Rate set to 48000Hz (requested 48000Hz) Buffer size range from 96 to 262144 Period size range from 48 to 131072 Requested period time 3990 us Periods = 4 was set period_size = 192 was set buffer_size = 768 0 - Front Left 1 - Front Right Time per period = 5.991993 0 - Front Left 1 - Front Right Time per period = 5.80 0 - Front Left 1 - Front Right Time per period = 5.83 0 - Front Left 1 - Front Right Time per period = 5.83 0 - Front Left ^C $ speaker-test -t sine -c 2 -D hw:2,0 -p 3980 # Produces discontinuous sine wave speaker-test 1.0.25 Playback device is hw:2,0 Stream parameters are 48000Hz, S16_LE, 2 channels Sine wave rate is 440.Hz Rate set to 48000Hz (requested 48000Hz) Buffer size range from 96 to 262144 Period size range from 48 to 131072 Requested period time 3980 us Periods = 4 was set period_size = 191 was set buffer_size = 764 0 - Front Left 1 - Front Right Time per period = 6.016006 0 - Front Left 1 - Front Right Time per period = 6.023981 0 - Front Left 1 - Front Right Time per period = 6.023984 0 - Front Left 1 - Front Right Time per period = 6.023983 0 - Front Left ^C $ speaker-test -t sine -c 2 -D hw:2,0 -p 2000 # much higher rate of discontinuities; note increased time per period speaker-test 1.0.25 Playback device is hw:2,0 Stream parameters are 48000Hz, S16_LE, 2 channels Sine wave rate is 440.Hz Rate set to 48000Hz (requested 48000Hz) Buffer size range from 96 to 262144 Period size range from 48 to 131072 Requested period time 2000 us Periods = 4 was set period_size = 96 was set buffer_size = 384 0 - Front Left 1 - Front Right Time per period = 8.994562 0 - Front Left 1 - Front Right Time per period = 8.13 0 - Front Left 1 - Front Right Time per period = 8.18 0 - Front Left ^C jrayhawk@tubbablubba:~$ lsusb # both 10f5:0211 and 0d8c:0126 exhibit the problem Bus 002 Device 002: ID 046d:c50b Logitech, Inc. Cordless Desktop Optical Bus 002 Device 003: ID 046d:c03d Logitech, Inc. M-BT96a Pilot Optical Mouse Bus 002 Device 004: ID 10f5:0211 Turtle Beach Bus 002 Device 005: ID 0d8c:0126 C-Media Electronics, Inc. Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub jrayhawk@richardiv:~$ lsusb # 046d:0a19 exhibits the problem Bus 002 Device 004: ID 0a5c:2145 Broadcom Corp. Bluetooth with Enhanced Data Rate II Bus 002 Device 005: ID 08ff:2810 AuthenTec, Inc. AES2810 Bus 004 Device 003: ID 046d:0a19 Logitech, Inc. Bus 007 Device 004: ID 17ef:1008 Lenovo Bus 008 Device 002: ID 17ef:480c Lenovo Integrated Webcam Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 007 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 008 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub jrayhawk@tubbablubba:~$ lspci -nn | grep -i usb 00:02.0 USB controller [0c03]: NVIDIA Corporation MCP61 USB 1.1 Controller [10de:03f1] (rev a3) 00:02.1 USB controller [0c03]: NVIDIA Corporation MCP61 USB 2.0 Controller [10de:03f2] (rev a3) jrayhawk@richardiv:~$ lspci -nn | grep -i usb 00:1a.0 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4 [8086:2937] (rev 03) 00:1a.1 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #5 [8086:2938] (rev 03) 00:1a.2 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #6 [8086:2939] (rev 03) 00:1a.7 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #2 [8086:293c] (rev 03) 00:1d.0 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #1 [8086:2934] (rev 03) 00:1d.1 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #2 [8086:2935] (rev 03) 00:1d.2 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #3 [8086:2936] (rev 03) 00:1d.7 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #1 [8086:293a] (rev 03) signature.asc Description: Digital signature
