Bug 230434
| Summary: | [DWC OTG] USB sound card fails to record | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Base System | Reporter: | chris | ||||||||||||
| Component: | usb | Assignee: | Hans Petter Selasky <hselasky> | ||||||||||||
| Status: | Closed FIXED | ||||||||||||||
| Severity: | Affects Only Me | CC: | hselasky | ||||||||||||
| Priority: | --- | ||||||||||||||
| Version: | CURRENT | ||||||||||||||
| Hardware: | arm64 | ||||||||||||||
| OS: | Any | ||||||||||||||
| Attachments: |
|
||||||||||||||
|
Description
chris
2018-08-07 11:21:15 UTC
Hi, No recording endpoints are recognised. There should be a Record: line. uaudio0: Play: 48000 Hz, 2 ch, 16-bit S-LE PCM format, 2x8ms buffer. uaudio0: Play: 44100 Hz, 2 ch, 16-bit S-LE PCM format, 2x8ms buffer. uaudio0: Play: 40000 Hz, 2 ch, 16-bit S-LE PCM format, 2x8ms buffer. uaudio0: Play: 32000 Hz, 2 ch, 16-bit S-LE PCM format, 2x8ms buffer. uaudio0: Play: 24000 Hz, 2 ch, 16-bit S-LE PCM format, 2x8ms buffer. uaudio0: Play: 22050 Hz, 2 ch, 16-bit S-LE PCM format, 2x8ms buffer. uaudio0: Play: 16000 Hz, 2 ch, 16-bit S-LE PCM format, 2x8ms buffer. uaudio0: Play: 11025 Hz, 2 ch, 16-bit S-LE PCM format, 2x8ms buffer. uaudio0: Play: 8000 Hz, 2 ch, 16-bit S-LE PCM format, 2x8ms buffer. uaudio0: No MIDI sequencer. A first step would be to enable: sysctl hw.usb.uaudio_debug=16 before plugging the device and then post the result debug prints. Also a dump of the USB descriptors are appreciated using lsusb from ports. FYI: lsusb is part of /usr/ports/sysutils/usbutils Created attachment 195979 [details]
dmesg output
Created attachment 195980 [details]
lsusb output
Thanks Hans for picking-up this bug for me. Please find debug attachments as requested. Cheers Chris In the debug messages pasted recording is supported: uaudio_attach: audio rev 1.00 uaudio_attach: 8 mixer controls uaudio0: Play: 48000 Hz, 2 ch, 16-bit S-LE PCM format, 2x8ms buffer. uaudio0: Play: 44100 Hz, 2 ch, 16-bit S-LE PCM format, 2x8ms buffer. uaudio0: Play: 40000 Hz, 2 ch, 16-bit S-LE PCM format, 2x8ms buffer. uaudio0: Play: 32000 Hz, 2 ch, 16-bit S-LE PCM format, 2x8ms buffer. uaudio0: Play: 24000 Hz, 2 ch, 16-bit S-LE PCM format, 2x8ms buffer. uaudio0: Play: 22050 Hz, 2 ch, 16-bit S-LE PCM format, 2x8ms buffer. uaudio0: Play: 16000 Hz, 2 ch, 16-bit S-LE PCM format, 2x8ms buffer. uaudio0: Play: 11025 Hz, 2 ch, 16-bit S-LE PCM format, 2x8ms buffer. uaudio0: Play: 8000 Hz, 2 ch, 16-bit S-LE PCM format, 2x8ms buffer. uaudio0: Record: 48000 Hz, 2 ch, 16-bit S-LE PCM format, 2x8ms buffer. uaudio0: Record: 44100 Hz, 2 ch, 16-bit S-LE PCM format, 2x8ms buffer. uaudio0: Record: 40000 Hz, 2 ch, 16-bit S-LE PCM format, 2x8ms buffer. uaudio0: Record: 32000 Hz, 2 ch, 16-bit S-LE PCM format, 2x8ms buffer. uaudio0: Record: 24000 Hz, 2 ch, 16-bit S-LE PCM format, 2x8ms buffer. uaudio0: Record: 22050 Hz, 2 ch, 16-bit S-LE PCM format, 2x8ms buffer. uaudio0: Record: 16000 Hz, 2 ch, 16-bit S-LE PCM format, 2x8ms buffer. uaudio0: Record: 11025 Hz, 2 ch, 16-bit S-LE PCM format, 2x8ms buffer. uaudio0: Record: 8000 Hz, 2 ch, 16-bit S-LE PCM format, 2x8ms buffer. uaudio0: No MIDI sequencer. If you "dd if=/dev/dsp0 of=/dev/null bs=256" does it fail? Try to use 8kHz instead of 48kHz with your app. Does it still fail? The RPi has some limitations what it can do w.r.t USB. In general I recommend high-speed USB audio devices. Your device appears to be full-speed - right? Hi, I tried: dd if=/dev/dsp0 of=/dev/null bs=256 But it failed with: dd: /dev/dsp0: Invalid argument 0+0 records in 0+0 records out 0 bytes transferred in 5.052607 secs (0 bytes/sec) I also have tried sampling at 8kHz with the same problem. Thanks Chris Can you try connecting the device via an external and self-powered USB 2.0 HUB? --HPS I've not got a powered USB hub to test it with. I have tried taking the other devices out of the USB just in case the problem is power related, but have had the same results. The iMic is a USB 2.0 device to answer your earlier question. Chris I tried connecting the USB sound card using a powered USB hub and the problem remains. Can you also trace the USB device while trying to record: usbdump -i usbusX -f Y -s 65536 dd if=/dev/dsp0 of=/dev/null bs=128 --HPS Have I got this right: The soundcard is on usbus0 and is /dev/dsp0.0, so am I right using: usbdump -i usbus0 -f 0.0 -s 65536 The device filter I have wrong, it is 0.7 and the output from usbdump is: 16:54:53.405462 usbus0.7 SUBM-ISOC-EP=00000084,SPD=FULL,NFR=8,SLEN=0,IVAL=0 16:54:53.405472 usbus0.7 DONE-ISOC-EP=00000084,SPD=FULL,NFR=0,SLEN=0,IVAL=0,ERR=TIMEOUT dd output as follows: [tmp]# dd if=/dev/dsp0.0 of=/dev/null bs=128 dd: /dev/dsp0.0: Invalid argument 0+0 records in 0+0 records out 0 bytes transferred in 5.006964 secs (0 bytes/sec) [tmp]# Did you start usbdump before doing dd and after CTRL+C usbdump after dd has exited? Yes, I did this. I could not seem to get the filter expression to work so let it capture all packets and pasted above the output from 0.7. Is this OK? Can you join #bsdusb on EF-net ? No, sorry. I'm a little surprised that you get a timeout that quickly. What is HZ set to? sysctl -a | grep hz If hz=1000, then it should be OK. --HPS I'll give my RPI3 a spin over the weekend and see if I can reproduce this issue. Thanks for your patience Hans.
kern.clockrate: { hz = 1000, tick = 1000, profhz = 8129, stathz = 127 }
kern.hz: 1000
Looks OK.
Hi,
I managed to reproduce the issue. It is a minor issue in the chipdriver DWC OTG.
I'm currently testing some patches. Stay tuned.
--HPS
diff --git a/sys/dev/usb/controller/dwc_otg.c b/sys/dev/usb/controller/dwc_otg.c
index 6bf42b98b7f..5d58e779ff1 100644
--- a/sys/dev/usb/controller/dwc_otg.c
+++ b/sys/dev/usb/controller/dwc_otg.c
@@ -1458,6 +1458,9 @@ dwc_otg_host_data_rx(struct dwc_otg_softc *sc, struct dwc_otg_td *td)
/* check if we are complete */
if (td->tt_xactpos == HCSPLT_XACTPOS_BEGIN) {
goto complete;
+ } else if (td->hcsplt != 0) {
+ /* get next CSPLIT packet */
+ goto receive_pkt;
} else {
/* get more packets */
goto busy;
Created attachment 198213 [details]
Fix for issue
The RPI3 has some limitation on the ISOCHRONOUS schedule, so you might need to set: sysctl dev.pcm.0.rec.vchanrate=32000 sysctl dev.pcm.0.play.vchanrate=32000 In order to use duplex audio! Or get a HIGH-speed USB audio device. --HPS Many thanks indeed Hans for your work. Glad that you could reproduce it. I'll apply your patch and give it a shot on my system here and let you know how things go. Cheers Chris Created attachment 198228 [details]
Updated fix for issue.
Updated the patch a bit with support for full duplex.
Created attachment 198229 [details]
Updated fix for issue (v2)
A commit references this bug: Author: hselasky Date: Tue Oct 16 18:47:13 UTC 2018 New revision: 339388 URL: https://svnweb.freebsd.org/changeset/base/339388 Log: Fix for reception of large full speed isochronous frames via the transaction translator, when using the DWC OTG USB controller driver. Make sure to re-try getting the complete split packets until a DATA0 packet is received. Larger isochronous frames may be split into multiple MDATA packets terminated by a single DATA0 packet. PR: 230434 MFC after: 3 days Approved by: re (gjb) Sponsored by: Mellanox Technologies Changes: head/sys/dev/usb/controller/dwc_otg.c A commit references this bug: Author: hselasky Date: Fri Oct 19 08:38:34 UTC 2018 New revision: 339442 URL: https://svnweb.freebsd.org/changeset/base/339442 Log: MFC r339388: Fix for reception of large full speed isochronous frames via the transaction translator, when using the DWC OTG USB controller driver. Make sure to re-try getting the complete split packets until a DATA0 packet is received. Larger isochronous frames may be split into multiple MDATA packets terminated by a single DATA0 packet. PR: 230434 Sponsored by: Mellanox Technologies Changes: _U stable/11/ stable/11/sys/dev/usb/controller/dwc_otg.c A commit references this bug: Author: hselasky Date: Fri Oct 19 08:40:26 UTC 2018 New revision: 339443 URL: https://svnweb.freebsd.org/changeset/base/339443 Log: MFC r339388: Fix for reception of large full speed isochronous frames via the transaction translator, when using the DWC OTG USB controller driver. Make sure to re-try getting the complete split packets until a DATA0 packet is received. Larger isochronous frames may be split into multiple MDATA packets terminated by a single DATA0 packet. PR: 230434 Sponsored by: Mellanox Technologies Changes: _U stable/10/ stable/10/sys/dev/usb/controller/dwc_otg.c Let me know if this is still an issue. |
