On Wed, 2010-03-31 at 12:58 -0400, Alan Stern wrote:
> Here's a patch which ought to fix that bug. However it may turn out
> that the end result is a little drastic: The aplay program might fail!
>
> The difficulty is that the audio driver schedules four Iso-IN URBs at
> 64-ms intervals, and the total scheduling window is only 236 ms long
> (actually 256 ms, but minus 20 for slop and overhead). The fourth URB
> should have been rejected with a -EFBIG error, and this patch will
> cause that to happen -- you can confirm with usbmon. How the driver
> and aplay will deal with the submission error, I don't know.
Thanks for the patch. I tested this, and the behavior is quite
different now. I still get the "fatal error" / "HC died" *most* of the
time, but you are right that aplay is now failing. Now, aplay errors
out with "aplay: set_params:1041: Unable to install hw params:".
On the kernel side, I see:
ALSA sound/usb/usbaudio.c:872: cannot submit syncpipe for urb 3, error -27: internal error
ehci_hcd 0000:07:0c.1: fatal error
ehci_hcd 0000:07:0c.1: fatal command 010038 (park)=0 ithresh=1 Async Periodic period=256 HALT
ehci_hcd 0000:07:0c.1: fatal status c018 Async Periodic FATAL FLR
The usbmon trace is now much shorter since aplay bails out:
bfb0e700 107029874 S Co:1:004:0 s 01 0b 0001 0002 0000 0
bfb0e700 107030073 C Co:1:004:0 0 0
bfb0e700 107030110 S Ci:1:004:0 s 80 06 0302 0409 00ff 255 <
bfb0e700 107030318 C Ci:1:004:0 0 16 = 10035700 36003800 31003300 30003800
bfb0e700 107030378 S Co:1:004:0 s 22 01 0100 0002 0003 3 = 80bb00
bfb0e700 107030568 C Co:1:004:0 0 3 >
bfb0e700 107030579 S Ci:1:004:0 s a2 81 0100 0002 0003 3 <
bfb0e700 107030818 C Ci:1:004:0 0 3 = 000000
bf13c540 107038689 S Zo:1:004:2 -115:1:0 1 -18:0:96 96 = 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
bf13c600 107038805 S Zo:1:004:2 -115:1:0 2 -18:0:96 -18:96:96 192 = 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
bf13c6c0 107038815 S Zi:1:004:6 -115:64:0 1 -18:0:3 4 <
bf13c780 107038824 S Zi:1:004:6 -115:64:0 1 -18:0:3 4 <
bf13c840 107038829 S Zi:1:004:6 -115:64:0 1 -18:0:3 4 <
bf13c900 107038834 S Zi:1:004:6 -115:64:0 1 -18:0:3 4 <
bf13c900 107038841 E Zi:1:004:6 -27 0
bf13c540 107048196 C Zo:1:004:2 -104:1:74:0 1 0:0:96 96 >
bf13c6c0 107048443 C Zi:1:004:6 -104:64:74:0 1 0:0:3 3 = 00000c
bf13c600 107050194 C Zo:1:004:2 -104:1:75:0 2 0:0:96 0:96:96 192 >
bf13c780 107125058 C Zi:1:004:6 -104:64:138:0 1 0:0:0 0
bf13c840 107125078 C Zi:1:004:6 -104:64:202:0 1 0:0:0 0
bf0bcb80 107125096 C Ii:1:002:1 -108:2048 0
bfb0e700 107128018 S Co:1:004:0 s 01 0b 0000 0002 0000 0
bf0bcc00 107129794 C Ii:1:003:1 -108:2048 0
bfb0e700 107129796 E Co:1:004:0 -108 0
bf0bc800 107313541 C Ii:1:001:1 -2:2048 0
> Incidentally, do you know exactly which USB audio driver is being used?
The standard in-kernel sound/usb/usbaudio.c driver. For fun, I
redefined SYNC_URBS from 4 to 3 (admittedly not understanding what I'm
doing), but that still had problems.
- Nate Case <ncase@xxxxxxxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
