finally usb audio problems affecting the Pi, have been solved! For those of you seeking a Raspberry Pi Usb Audio fix, you’re in the right place!  I was compulsively lurking this thread hoping that the foundation would eventually find a fix for the usb issue. What was it?

Well, to make it simple, when the usb bus of the pi was receiving lot of i\o requests, it cannot satisfy them all, and as a result part of the data travelling trough usb was lost. So, while communicating with a usb dac , if the file being played was more than 44/16 the usb bus was overwhelmed and some parts of the data (packets, jargon comes in finally) was lost. If you google for packet loss, you can figure out what was happening.

I’ve been investigating a lot on the matter, hoping to find a Raspberry Pi usb audio fix , tried almost everything. But this was in the hands of the foundation, since there is no extensive documentation available.

Finally, the Raspberry Pi usb Audio Fix came on Thu May 09, 2013 9:19 am, from gsh (which has my imperiture gratitude)

Basically, this updates some part of the pi firmware and kernel, via rpi-update (this is an experimental branch you won’t find on the master branch of rpi-update by hexxeh 

For those of you on RaspyFi, update is hassle free since you already have rpi-update up and running. Just do this to enable the Raspberry Pi Usb Audio Fix:

sudo apt-get install git-core binutils

sudo BRANCH=fiq_split rpi-update

Let it run, it will need almost 20 minutes to complete. In case you’re receiving some errors, just retry. Sometimes the git servers are not able to face the requests of thousands users simoultaneusly.

Once it’s done, and you’re not getting any error, just reboot.

Now, it’s time to enable bit perfect playback on RaspyFi via mpd.conf

sudo nano /etc/mpd.conf

the line:

format “44100:16:2″ # optional

becomes

#format “44100:16:2″ # optional

ctrl + x to save.

Now, we’ll restart mpd:

sudo /etc/init.d/mpd restart

Now, play and enjoy! Files >44/16 will be played without glitches, and I hope that async dacs will work flawlessly as well! I cannot confirm this by now since I don’t have any async to the test this Raspberry Pi usb audio fix for them… But please let me know via comments below.

To check if your Pi now resides in Bit Perfect heaven just type, while playing:

cat /proc/asound/card0/pcm0p/sub0/hw_params

The output will show you current bit rate and bit depth, that should be the same as the file. Please note that if a bit rate/bit depth is not supported by your dac, mpd will automatically resample it to  the nearest supported one.

Here, an example (showing different bitrates/bitdepths, with perfect sound)

Raspberry Pi in bit perfect mode

Obviously, this raspberry pi usb audio fix will be implemented and working out of the box in next Release of RaspyFi, which is in its final stage of development.

This raspberry pi audio fix, also can be excecuted on plain Raspbian and all the other distros out there. Just type that:

sudo apt-get install git-core
sudo wget http://goo.gl/1BOfJ -O /usr/bin/rpi-update && sudo chmod +x /usr/bin/rpi-update
sudo BRANCH=fiq_split rpi-update

Et voilà, you’re done! Please let me know if it works for you, and if you got some troubles doing it !

UPDATE FOR SAMBA USERS

As suggested by Klinkt Beter and Carlo Bernardini this fixes the samba issues for async dac users. With my new xmos to i2s dac  and this fix I don’t have any stuttering at 24/96 , some reports this works well with 24/192 as well. So edit /etc/auto.nas as follows:

Nas    -fstype=cifs,file_mode=0777,dir_mode=0777,iocharset=utf8,sec=ntlm,rsize=2048,wsize=4096,cache=strict,username=pi,password=    ://192.168.nasip/sharename

L'articolo Raspberry Pi Usb Audio fix sembra essere il primo su RaspyFi.

Hey,

I’m experiencing audio stutter while playing movies via the Raspberry Pi to the TV. I used to have the 1080p videos buffering all the time, but I fixed by switching my shares from Samba to NFS, using Hanewin NFS Server. That fixed all the buffering issues and makes the Pi read the shares much, much faster.

http://openelec.tv/forum/134-usage/40394-audio-stuttering

I’m also having problems with RaspyFI, when i comment out the line

format          ”44100:16:2″    # optional

in order to avoi resampling (you remember Audiophilia Hysterica obliges you to think resampling is evil??) I get audio stuttering, especially with flac with samplerate higher than redbook standards . I do really think this is related to an driver issue of the Soc controlling both ethernet and USB.

The main theory circulating on the net states that usb related issues (which can affect wi-fi dongles transfer, keyboard and mouse imputs etc etc) are due to some drivers problems which manifestates themselfs under heavy stress of usb\ethernet pathways, in conjunction and in some cases alone. More precisely there seems that there is some packet loss:

- USB congestion:our devices work in full-speed (USB 1.1 12 Mbit/s) and transmit at max 1 packet of 64 bytes each frame (64 Kb/s). We have analyse the transfer with and USB analyser and ALL packets are correctly transmitted over the wire (no bus reset, no invalid packet, the USB host ack all packet). this mean that the USB Host controller of the raspberry Pi as correctly received and ack the missing USB packet.Our conclusion is that or the libusb or the linux kernel drop some packets and do not raise any error.
We have found a serious issue on the raspberry PI USB stack (or at last the HID USB stack). We produce USB device and have found that we often get missing packet.
We have create an specific firmware illustrate the problem. This debug protocol is very simple the Raspberry will send one packet of 64 bytes, then the device will start a burst of USB transaction. Our USB device work in full speed (USB 1.1) and follow the HID protocol. All packets have the same size (64 bytes). the first uint32_t will contain the current packet number and the second uint32_t will contain the number of packet to send. Each packet is numbered and we stop after burst of 4096 packet of on the first missing packet.

The debug program call libusb-1.0, and will look for one of our device with the debug firmware, then send one USB packet to the device to start the burst. Then we will wait for all packet and check that all packet are send. You can download the source here http://www.yoctopuce.com/tmp/debug_libusb.zip

We have test this code and firmware on many linux platform (i386 and x86_64), and on a ARM based NAS (QNAP TS-219P II). We never get any missing packet. but on the Raspberry PI we always get missing packets. We have check with a USB analyser that the missing packet is correctly sent on the wire (the packet has been correctly acked by the Raspberry PI USB host). It seems that the packet is lost by the Raspberry PI firmware.

http://www.raspberrypi.org/phpBB3/viewtopic.php?f=28&t=5249

In addition to this:

The USB driver may not be fixable, the jury is still out on this one. There are three key problems:

1) Documentation on the Broadcom USB controller is proprietary and is not made openly available by the Raspberry Pi Foundation.

