USB Audio broken in kernel 3.18.7+ #888
Comments
|
|
|
Looks like the latest 3.12 works, the oldest 3.18 does not: Ran: got: Audio works Ran got: Audio broken |
|
Are you able to test the USB on a different platform (e.g. x86) with 3.18 kernel? The point where it broke was switching to a newer upstream kernel rather than a change to any Pi specific code. It may be this is a common problem for that sound card with newer kernel versions. Could be worth searching for similar problems on other platforms, in case there are known patches or workarounds. |
|
Testing on x86 is not something that I can do anytime soon, though I'll try to figure out a way to do that.... I have looked through a lot of Audio sites, and it's hard to isolate the issues mentioned there, b/c getting USB audio working on Ubuntu seems to be pretty confusing in the first place.... But thanks for that feedback. I will try to do more digging, and see if I can make any progress. In my case, the 3.12.x kernel is not really a problem, so I'll admit that my motivation here is pretty low. Again, let me know if there are other things you'd like me to check, and if I can get an x86 machine running 3.18 I'll post results here. |
|
For reference, can you post a At this point I'm not convinced this is a Pi-specific issue, namely because recent updates should have absolutely no effect on Pi 1 USB performance. |
|
Cannot figure out which device it is, as the manufacturer is not showing up, but here are the 2 possibilities: |
|
USB audio working Hardware : BCM2708 Linux raspberrypi 3.18.9 |
|
@Halloran With audio playing (either MPD or aplay) can you post the output of |
|
@Halloran I've just noticed that the device is likely to use a High-Speed chipset (CM6631A). Can you post a |
|
I can second this USB audio issue. I had to downgrade my kernel to 3.12 to get USB audio to work. BTW, I am also using a Schiit Modi USB DAC. Anything beyond 3.12 breaks the audio into crackles and corruption/noise. This might have a connection with the nrpacks option in the snd-usb-audio module. I noticed that this option is no longer supported in the latest kernels. According to modinfo, this sets the: Max. number of packets per URB. (int). Setting this to "nrpacks=1" should allow latencies in the area of 4-6 msecs. So if it shows up in the kernel as a valid parameter, then all is well: modinfo snd-usb-audio | grep ^parm:If nrpacks isn't available, then USB audio doesn't seem to work with the Schiit Modi DAC; this option has been recommended for other popular USB DACs too. I am not sure, but it appears that the nrpacks option was removed as the configuration for setting the number of packets per URB has been made automatic, hence this is no longer needed. Clearly something seems to be going wrong with this new implementation, or perhaps I am missing a replacement bit of configuration for the new kernels. Need to investigate a bit more |
This would seem to be related to buffer settings in the audio subsystem have you tried upping buffer time and period count / buffer size for reliable usb audio try periodCount=5 bufferTime=113378, |
|
@pssc @sanjibm It it unlikely that these module parameters need altering from defaults. With 3.18 in the wild and packaged for the latest release of Raspbian, if these changes caused failures across all usb-audio devices then the entire world would be screaming on the forums. As of 3.18 (actually as of 3.13) the nrpacks parameter is redundant because the driver has a notionally saner algorithm for calculating the number of URBs required. Both the reported problems are with a specific type of DAC. This DAC is unusual in being a high-speed device. There are differences with handling of packet intervals for high-speed Isochronous devices, which a move to 3.18 may have caused to change. |
|
ok well event with my low speed devices I had to alter the application settings (not kernel) to get sane usb audio, if the system was under any load. I could also distort the USB audio by altering the spi bus frequency for the piftft screen (but I think that’s a different issue) |
|
@P33M I've had to travel so do not have access to the machine at the moment. Will get you the info you requested above, but it might be a couple of days. |
|
Looking at one of my home PI's the least tolerant device I have was a |
PiTFT (fbtft driver) and USB audio has been problematic: https://forums.adafruit.com/viewtopic.php?f=47&t=63696 |
|
@notro Yes this tallies with my experance I have reliable operation uning usb audio and pitft as long as I dont alter the spi frequency ifrom 25Mhz and drop the fps=~12 to reflect this altering the spi frquency allways produced bad audio event with low fps options. I am running a squeezeplay variant for audio and visual as well as fbcp(altered to copy for the fps the pitft is running at) to mirror onto the pitft and external usb sound of differnt variaties as well as via hdmi though and amp on one of my pi's |
|
@notro my though was that the ALSA or the USB driver was reliant on the interrupt from the 25Mhz timer for some operation. |
|
I have the HDMI active for both audio and visual , as well as the fbtft and external USB sound, so that may well be enough to trigger a SRAM congestion issue msperl/spi-bcm2835#13 increasing the timer speed without raising the fps from 12, triggers the issues. |
|
With kernel at 3.18.3+ (audio is broken) With kernel at 3.12.36+ (audio working fine) Don't see any difference here. |
|
Here is the lsusb -t: |
|
@P33M your comment:
seems the logical path to me. Is there any way to see packet handling intervals? Or to manually set them? |
|
The claimed interval is displayed in the output of the sysfs node (alternate setting for the device). Whether this actually what's coming out of the USB port is a different matter entirely. As you can see, there's no difference in the playback settings between 3.12 and 3.18. I think at this point it needs one of these devices + the USB analyser to work out what's going on. |
|
OK. I definitely do not have access to a USB analyzer. Sorry. Let me know if there's anything further I can do to help. |
|
I was meaning R-Pi's resident analyser. I've bought one of these DACs for inspection, as it may be common to all USB2.0 HS USB audio devices. |
|
Try change use_mmap yes to no |
|
The use_mmap param is not present in my mpd.conf, and the mpd documentation suggests that the default is no, but I will give it a try and post the results. In the meantime, thanks for the suggestion! |
|
I now have a Schitt Modi 2. Interestingly, there's a switch on the back that puts the device in "expert" mode. It changes the descriptors like so: |
|
|
This is the output on a B+ with 3.18: On 3.12, I note that the audio actually plays ridiculously fast. Yep, it's broken. There's some substantial weirdness with the packet intervals. On 3.12, I get a packet every microframe (which is totally wrong) but it's somewhat consistent. On 3.18, I get 3-4 packets every 8 microframes, which is even more wrong. |
|
@Halloran Can you try using the device with dwc_otg.fiq_fsm_enable=0? Or alternatively if your keyboard starts to play up, substitute |
|
Happy to give that a try. Where/how do I configure that? |
|
Add the parameter to /boot/cmdline.txt and reboot. |
|
Yup. That works. What are the implications of that? |
|
The fiq_fsm handler is incorrectly performing transfers to high-speed isoc OUT endpoints. It appears that it's blindly transferring data every microframe instead of strided per 2^(n-1) microframes. With Isoc IN endpoints, you can request data every microframe and the device just responds as-and-when. This is why nrpacks=1 worked - one isochronous transfer per URB which hid the bug. Without FIQ support, microframe jitter will cause variations in timing of the OUT packets which will probably cause sample rate skew. I'll look at implementing strided transfer support. |
|
OK. Going back to the 3.12 kernel. Happy to test things out to help. And many thanks for working on this. |
|
@Halloran has your issue been resolved? If so, please close this issue. Thanks. |
|
@Ruffio am I correct that you are asking if the issue is resolved in the 4.1 kernel? Or is there a 3 series kernel that I should be testing? |
|
@Halloran I would test with latest version (4.4) |
|
@Ruffio will try to give that a go sometime this week. Sorry to have left this open so long. |
|
Updated kernel to 4.4.17+ and the issue is resolved. |
I run an RPi as an audio server: mpd 0.19.7 using ALSA to output to a Schiit Modi USB DAC, serving MP3's and FLAC files.
Recently, I ran apt-get update, apt-get upgrade, and my kernel went from 3.12.28+ to 3.18.7+, and this completely broke the audio output. Audio was being output more or less as white noise, not as slightly distorted, and this was the case with the aplay utility as well as with MPD. After a lot of troubleshooting with MPD, ALSA, etc., I used rpi-update to downgrade to the 3.12.28+ kernel, and all is working fine....
No idea it this is limited to USB audio, or if the problem might be deeper, but wanted to report it. Am happy to help with more system information, etc.
The text was updated successfully, but these errors were encountered: