Re: use of isochronous mode
> > Does the Linux USB implementation supports both equally well? And also the > scheduling of a mixture of both pipe types? For both USB 2 and 3? > Do you have an idea why many commercial devices (e.g. AV applications) still > would go for bulk? > > Thanks a lot & kind regards, > Yves > -- I have a DAC that use isochronous audio and it worked fine on USB 2.0, then I bought an intel NUC which had USB 3.0 and it still does not work after a couple of months of trying. Intel just say its a Linux issue, however the people here have been very helpful and say its not a driver issue, also I have heard it reported it works on a non intel USB 3.0 hardware. Although I cannot say for sure, it looks like the Intel hardware has a bug and they are reluctant to admit it. See below. forums.presonus.com/posts/list/33427.page It might be worth contacting this guy to see if he can help. usb.org/developers/presentations/pres1108/SuperSpeed_USB_DevCon_Isochronous_TengFroelich.pdf BR Russ -- 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: Bugs in xhci-hcd isochronous support
> Does your computer have any USB-2 ports? Or is it possible to disable > the USB-3 controllers in the BIOS? It would be worthwhile to see if > the audio works when the device is attached to a non-USB-3 controller. > Hi, Some more information from someone who has the same DAC as me and has got it working on USB3.0 under Linux. I dont know if this helps with a workround or just points to some fundamental problem with the Intel hardware. "I was right in that MDAC works for me on USB3.0 (detected as NEC uPD720200, Asus P8Z68 Deluxe motherboard), using xhci_hcd on a more-or-less vanilla 3.12.3 kernel (yeah, I should upgrade soon): Code: # lsusb -t ... /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 480M |__ Port 1: Dev 3, If 0, Class=HID, Driver=usbhid, 12M |__ Port 1: Dev 3, If 1, Class=audio, Driver=snd-usb-audio, 12M |__ Port 1: Dev 3, If 2, Class=audio, Driver=snd-usb-audio, 12M ... Manually watching /proc/interrupts confirms that it's not going through ehci_hcd. I can even play 24/96k without any problems (unlike unpatched ehci_hcd). Therfore your issue is either not xhci_hcd related, or is hardware-specific. Make sure to mention your USB3 xhci controller in that lkml thread." My output is: lsusb -t /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/9p, 480M |__ Port 3: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 12M |__ Port 3: Dev 2, If 1, Class=Audio, Driver=snd-usb-audio, 12M |__ Port 3: Dev 2, If 2, Class=Audio, Driver=snd-usb-audio, 12M |__ Port 4: Dev 3, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M |__ Port 4: Dev 3, If 1, Class=Human Interface Device, Driver=usbhid, 1.5M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/8p, 480M -- 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: Bugs in xhci-hcd isochronous support
> > I got it. There doesn't seem to be anything wrong with the data in the > file. This means whatever the problem is, there's a good chance we > can't find it through software. > > Does your computer have any USB-2 ports? Or is it possible to disable > the USB-3 controllers in the BIOS? It would be worthwhile to see if > the audio works when the device is attached to a non-USB-3 controller. > > Alan Stern Particular Attention ***Intel*** people The audio device does work correctly on USB2.0 ports on another computer. The NUC does have USB 2.0 port headers on the PCB which I can try but as Intel have neglected to document anywhere on what the connections are it will take a bit of time to figure them out, they also look non standard header spacing at 2mm instead of 2.54mm, 0.1", so I need to source 2mm header connectors. Its not possible to disable USB 3.0 controllers in Bios, I would be happy if Intel could provide that as a workround. I have posted this previously, https://forums.presonus.com/posts/list/33427.page , where people are complaining about USB 3.0 Isochronous audio and rightly or wrongly are blaming Intel. From Intels perspective they might not care about the hi-fi market, its not that big, but the pro audio market is significant. I will try the onboard USB ports at some point and report the results back but it seems a bit of a backward step if I have to drill a hole in the box to get the USB audio running correctly. I am happy if someone from Intel want to contact me to try non Unix workarounds like different Bios software. BR Russel > -- 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: Bugs in xhci-hcd isochronous support
> The audio data is contained in the lines that have a 'Z'. Just search > for the first such line and then go back twenty or so lines before that > to provide some context. > > Alan Stern This OK? BR Russel fff880211c1e000 2991052997 S Ii:2:002:3 -115:32 2 < 880036d09480 2991060964 C Ii:2:003:2 0:8 7 = 02f0 ff 880036d09480 2991060996 S Ii:2:003:2 -115:8 20 < 880211c1e000 2991084868 C Ii:2:002:3 0:32 2 = 8002 880211c1e000 2991084875 S Ii:2:002:3 -115:32 2 < 880211c1e000 2991116869 C Ii:2:002:3 0:32 2 = 8002 880211c1e000 2991116886 S Ii:2:002:3 -115:32 2 < 880211c1e000 2991148920 C Ii:2:002:3 0:32 2 = 8002 880211c1e000 2991148934 S Ii:2:002:3 -115:32 2 < 880211c1e000 2991180881 C Ii:2:002:3 0:32 2 = 8002 880211c1e000 2991180891 S Ii:2:002:3 -115:32 2 < 880211c1e000 2991212916 C Ii:2:002:3 0:32 2 = 8002 880211c1e000 2991212930 S Ii:2:002:3 -115:32 2 < 880211c1e000 2991244869 C Ii:2:002:3 0:32 2 = 8002 880211c1e000 2991244882 S Ii:2:002:3 -115:32 2 < 880211c1e000 2991276888 C Ii:2:002:3 0:32 2 = 8002 880211c1e000 2991276896 S Ii:2:002:3 -115:32 2 < 880211c1e000 2991308916 C Ii:2:002:3 0:32 2 = 8002 880211c1e000 2991308929 S Ii:2:002:3 -115:32 2 < 880036d09480 2991333025 C Ii:2:003:2 0:8 7 = 0201 00 880036d09480 2991333061 S Ii:2:003:2 -115:8 20 < 880211c1e000 2991340916 C Ii:2:002:3 0:32 2 = 8002 880211c1e000 2991340929 S Ii:2:002:3 -115:32 2 < 880211c1e000 2991372916 C Ii:2:002:3 0:32 2 = 8002 880211c1e000 2991372929 S Ii:2:002:3 -115:32 2 < 880211c1e000 2991404885 C Ii:2:002:3 0:32 2 = 8002 880211c1e000 2991404894 S Ii:2:002:3 -115:32 2 < 880211c1e000 2991436915 C Ii:2:002:3 0:32 2 = 8002 880211c1e000 2991436928 S Ii:2:002:3 -115:32 2 < 880211c1e000 2991468853 C Ii:2:002:3 0:32 2 = 8002 880211c1e000 2991468862 S Ii:2:002:3 -115:32 2 < 880211c1e000 2991500915 C Ii:2:002:3 0:32 2 = 8002 880211c1e000 2991500929 S Ii:2:002:3 -115:32 2 < 880036d09480 2991524964 C Ii:2:003:2 0:8 7 = 0200 00 880036d09480 2991524999 S Ii:2:003:2 -115:8 20 < 8800c5551300 2991527066 S Co:2:002:0 s 01 0b 0001 0002 0 8800c5551300 2991527480 C Co:2:002:0 0 0 8800c5551540 2991527571 S Co:2:002:0 s 22 01 0100 0001 0003 3 = 44ac00 8800c5551540 2991527939 C Co:2:002:0 0 3 > 8800c5551540 2991527947 S Ci:2:002:0 s a2 81 0100 0001 0003 3 < 8800c5551540 2991530030 C Ci:2:002:0 -32 0 8801fe291c00 2991530052 S Zo:2:002:1 -115:1:0 6 -18:0:264 -18:264:264 -18:528:264 -18:792:264 -18:1056:264 1584 = 8801fe291000 2991530059 S Zo:2:002:1 -115:1:0 6 -18:0:264 -18:264:264 -18:528:264 -18:792:270 -18:1062:264 1590 = 8801fe290c00 2991530061 S Zo:2:002:1 -115:1:0 6 -18:0:264 -18:264:264 -18:528:264 -18:792:264 -18:1056:264 1584 = 880211833700 2991530062 S Zi:2:002:1 -115:32:0 1 -18:0:3 4 < 88020360b000 2991530065 S Zi:2:002:1 -115:32:0 1 -18:0:3 4 < 88020360be00 2991530066 S Zi:2:002:1 -115:32:0 1 -18:0:3 4 < 8802010e4f00 2991530067 S Zi:2:002:1 -115:32:0 1 -18:0:3 4 < 8800c5551540 2991530074 S Co:2:002:0 s 22 01 0100 0001 0003 3 = 44ac00 8800c5551540 2991530618 C Co:2:002:0 0 3 > 8800c5551540 2991530626 S Ci:2:002:0 s a2 81 0100 0001 0003 3 < 880211833700 2991531065 C Zi:2:002:1 0:1:1406:0 1 0:0:3 4 = 00030b00 880211833700 2991531069 S Zi:2:002:1 -115:1:1406 1 -18:0:3 4 < 88020360b000 2991532030 C Zi:2:002:1 0:1:1407:0 1 0:0:3 4 = 00030b00 88020360b000 2991532033 S Zi:2:002:1 -115:1:1407 1 -18:0:3 4 < 8800c5551540 2991532523 C Ci:2:002:0 -32 0 88020360be00 2991533035 C Zi:2:002:1 0:1:1408:0 1 0:0:3 4 = 00030b00 88020360be00 2991533040 S Zi:2:002:1 -115:1:1408 1 -18:0:3 4 < 880211c1e000 2991533045 C Ii:2:002:3 0:32 2 = 8002 880211c1e000 2991533047 S Ii:2:002:3 -115:32 2 < 8802010e4f00 2991534022 C Zi:2:002:1 0:1:1409:0 1 0:0:3 4 = 00030b00 8802010e4f00 2991534026 S Zi:2:002:1 -115:1:1409 1 -18:0:3 4 < 880211833700 2991535024 C Zi:2:002:1 0:1:1410:0 1 0:0:3 4 = 00030b00 880211833700 2991535029 S Zi:2:002:1 -115:1:1410 1 -18:0:3 4 < 8801fe291c00 2991536017 C Zo:2:002:1 0:1:1406:0 6 0:0:264 0:264:264 0:528:264 0:792:264 0:1056:264 1584 > 8801fe291c00 2991536026 S Zo:2:002:1 -115:1:1406 6 -18:0:264 -18:264:264 -18:528:264 -18:792:264 -18:1056:270 1590 = 8dedd084 ecd387b1 d29165cf 7058daa1 2cca618d dfb1d6c4 6cc3dbbb 5bc17a4a 88020360b000 2991536031 C Zi:2:002:1 0:1:1411:0 1 0:0:3 4 = 00030b00 88020360b000 2991536032 S Zi:2:002:1 -115:1:1411 1 -18:0:3 4 < 88020360be00 2991537025 C Zi:2:002:1 0:1:1412:0 1 0:0:3 4 = 00030b00 88020360be00 2991537029 S Zi:2:002:1 -115:1:1412 1 -18:0:3 4 < 8802010e4f00 2991538033 C Zi:2:002:1 0:1:1413:0 1 0:0:3 4
Re: Bugs in xhci-hcd isochronous support
> The patch was made against 3.15-rc2, which is no longer the latest > kernel version. > > However, the nature of those error messages suggests that the patch > file you tried to apply was messed up somehow, probably by your email > client. You can get the unmodified original here: > > http://marc.info/?l=linux-usb&m=139906101630351&q=raw > > Alan Stern > Hi, Thanks, yes I don't know what is going on in gmail, plain text is selected and indicated, it has worked but now no longer seems to. No noticeable difference in buffer level performance visually, still all over the place compared to USB2.0, audio everyone is asleep so I cannot really test but I think it still drops out, will say tomorrow. HDMI audio still works, which it didn't last time I swapped kernels, so some good news! Patch went as follows. Hunk #1 succeeded at 3148 (offset -5 lines). Hunk #2 succeeded at 3159 (offset -5 lines). Hunk #3 succeeded at 3402 (offset -5 lines). Hunk #4 succeeded at 3541 (offset -5 lines). Hunk #5 succeeded at 3658 (offset -5 lines). Hunk #6 succeeded at 3738 (offset -5 lines). Hunk #7 succeeded at 3754 (offset -5 lines). Hunk #8 succeeded at 3766 (offset -5 lines). Hunk #9 succeeded at 3829 (offset -5 lines). Hunk #10 succeeded at 3894 (offset -5 lines). Hunk #11 succeeded at 3978 (offset -5 lines). Hunk #12 succeeded at 4000 (offset -5 lines). Hunk #13 succeeded at 4015 (offset -5 lines). patching file drivers/usb/host/xhci.h Hunk #2 succeeded at 887 (offset -2 lines). Hunk #3 succeeded at 1169 (offset -2 lines). built the kernel and placed it in, I can rebuild it with rc2 as I forgot you had used rc2 if you wish uname -r 3.15.0-rc3 T: Bus=02 Lev=01 Prnt=01 Port=02 Cnt=01 Dev#= 4 Spd=12 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor=0451 ProdID=adac Rev= a.09 S: Manufacturer=Lakewest Audio S: Product=Audiolab M-DAC C:* #Ifs= 3 Cfg#= 1 Atr=c0 MxPwr= 0mA I:* If#= 0 Alt= 0 #EPs= 2 Cls=03(HID ) Sub=00 Prot=00 Driver=usbhid E: Ad=82(I) Atr=03(Int.) MxPS= 64 Ivl=1ms E: Ad=02(O) Atr=03(Int.) MxPS= 64 Ivl=1ms I:* If#= 1 Alt= 0 #EPs= 1 Cls=01(audio) Sub=01 Prot=00 Driver=snd-usb-audio E: Ad=83(I) Atr=03(Int.) MxPS= 2 Ivl=32ms I: If#= 2 Alt= 0 #EPs= 0 Cls=01(audio) Sub=02 Prot=00 Driver=snd-usb-audio I:* If#= 2 Alt= 1 #EPs= 2 Cls=01(audio) Sub=02 Prot=00 Driver=snd-usb-audio E: Ad=01(O) Atr=05(Isoc) MxPS= 582 Ivl=1ms E: Ad=81(I) Atr=11(Isoc) MxPS= 3 Ivl=1ms sudo cat /sys/kernel/debug/usb/usbmon/2u > /tmp/1.mon.out first few hundred lines 880200adef00 2596394321 C Zi:2:004:1 0:1:1833:0 1 0:0:3 4 = 00030b00 880200adef00 2596394330 S Zi:2:004:1 -115:1:1833 1 -18:0:3 4 < 8801f3c8e600 2596395313 C Zo:2:004:1 0:1:1830:0 5 0:0:264 0:264:264 0:528:264 0:792:270 0:1062:264 1326 > 8801f3c8e600 2596395324 S Zo:2:004:1 -115:1:1830 5 -18:0:264 -18:264:264 -18:528:264 -18:792:264 -18:1056:264 1320 = 023dff06 fffdfdc4 0003bafe fdbf0003 c0fe00ad ff06eefd 0496fe07 57fd0843 8800d14aba00 2596395327 C Zi:2:004:1 0:1:1834:0 1 0:0:3 4 = 00030b00 8800d14aba00 2596395328 S Zi:2:004:1 -115:1:1834 1 -18:0:3 4 < 8800d058e700 2596396343 C Zi:2:004:1 0:1:1835:0 1 0:0:3 4 = 00030b00 8800d058e700 2596396346 S Zi:2:004:1 -115:1:1835 1 -18:0:3 4 < 8801f3564300 2596397329 C Zi:2:004:1 0:1:1836:0 1 0:0:3 4 = 00030b00 8801f3564300 2596397341 S Zi:2:004:1 -115:1:1836 1 -18:0:3 4 < 880200adef00 2596398321 C Zi:2:004:1 0:1:1837:0 1 0:0:3 4 = 00030b00 880200adef00 2596398323 S Zi:2:004:1 -115:1:1837 1 -18:0:3 4 < 8800d14aba00 2596399319 C Zi:2:004:1 0:1:1838:0 1 0:0:3 4 = 00030b00 8800d14aba00 2596399323 S Zi:2:004:1 -115:1:1838 1 -18:0:3 4 < 8800d058e700 2596400323 C Zi:2:004:1 0:1:1839:0 1 0:0:3 4 = 00030b00 8800d058e700 2596400327 S Zi:2:004:1 -115:1:1839 1 -18:0:3 4 < 8801f3c8fa00 2596401328 C Zo:2:004:1 0:1:1835:0 6 0:0:264 0:264:264 0:528:264 0:792:264 0:1056:264 1584 > 8801f3c8fa00 2596401335 S Zo:2:004:1 -115:1:1835 5 -18:0:264 -18:264:264 -18:528:264 -18:792:270 -18:1062:264 1326 = f7e502f3 4f04f89a 02f89e02 fe7e0001 56fffc0f 0100e3ff f30604f1 b204f1b2 8801f3564300 2596401338 C Zi:2:004:1 0:1:1840:0 1 0:0:3 4 = 00030b00 8801f3564300 2596401338 S Zi:2:004:1 -115:1:1840 1 -18:0:3 4 < 880200adef00 2596402340 C Zi:2:004:1 0:1:1841:0 1 0:0:3 4 = 00030b00 880200adef00 2596402342 S Zi:2:004:1 -115:1:1841 1 -18:0:3 4 < 8800d14aba00 2596403345 C Zi:2:004:1 0:1:1842:0 1 0:0:3 4 = 00030b00 8800d14aba00 2596403350 S Zi:2:004:1 -115:1:1842 1 -18:0:3 4 < 8800d058e700 2596404352 C Zi:2:004:1 0:1:1843:0 1 0:0:3 4 = 00030b00 8800d058e700 2596404356 S Zi:2:004:1 -115:1:1843 1 -18:0:3 4 < 8801f3564300 2596405351 C Zi:2:004:1 0:1:1844:0 1 0:0:3 4 = 00030b00 8801f3564300 2596405355 S Zi:2:004:1 -115:1:1844 1 -18:0:3 4 < 8801f3c8f000 2596406339 C Zo:2:004:1 0:1:1841:0 5 0:0:264 0:264:264 0:528:264 0:792:264 0:1056:264 1320 > 8801f3c8f000 2596406347 S Zo:2:004:1 -115:1:1841 5 -18
Re: Bugs in xhci-hcd isochronous support
> > Russel, here's a patch you can test. It's only a partial fix for the > problem, because it doesn't handle over/underruns. Still, it would be > nice to see if the patch makes any difference in normal operation. > > Even if it doesn't fix the problem, please post a short stretch (a few > hundred lines) from a usbmon trace with the patch installed. > > Alan Stern > Hi, We tried downloading the latest kernel 3.15 and got this when applying the patch File to patch: ^C :~/linux kernel/usb-3.15.orig$ patch -p1 < patch.dif patching file drivers/usb/host/xhci-ring.c Hunk #1 FAILED at 3153. Hunk #2 FAILED at 3164. Hunk #3 FAILED at 3406. Hunk #4 FAILED at 3545. Hunk #5 FAILED at 3662. Hunk #6 FAILED at 3742. Hunk #7 FAILED at 3756. Hunk #8 FAILED at 3765. Hunk #9 FAILED at 3826. Hunk #10 FAILED at 3895. Hunk #11 FAILED at 3935. Hunk #12 FAILED at 3958. Hunk #13 FAILED at 3982. 13 out of 13 hunks FAILED -- saving rejects to file drivers/usb/host/xhci-ring.c.rej patching file drivers/usb/host/xhci.h Reversed (or previously applied) patch detected! Assume -R? [n] I was told that the lines in the source file were not in the place that they were expected, are we using the right kernel? Thanks in advance! BR Russel -- 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: Bugs in xhci-hcd isochronous support
> More importantly, the routine sets urb->start_frame to the current > value of the frame counter. This is completely wrong; urb->start_frame > is supposed to be the (micro-)frame number for when the transfer > begins, not when the transfer was submitted. > > As far as I can tell, the only way to do this correctly is to set the > Frame ID field (with SIA = 0) in the first TD of an isochronous stream, > and then set SIA = 1 in all the following TDs (see 4.11.2.5). That > way, xhci-hcd will know exactly when the stream begins, so it can keep > track of the frame in which each URB starts. Dealing with underruns is > left as an exercise for the implementer... > Let me know if you want any changes tested using my DAC that reliably shows the problem. BR Russel -- 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: Fwd: Isochronos audio
On 9 April 2014 19:53, Alan Stern wrote: > On Wed, 9 Apr 2014, Clemens Ladisch wrote: > >> Alan Stern wrote: >> > The IN transfer was 1 frame long and scheduled for frame 1123, so its >> > completion indicates that the current frame number is >= 1123. The OUT >> > transfer was 6 frames long and scheduled for frame , so it should >> > have completed in frame 1117. But the timestamps show that the two >> > URBs completed at the same time (only 13 us between them). >> > > Furthermore, I clearly recall Sarah Sharp (the original maintainer for > xhci-hcd) saying that the support for isochronous transfers needed > attention. This may well be an example. > > Alan Stern > Hi, Is there any progress on this or is it low priority? BR Russel -- 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
Fwd: Isochronos audio
-- Forwarded message -- From: Russel Hughes Date: 6 April 2014 11:32 Subject: Isochronos audio To: linux-usb > > Can you describe the actual problem ? How can you trigger it ? What are > you doing when the problem arises ? Do you hear audio glitches or does > the device disconnect ? Do you have a crash ? Does the *same* device > work on other setups ? > > Try to capture a usbmon trace of the failure, that's likely to help. > > -- Hi, I put in a new kernel and get the response from uname -r of 3.14.0-031400-generic, apologies for the pedantry I am not that sure what I am doing. The device behaves exactly the same as default Linux kernel, buffer is erratic not stable like USB 2.0 and audio droputs every couple of seconds. The HDMI audio output does not work after installing the new kernel. I captured some data with usbmon but its a big file 4MB so I can email it separately if you are interested but a sample is as below. sudo cat /sys/kernel/debug/usb/usbmon/2u > /tmp/1.mon.out Thanks Russel 8800d0230400 2003746485 C Zi:2:003:1 0:1:1116:0 1 0:0:3 4 = 00030b00 8800d0230400 2003746493 S Zi:2:003:1 -115:1:1116 1 -18:0:3 4 < 8802115e9540 2003746499 C Ii:2:003:3 0:32 2 = 0002 8802115e9540 2003746514 S Ii:2:003:3 -115:32 2 < 880036e14600 2003747539 C Zo:2:003:1 0:1:1106:0 5 0:0:264 0:264:264 0:528:264 0:792:264 0:1056:264 1320 > 880036e14600 2003747556 S Zo:2:003:1 -115:1:1106 5 -18:0:264 -18:264:270 -18:534:264 -18:798:264 -18:1062:264 1326 = b40e4abb e343b295 4cb72848 bc8d42bd 7341c10b 3ec4943b c2883dc8 9737cc17 8800d0230100 2003747563 C Zi:2:003:1 0:1:1117:0 1 0:0:3 4 = 00030b00 8800d0230100 2003747564 S Zi:2:003:1 -115:1:1117 1 -18:0:3 4 < 8800d0237900 2003748552 C Zi:2:003:1 0:1:1118:0 1 0:0:3 4 = 00030b00 8800d0237900 2003748561 S Zi:2:003:1 -115:1:1118 1 -18:0:3 4 < 8800d0237600 2003749520 C Zi:2:003:1 0:1:1119:0 1 0:0:3 4 = 00030b00 8800d0237600 2003749526 S Zi:2:003:1 -115:1:1119 1 -18:0:3 4 < 8800d0230400 2003750493 C Zi:2:003:1 0:1:1120:0 1 0:0:3 4 = 00030b00 8800d0230400 2003750498 S Zi:2:003:1 -115:1:1120 1 -18:0:3 4 < 8800d0230100 2003751518 C Zi:2:003:1 0:1:1121:0 1 0:0:3 4 = 00030b00 8800d0230100 2003751523 S Zi:2:003:1 -115:1:1121 1 -18:0:3 4 < 8800d0237900 2003752501 C Zi:2:003:1 0:1:1122:0 1 0:0:3 4 = 00030b00 8800d0237900 2003752506 S Zi:2:003:1 -115:1:1122 1 -18:0:3 4 < 880036e15c00 2003753507 C Zo:2:003:1 0:1::0 6 0:0:264 0:264:264 0:528:264 0:792:264 0:1056:264 1584 > 880036e15c00 2003753516 S Zo:2:003:1 -115:1: 5 -18:0:264 -18:264:264 -18:528:264 -18:792:264 -18:1056:264 1320 = 1537ea16 c9e808b1 f60dd5f1 f7970801 e4fdef09 10fab104 f4e00afb c103fbf6 8800d0237600 2003753520 C Zi:2:003:1 0:1:1123:0 1 0:0:3 4 = 00030b00 8800d0237600 2003753521 S Zi:2:003:1 -115:1:1123 1 -18:0:3 4 < 8800d0230400 2003754492 C Zi:2:003:1 0:1:1124:0 1 0:0:3 4 = 00030b00 8800d0230400 2003754494 S Zi:2:003:1 -115:1:1124 1 -18:0:3 4 < 8800d0230100 200371 C Zi:2:003:1 0:1:1125:0 1 0:0:3 4 = 00030b00 8800d0230100 2003755560 S Zi:2:003:1 -115:1:1125 1 -18:0:3 4 < 8800d0237900 2003756552 C Zi:2:003:1 0:1:1126:0 1 0:0:3 4 = 00030b00 8800d0237900 2003756561 S Zi:2:003:1 -115:1:1126 1 -18:0:3 4 < 8800d0237600 2003757557 C Zi:2:003:1 0:1:1127:0 1 0:0:3 4 = 00030b00 8800d0237600 2003757565 S Zi:2:003:1 -115:1:1127 1 -18:0:3 4 < 880036e14000 2003758499 C Zo:2:003:1 0:1:1116:0 5 0:0:264 0:264:264 0:528:264 0:792:264 0:1056:264 1320 > 880036e14000 2003758507 S Zo:2:003:1 -115:1:1116 6 -18:0:264 -18:264:264 -18:528:264 -18:792:264 -18:1056:264 1584 = 1761e712 8ded1cce e21323ec 1264ec08 caf607e0 f7ff1500 0823f703 28fc1409 8800d0230400 2003758511 C Zi:2:003:1 0:1:1128:0 1 0:0:3 4 = 00030b00 8800d0230400 2003758512 S Zi:2:003:1 -115:1:1128 1 -18:0:3 4 < 8800d0230100 2003759550 C Zi:2:003:1 0:1:1129:0 1 0:0:3 4 = 00030b00 8800d0230100 2003759559 S Zi:2:003:1 -115:1:1129 1 -18:0:3 4 < 8800d0237900 2003760554 C Zi:2:003:1 0:1:1130:0 1 0:0:3 4 = 00030b00 8800d0237900 2003760563 S Zi:2:003:1 -115:1:1130 1 -18:0:3 4 < 8800d0237600 2003761552 C Zi:2:003:1 0:1:1131:0 1 0:0:3 4 = 00030b00 8800d0237600 2003761561 S Zi:2:003:1 -115:1:1131 1 -18:0:3 4 < 8800d0230400 2003762512 C Zi:2:003:1 0:1:1132:0 1 0:0:3 4 = 00030b00 8800d0230400 2003762515 S Zi:2:003:1 -115:1:1132 1 -18:0:3 4 < 880036e14600 2003763509 C Zo:2:003:1 0:1:1121:0 5 0:0:264 0:264:270 0:534:264 0:798:264 0:1062:264 1326 > 880036e14600 2003763519 S Zo:2:003:1 -115:1:1121 5 -18:0:264 -18:264:264 -18:528:264 -18:792:264 -18:1056:264 1320 = 26acd81f 9fe02ac2 d423c1db 2f70d027 1fd82b7f d424d5da 28b0d623 35dc2e61 8800d0230100 2003763524 C Zi:2:003:1 0:1:1133:0 1 0:0:3 4 = 00030b00 8800d0230100 2003763526 S Zi:2:003:1 -115:1:1133 1 -18:0:3 4 < 8800d0237900 2003
Re: USB 3.0 Isochronous audio
> > Can you describe the actual problem ? How can you trigger it ? What are > you doing when the problem arises ? Do you hear audio glitches or does > the device disconnect ? Do you have a crash ? Does the *same* device > work on other setups ? > > Try to capture a usbmon trace of the failure, that's likely to help. > > -- > balbi Hi, I put in a new kernel and get the response from uname -r of 3.14.0-031400-generic, apologies for the pedantry I am not that sure what I am doing. The device behaves exactly the same as default Linux kernel, buffer is erratic not stable like USB 2.0 and audio droputs every couple of seconds. The HDMI audio output does not work after installing the new kernel. I captured some data with usbmon but its a big file 4MB so I can email it separately if you are interested but a sample is as below. sudo cat /sys/kernel/debug/usb/usbmon/2u > /tmp/1.mon.out Thanks Russel 8800d0230400 2003746485 C Zi:2:003:1 0:1:1116:0 1 0:0:3 4 = 00030b00 8800d0230400 2003746493 S Zi:2:003:1 -115:1:1116 1 -18:0:3 4 < 8802115e9540 2003746499 C Ii:2:003:3 0:32 2 = 0002 8802115e9540 2003746514 S Ii:2:003:3 -115:32 2 < 880036e14600 2003747539 C Zo:2:003:1 0:1:1106:0 5 0:0:264 0:264:264 0:528:264 0:792:264 0:1056:264 1320 > 880036e14600 2003747556 S Zo:2:003:1 -115:1:1106 5 -18:0:264 -18:264:270 -18:534:264 -18:798:264 -18:1062:264 1326 = b40e4abb e343b295 4cb72848 bc8d42bd 7341c10b 3ec4943b c2883dc8 9737cc17 8800d0230100 2003747563 C Zi:2:003:1 0:1:1117:0 1 0:0:3 4 = 00030b00 8800d0230100 2003747564 S Zi:2:003:1 -115:1:1117 1 -18:0:3 4 < 8800d0237900 2003748552 C Zi:2:003:1 0:1:1118:0 1 0:0:3 4 = 00030b00 8800d0237900 2003748561 S Zi:2:003:1 -115:1:1118 1 -18:0:3 4 < 8800d0237600 2003749520 C Zi:2:003:1 0:1:1119:0 1 0:0:3 4 = 00030b00 8800d0237600 2003749526 S Zi:2:003:1 -115:1:1119 1 -18:0:3 4 < 8800d0230400 2003750493 C Zi:2:003:1 0:1:1120:0 1 0:0:3 4 = 00030b00 8800d0230400 2003750498 S Zi:2:003:1 -115:1:1120 1 -18:0:3 4 < 8800d0230100 2003751518 C Zi:2:003:1 0:1:1121:0 1 0:0:3 4 = 00030b00 8800d0230100 2003751523 S Zi:2:003:1 -115:1:1121 1 -18:0:3 4 < 8800d0237900 2003752501 C Zi:2:003:1 0:1:1122:0 1 0:0:3 4 = 00030b00 8800d0237900 2003752506 S Zi:2:003:1 -115:1:1122 1 -18:0:3 4 < 880036e15c00 2003753507 C Zo:2:003:1 0:1::0 6 0:0:264 0:264:264 0:528:264 0:792:264 0:1056:264 1584 > 880036e15c00 2003753516 S Zo:2:003:1 -115:1: 5 -18:0:264 -18:264:264 -18:528:264 -18:792:264 -18:1056:264 1320 = 1537ea16 c9e808b1 f60dd5f1 f7970801 e4fdef09 10fab104 f4e00afb c103fbf6 8800d0237600 2003753520 C Zi:2:003:1 0:1:1123:0 1 0:0:3 4 = 00030b00 8800d0237600 2003753521 S Zi:2:003:1 -115:1:1123 1 -18:0:3 4 < 8800d0230400 2003754492 C Zi:2:003:1 0:1:1124:0 1 0:0:3 4 = 00030b00 8800d0230400 2003754494 S Zi:2:003:1 -115:1:1124 1 -18:0:3 4 < 8800d0230100 200371 C Zi:2:003:1 0:1:1125:0 1 0:0:3 4 = 00030b00 8800d0230100 2003755560 S Zi:2:003:1 -115:1:1125 1 -18:0:3 4 < 8800d0237900 2003756552 C Zi:2:003:1 0:1:1126:0 1 0:0:3 4 = 00030b00 8800d0237900 2003756561 S Zi:2:003:1 -115:1:1126 1 -18:0:3 4 < 8800d0237600 2003757557 C Zi:2:003:1 0:1:1127:0 1 0:0:3 4 = 00030b00 8800d0237600 2003757565 S Zi:2:003:1 -115:1:1127 1 -18:0:3 4 < 880036e14000 2003758499 C Zo:2:003:1 0:1:1116:0 5 0:0:264 0:264:264 0:528:264 0:792:264 0:1056:264 1320 > 880036e14000 2003758507 S Zo:2:003:1 -115:1:1116 6 -18:0:264 -18:264:264 -18:528:264 -18:792:264 -18:1056:264 1584 = 1761e712 8ded1cce e21323ec 1264ec08 caf607e0 f7ff1500 0823f703 28fc1409 8800d0230400 2003758511 C Zi:2:003:1 0:1:1128:0 1 0:0:3 4 = 00030b00 8800d0230400 2003758512 S Zi:2:003:1 -115:1:1128 1 -18:0:3 4 < 8800d0230100 2003759550 C Zi:2:003:1 0:1:1129:0 1 0:0:3 4 = 00030b00 8800d0230100 2003759559 S Zi:2:003:1 -115:1:1129 1 -18:0:3 4 < 8800d0237900 2003760554 C Zi:2:003:1 0:1:1130:0 1 0:0:3 4 = 00030b00 8800d0237900 2003760563 S Zi:2:003:1 -115:1:1130 1 -18:0:3 4 < 8800d0237600 2003761552 C Zi:2:003:1 0:1:1131:0 1 0:0:3 4 = 00030b00 8800d0237600 2003761561 S Zi:2:003:1 -115:1:1131 1 -18:0:3 4 < 8800d0230400 2003762512 C Zi:2:003:1 0:1:1132:0 1 0:0:3 4 = 00030b00 8800d0230400 2003762515 S Zi:2:003:1 -115:1:1132 1 -18:0:3 4 < 880036e14600 2003763509 C Zo:2:003:1 0:1:1121:0 5 0:0:264 0:264:270 0:534:264 0:798:264 0:1062:264 1326 > 880036e14600 2003763519 S Zo:2:003:1 -115:1:1121 5 -18:0:264 -18:264:264 -18:528:264 -18:792:264 -18:1056:264 1320 = 26acd81f 9fe02ac2 d423c1db 2f70d027 1fd82b7f d424d5da 28b0d623 35dc2e61 8800d0230100 2003763524 C Zi:2:003:1 0:1:1133:0 1 0:0:3 4 = 00030b00 8800d0230100 2003763526 S Zi:2:003:1 -115:1:1133 1 -18:0:3 4 < 8800d0237900 2003764553 C Zi:2:003:1 0:1:1134:0 1 0:0:3 4 = 00030b00 8800d0237900 2003764562 S Zi:2:003:1 -115:1:1134 1 -18:0:3 4 < 8800d0237600 2003765552 C Zi:2:003:1 0:1:1135:0 1 0:0:3 4 = 00030b00 8800d0237600 2003765561 S Zi:2:
Isochronos audio
> > Can you describe the actual problem ? How can you trigger it ? What are > you doing when the problem arises ? Do you hear audio glitches or does > the device disconnect ? Do you have a crash ? Does the *same* device > work on other setups ? > > Try to capture a usbmon trace of the failure, that's likely to help. > > -- Hi, I put in a new kernel and get the response from uname -r of 3.14.0-031400-generic, apologies for the pedantry I am not that sure what I am doing. The device behaves exactly the same as default Linux kernel, buffer is erratic not stable like USB 2.0 and audio droputs every couple of seconds. The HDMI audio output does not work after installing the new kernel. I captured some data with usbmon but its a big file 4MB so I can email it separately if you are interested but a sample is as below. sudo cat /sys/kernel/debug/usb/usbmon/2u > /tmp/1.mon.out Thanks Russel 8800d0230400 2003746485 C Zi:2:003:1 0:1:1116:0 1 0:0:3 4 = 00030b00 8800d0230400 2003746493 S Zi:2:003:1 -115:1:1116 1 -18:0:3 4 < 8802115e9540 2003746499 C Ii:2:003:3 0:32 2 = 0002 8802115e9540 2003746514 S Ii:2:003:3 -115:32 2 < 880036e14600 2003747539 C Zo:2:003:1 0:1:1106:0 5 0:0:264 0:264:264 0:528:264 0:792:264 0:1056:264 1320 > 880036e14600 2003747556 S Zo:2:003:1 -115:1:1106 5 -18:0:264 -18:264:270 -18:534:264 -18:798:264 -18:1062:264 1326 = b40e4abb e343b295 4cb72848 bc8d42bd 7341c10b 3ec4943b c2883dc8 9737cc17 8800d0230100 2003747563 C Zi:2:003:1 0:1:1117:0 1 0:0:3 4 = 00030b00 8800d0230100 2003747564 S Zi:2:003:1 -115:1:1117 1 -18:0:3 4 < 8800d0237900 2003748552 C Zi:2:003:1 0:1:1118:0 1 0:0:3 4 = 00030b00 8800d0237900 2003748561 S Zi:2:003:1 -115:1:1118 1 -18:0:3 4 < 8800d0237600 2003749520 C Zi:2:003:1 0:1:1119:0 1 0:0:3 4 = 00030b00 8800d0237600 2003749526 S Zi:2:003:1 -115:1:1119 1 -18:0:3 4 < 8800d0230400 2003750493 C Zi:2:003:1 0:1:1120:0 1 0:0:3 4 = 00030b00 8800d0230400 2003750498 S Zi:2:003:1 -115:1:1120 1 -18:0:3 4 < 8800d0230100 2003751518 C Zi:2:003:1 0:1:1121:0 1 0:0:3 4 = 00030b00 8800d0230100 2003751523 S Zi:2:003:1 -115:1:1121 1 -18:0:3 4 < 8800d0237900 2003752501 C Zi:2:003:1 0:1:1122:0 1 0:0:3 4 = 00030b00 8800d0237900 2003752506 S Zi:2:003:1 -115:1:1122 1 -18:0:3 4 < 880036e15c00 2003753507 C Zo:2:003:1 0:1::0 6 0:0:264 0:264:264 0:528:264 0:792:264 0:1056:264 1584 > 880036e15c00 2003753516 S Zo:2:003:1 -115:1: 5 -18:0:264 -18:264:264 -18:528:264 -18:792:264 -18:1056:264 1320 = 1537ea16 c9e808b1 f60dd5f1 f7970801 e4fdef09 10fab104 f4e00afb c103fbf6 8800d0237600 2003753520 C Zi:2:003:1 0:1:1123:0 1 0:0:3 4 = 00030b00 8800d0237600 2003753521 S Zi:2:003:1 -115:1:1123 1 -18:0:3 4 < 8800d0230400 2003754492 C Zi:2:003:1 0:1:1124:0 1 0:0:3 4 = 00030b00 8800d0230400 2003754494 S Zi:2:003:1 -115:1:1124 1 -18:0:3 4 < 8800d0230100 200371 C Zi:2:003:1 0:1:1125:0 1 0:0:3 4 = 00030b00 8800d0230100 2003755560 S Zi:2:003:1 -115:1:1125 1 -18:0:3 4 < 8800d0237900 2003756552 C Zi:2:003:1 0:1:1126:0 1 0:0:3 4 = 00030b00 8800d0237900 2003756561 S Zi:2:003:1 -115:1:1126 1 -18:0:3 4 < 8800d0237600 2003757557 C Zi:2:003:1 0:1:1127:0 1 0:0:3 4 = 00030b00 8800d0237600 2003757565 S Zi:2:003:1 -115:1:1127 1 -18:0:3 4 < 880036e14000 2003758499 C Zo:2:003:1 0:1:1116:0 5 0:0:264 0:264:264 0:528:264 0:792:264 0:1056:264 1320 > 880036e14000 2003758507 S Zo:2:003:1 -115:1:1116 6 -18:0:264 -18:264:264 -18:528:264 -18:792:264 -18:1056:264 1584 = 1761e712 8ded1cce e21323ec 1264ec08 caf607e0 f7ff1500 0823f703 28fc1409 8800d0230400 2003758511 C Zi:2:003:1 0:1:1128:0 1 0:0:3 4 = 00030b00 8800d0230400 2003758512 S Zi:2:003:1 -115:1:1128 1 -18:0:3 4 < 8800d0230100 2003759550 C Zi:2:003:1 0:1:1129:0 1 0:0:3 4 = 00030b00 8800d0230100 2003759559 S Zi:2:003:1 -115:1:1129 1 -18:0:3 4 < 8800d0237900 2003760554 C Zi:2:003:1 0:1:1130:0 1 0:0:3 4 = 00030b00 8800d0237900 2003760563 S Zi:2:003:1 -115:1:1130 1 -18:0:3 4 < 8800d0237600 2003761552 C Zi:2:003:1 0:1:1131:0 1 0:0:3 4 = 00030b00 8800d0237600 2003761561 S Zi:2:003:1 -115:1:1131 1 -18:0:3 4 < 8800d0230400 2003762512 C Zi:2:003:1 0:1:1132:0 1 0:0:3 4 = 00030b00 8800d0230400 2003762515 S Zi:2:003:1 -115:1:1132 1 -18:0:3 4 < 880036e14600 2003763509 C Zo:2:003:1 0:1:1121:0 5 0:0:264 0:264:270 0:534:264 0:798:264 0:1062:264 1326 > 880036e14600 2003763519 S Zo:2:003:1 -115:1:1121 5 -18:0:264 -18:264:264 -18:528:264 -18:792:264 -18:1056:264 1320 = 26acd81f 9fe02ac2 d423c1db 2f70d027 1fd82b7f d424d5da 28b0d623 35dc2e61 8800d0230100 2003763524 C Zi:2:003:1 0:1:1133:0 1 0:0:3 4 = 00030b00 8800d0230100 2003763526 S Zi:2:003:1 -115:1:1133 1 -18:0:3 4 < 8800d0237900 2003764553 C Zi:2:003:1 0:1:1134:0 1 0:0:3 4 = 00030b00 8800d0237900 2003764562 S Zi:2:003:1 -115:1:1134 1 -18:0:3 4 < 8800d0237600 2003765552 C Zi:2:003:1 0:1:1135:0 1 0:0:3 4 = 00030b00 8800d0237600 2003765561 S Zi:2:003:1 -
Re: USB 3.0 Isochronous audio
On 31 March 2014 23:00, Greg KH wrote: > On Mon, Mar 31, 2014 at 10:17:20PM +0200, Russel Hughes wrote: >> Hi, >> >> Thanks for replying. I can use a some USB audio devices, ones based >> around the Ti PCM2704 are fine, the DAC I want to use is called an >> audiolab MDAC and as I said it has an elasticity buffer, this sits at >> 50% full and is rock solid, as it should do, on USB 2.0 devices under >> Ubuntu 12.04 LTS fully patched ASRock 330 but not on the 12.04 LTS >> fully patched Intel NUC, where it reaches a maximum of 20% is highly >> erratic and drops out from time to time. The lsmod output is as >> follows: > > I have no idea what kernel release Ubuntu is using, but I suggest, if > you have issues with that specific kernel, filing a bug with Ubuntu. > Otherwise, if you can run a kernel.org release, can you please try 3.14 > and see if that changes anything or not? > > thanks, > > greg k-h I think I have changed the kernel: uname -r 3.14.0-031400-generic But it has exactly the same problem. I will do a usbmon when I get time and post the results back here as requested. I dont know if its of any interest but the HDMI audio stopped working so I had to switch back to the old kernel, then it worked again. Thanks -- 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: USB 3.0 Isochronous audio
> I have no idea what kernel release Ubuntu is using, but I suggest, if > you have issues with that specific kernel, filing a bug with Ubuntu. > Otherwise, if you can run a kernel.org release, can you please try 3.14 > and see if that changes anything or not? > > thanks, > > greg k-h I think I have changed the kernel: uname -r 3.14.0-031400-generic But it has exactly the same problem. I will do a USB trace when I get time and post the results back here as requested. Thanks Russel -- 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: USB 3.0 Isochronous audio
OK sure. I guess there are plenty guides on how to do it out there but if you have one you can recommend it would be good. Its not a disaster if the system gets trashed but it would be nice if it didnt, I did ask on Ubuntu forums but no one replied, thats why I am here!. Thanks Russel On 31 March 2014 23:00, Greg KH wrote: > On Mon, Mar 31, 2014 at 10:17:20PM +0200, Russel Hughes wrote: >> Hi, >> >> Thanks for replying. I can use a some USB audio devices, ones based >> around the Ti PCM2704 are fine, the DAC I want to use is called an >> audiolab MDAC and as I said it has an elasticity buffer, this sits at >> 50% full and is rock solid, as it should do, on USB 2.0 devices under >> Ubuntu 12.04 LTS fully patched ASRock 330 but not on the 12.04 LTS >> fully patched Intel NUC, where it reaches a maximum of 20% is highly >> erratic and drops out from time to time. The lsmod output is as >> follows: > > I have no idea what kernel release Ubuntu is using, but I suggest, if > you have issues with that specific kernel, filing a bug with Ubuntu. > Otherwise, if you can run a kernel.org release, can you please try 3.14 > and see if that changes anything or not? > > thanks, > > greg k-h -- 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: USB 3.0 Isochronous audio
Playing any audio via spotify, youtube, BBC iplayer, XBMC causes the problem. The problem is the audio glitches, its never crashed, as I said the same device works flawlessly on a USB2.0 device amd has done for about two years. Even with no music playing the buffer level changes, the problem. I have seen this which is interesting https://forums.presonus.com/posts/list/33427.page I will try and get usbmon working tomorrow but it seems its a known Intel issue, I dont know if you can manage a software workaround. "Errata 1. USB Isoch In Transfer Error Issue Problem: If a USB full-speed inbound isochronous transaction with a packet length 190 bytes or greater is started near the end of a microframe the PCH may see more than 189 bytes in the next microframe. Implication: If the PCH sees more than 189 bytes for a microframe an error will be sent to software and the isochronous transfer will be lost. If a single data packet is lost no perceptible impact for the end user is expected. Note: Intel has only observed the issue in a synthetic test environment where precise control of packet scheduling is available, and has not observed this failure in its compatibility validation testing. * Isochronous traffic is periodic and cannot be retried thus it is considered good practice for software to schedule isochronous transactions to start at the beginning of a microframe. Known software solutions follow this practice. * To sensitize the system to the issue additional traffic such as other isochronous transactions or retries of asynchronous transactions would be required to push the inbound isochronous transaction to the end of the microframe. Workaround: None. Status: No Plan to Fix." On 31 March 2014 22:32, Felipe Balbi wrote: > On Mon, Mar 31, 2014 at 10:17:20PM +0200, Russel Hughes wrote: >> Hi, >> >> Thanks for replying. I can use a some USB audio devices, ones based >> around the Ti PCM2704 are fine, the DAC I want to use is called an >> audiolab MDAC and as I said it has an elasticity buffer, this sits at >> 50% full and is rock solid, as it should do, on USB 2.0 devices under >> Ubuntu 12.04 LTS fully patched ASRock 330 but not on the 12.04 LTS >> fully patched Intel NUC, where it reaches a maximum of 20% is highly >> erratic and drops out from time to time. The lsmod output is as > > you need to grab information of the error. lsusb alone doesn't provide a > lot of information (unless someone has dealt with the same error in a > NUC). > > Can you describe the actual problem ? How can you trigger it ? What are > you doing when the problem arises ? Do you hear audio glitches or does > the device disconnect ? Do you have a crash ? Does the *same* device > work on other setups ? > > Try to capture a usbmon trace of the failure, that's likely to help. > > -- > balbi -- 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: USB 3.0 Isochronous audio
Hi, Thanks for replying. I can use a some USB audio devices, ones based around the Ti PCM2704 are fine, the DAC I want to use is called an audiolab MDAC and as I said it has an elasticity buffer, this sits at 50% full and is rock solid, as it should do, on USB 2.0 devices under Ubuntu 12.04 LTS fully patched ASRock 330 but not on the 12.04 LTS fully patched Intel NUC, where it reaches a maximum of 20% is highly erratic and drops out from time to time. The lsmod output is as follows: snd_usb_audio 146849 1 snd_usbmidi_lib29477 1 snd_usb_audio hid_generic12540 0 snd_hda_codec_realtek80192 1 snd_hda_codec_hdmi 37463 1 coretemp 13596 0 kvm_intel 137928 0 kvm 452238 1 kvm_intel ghash_clmulni_intel13259 0 aesni_intel55495 0 ablk_helper13597 1 aesni_intel cryptd 20530 3 ghash_clmulni_intel,aesni_intel,ablk_helper lrw13323 1 aesni_intel aes_x86_64 17255 1 aesni_intel xts12951 1 aesni_intel gf128mul 14951 2 lrw,xts snd_hda_intel 44339 5 snd_hda_codec 141761 3 snd_hda_codec_realtek,snd_hda_codec_hdmi,snd_hda_intel snd_hwdep 13668 2 snd_usb_audio,snd_hda_codec microcode 23075 0 snd_pcm 102477 4 snd_usb_audio,snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec snd_seq_midi 13324 0 snd_rawmidi30417 2 snd_usbmidi_lib,snd_seq_midi snd_seq_midi_event 14899 1 snd_seq_midi snd_seq61930 2 snd_seq_midi,snd_seq_midi_event joydev 17613 0 rfcomm 47922 0 snd_timer 29989 2 snd_pcm,snd_seq snd_seq_device 14497 3 snd_seq_midi,snd_rawmidi,snd_seq bnep 18399 2 bluetooth 247324 10 rfcomm,bnep nuvoton_cir17980 0 rc_core26422 1 nuvoton_cir parport_pc 28284 1 ppdev 17113 0 i915 621562 3 snd69533 24 snd_usb_audio,snd_usbmidi_lib,snd_hda_codec_realtek,snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec,snd_hwdep,snd_pcm,snd_rawmidi,snd_seq,snd_timer,snd_seq_device drm_kms_helper 49597 1 i915 mac_hid13253 0 drm 287796 4 i915,drm_kms_helper i2c_algo_bit 13564 1 i915 lpc_ich17144 0 video 19652 1 i915 soundcore 12680 1 snd snd_page_alloc 18798 2 snd_hda_intel,snd_pcm mei45974 0 binfmt_misc17540 1 lp 17799 0 parport46562 3 parport_pc,ppdev,lp hid_logitech 26634 0 ff_memless 13097 1 hid_logitech usbhid 47346 1 hid_logitech hid 105826 3 hid_generic,hid_logitech,usbhid ahci 25879 2 libahci31636 1 ahci e1000e202746 0 On 31 March 2014 22:02, Greg KH wrote: > On Mon, Mar 31, 2014 at 08:44:00AM +0200, Russel Hughes wrote: >> Hi, >> >> Does anyone know when isochronous audio will be implemented for >> USB 3.0 in Linux? > > What specific specification are you referring to that we do not already > support? > > I can use a USB audio device just fine with a USB 3.0 host at the > moment, what exact driver are you having problems with? > > thanks, > > greg k-h -- 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
USB 3.0 Isochronous audio
Hi, Does anyone know when isochronous audio will be implemented for USB 3.0 in Linux? I have asked Intel who make the NUC device I use and they are not interested and on Ubuntu forums got no reply. I have an Audiolab MDAC which cannot be used with USB 3.0 because of this, I have to route the audio via HDMI and out of the TV optical to get sound. USB is better as there is an elasticity buffer on the DAC which means that jitter is lower, I am a sad hi- fi nerd as you will of guessed. I cannot program but I work with hardware and have access to a USB 2.0 bus analyser, I will check if it has been updated to 3.0, so if anyone wants help looking for lost data packets etc, I may be able to help. Thanks in advance! BR -- 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
USB 3.0 Isochronous audio
Hi, Does anyone know when isochronous audio will be implemented for USB 3.0 in Linux? I have asked Intel who make the NUC device I use and they are not interested and on Ubuntu forums got no reply. I have an Audiolab MDAC which cannot be used with USB 3.0 because of this, I have to route the audio via HDMI and out of the TV optical to get sound. USB is better as there is an elasticity buffer on the DAC which means that jitter is lower, I am a sad hi- fi nerd as you will of guessed. I cannot program but I work with hardware and have access to a USB 2.0 bus analyser, I will check if it has been updated to 3.0, so if anyone wants help looking for lost data packets etc, I may be able to help. Thanks in advance! BR Russel -- 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