2) The USB core for the Broadcom SoC was bought from a 3rd party, and we are told that not even Broadcom has full documentation, nor understands the driver.

3) The Foundation has discovered that the controller and its driver expect realtime response from the ARM core, and if Linux’s non-realtime scheduling doesn’t respond in 1 ms, a split transaction USB event can be dropped. Not surprisingly, this occurs regularly and produces lost mouse clicks, stuck keyboard keys, etc..

That’s a pretty nasty combination of problems, and it means that assuming that it’s fixable may not be a safe prediction. We’ll have to wait and see.

For the time being though, USB and networking (which is implemented over USB) have a large catalogue of issues and incompatibilities. All boards have this inherent problem but YMMV on whether the issues bite you, as it depends on exactly what devices you have connnected and what you’re doing with the board.

In addition to the above faults, the community discovered a PCB track layout error on the board which causes a proportion of the USB chips to overheat owing to an incorrect connection. It doesn’t appear to be critical but wastes power and the heat may shorten board or device lifetime.

Relations are very tense on the forum, and the Foundation has banned people who express their concern about the faults.

http://hardware.slashdot.org/story/12/08/24/2228251/serious-problems-with-usb-and-ethernet-on-the-raspberry-pi

 

So what happens? Under heavy load some of our precious binary vives is lost and never reaches our fancy USB Dac. Setting the resample mode seems to avoid it because of less bandwith is required to stream the audio to the dac, but we don’t want this as we are:

1- Applying some post processing to our audio stream (which, I remember should be evil to us…)
2- Making our hi-res flac library very sad
3- Degrading our listening experience as it is non-bit- perfect (wheter this is perceptible or not, still I don’t know… but we are damn audio purity integralists, aren’t we?)

But, is there a light out of the tunnel? Of course yes, theorethically at least.

As you can find out from that quote:

3) The Foundation has discovered that the controller and its driver expect realtime response from the ARM core, and if Linux’s non-realtime scheduling doesn’t respond in 1 ms, a split transaction USB event can be dropped. Not surprisingly, this occurs regularly and produces lost mouse clicks, stuck keyboard keys, etc..

 

So, if we succeed in compiling a real-time kernel, hopefully out problem will be solved and finally we’ll have bit perfect reproducion. This is already in process, as a superuser from tforumhifi il helping while compiling a custom real-time kernel for RaspyFi, you can follow the iter here on the RaspyFi thread:

http://www.tforumhifi.com/t32285-raspyfi-raspberry-pi-voyage-mpd-progetto-per-un-ottima-sorgente-low-cost

Meanwhile, a possible solution for audio stuttering via usb is made possible by setting the Usb transfer rate to USB 1.1 and setting it in full mode:

We have run some tests today to validate the tentative fixes.

First we have run rpi-update to get the latest fix. Here is my cmdline.txt and the kernel version

CODE: 

root@raspberrypi:/home/pi# more /boot/cmdline.txt
dwc_otg.lpm_enable=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait
root@raspberrypi:/home/pi# uname -a
Linux raspberrypi 3.2.27+ #160 PREEMPT Mon Sep 17 23:18:42 BST 2012 armv6l GNU/Linux


As expected, Gordon fix does not completely solve the issue of packet loss in this case, but the packet loss seems to happen far less frequently (I have been able to stress the PI for several minutes before I get a missing packet).

Then we have added the dwc_otg.speed=1 parameter to force USB to work only in full speed mode (speed of USB 1.1). This solved the issue. This confirms that the PI has some trouble to handle USB 1.1 devices behind an USB 2.0 hub, but forcing the USB to work in full speed mode completely solves the packet loss for our USB 1.1 devices.

Our working config:

CODE: 

root@raspberrypi:/home/pi# more /boot/cmdline.txt
dwc_otg.lpm_enable=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 dwc_otg.speed=
1 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait
root@raspberrypi:/home/pi# uname -a
Linux raspberrypi 3.2.27+ 

http://www.raspberrypi.org/phpBB3/viewtopic.php?f=28&t=5249&start=200

This is done byadding the dwc_otg.speed=1 parameter to force USB to work only in full speed mode:

sudo nano /boot/cmdline.txt

and adding dwc_otg.speed=1 in the text. ctrl +x, y and reboot

adding the dwc_otg.speed=1 parameter to force USB to work only in full speed mode

Some reported this solution as working, It’s worth trying… I’ll let you know…

Then a final option is this, that prevents kernel panic by setting always free quote of memory and setting the Soc in turbo mode.

Just to report, I had exactly the same error and I solved with:

• vm.min_free_kbytes = 32768 in /etc/sysctl.conf
• smsc95xx.turbo_mode=N in /boot/cmdline.txt

Remember that with turbo mode enabled you are seriously risking to corrupt your SD card…

So, that’s all about USB problems with the PI, I’ll upgrade this post with new informations when they’ll come out.

L'articolo Anatomy of a PI – USB Audio quality and related issues on Pi sembra essere il primo su RaspyFi.