The Digi+ should eliminate the USB subsystem in the RPi altogether, receiving data via the I²S interface. So you would be taking two USB conversions out of the chain. I hope that will translate into better SQ, but we shall see.

Great stuff, Tom. Let us know what you did. Are you finding much difference between Volumio and Rune in terms of sound quality? I ask, since they all fundamentally seem to use MPD as the replay engine.

Interesting - glitches were obvious on USB playback with Volumio v1.41 into the Caiman-II as-is, but went away once I performed the Linux upgrades to 'Jessie' (although that was a bit naughty as I risked breaking things - RPi have their own upgrades available). However, I'm looking forward to ditching USB as an interface altogether.

Yes everything I looked at pointed towards its being highly device dependent, so it wouldn't necessarily be surprisingly if we had different results with different USB interfaces.
However, although I updated Linux, this was to the latest Wheezy. To test then, I'll update to Jessie and stop overclocking - maybe that will crack it too, and without potentially frying the CPU!

Eliminating USB glitches


So, as I mentioned above, at the beginning of the week I set myself the task of eliminating the glitches that had been a mainstay of my Pi experience up to that point. I had no idea what the cause could be, but some research suggested that this was a common problem, and that there were a variety of settings that I could play with to try and fix it. Here are some things that I tried:

Increasing playback buffer in Volumio

Access the 'Playback' screen via Menu > Playback, and look for the ‘General music daemon options’ header. Here, it’s possible to increase the size of the audio buffer – which by default is set to 2k; ‘12 seconds of CD-quality audio’ – and to determine how much of the buffer is filled before play – 10% by default.



I was a little unsure about increasing either of these, since I'd previously read that smaller buffers yield better results, but in any case this had no effect on the glitches. In hindsight, this was to be expected, since the problem was glitching, rather than dropouts or stuttering.

Changing the kernel profile in Volumio

Volumio has a number of kernel profiles, which differ from one another with respect to certain kernel parameters, in ways which can make for audible differences, but without actually altering the information being streamed (all deliver bitperfect playback). Access the 'System' page via Menu > System and look for the 'Sound Quality Tweaks' header.



There are five profiles to choose from, and I tried out all of them. My impression (though I did not make a rigorous count) was that there were fewer glitches under ACX, but that the rest were either on a par with the default setting or worse. This was a little progress, but not nearly enough.

Changing the NAS mount rsize/wsize

When adding a new mount, there are some advanced options, which are hidden by default, and which allow you to alter the rsize/wsize – that is, the size of the chunks which the Pi reads/writes from/to the NAS in a single network transaction.



I’d found a thread on the Volumio forums, in which the author recommends setting them higher than the default of 8K:

volumio.org/forum/experience-getting-volumio-going-t746.html

And so I looked into what the maximum could be for a CIFS mount, which is apparently 127k (=130048), and I gave this a go. It didn’t seem to have any positive effect – indeed, the glitching seemed to become even more frequent. I then found another thread, in which Michaelangelo – Volumio’s author – advises a user to reduce the rsize/wsize from the default to combat pops and clicks. So next, as per the image above, I tried reducing them to the minimum of 2k (=2048), which seemed to reduce the frequency of the glitching, but without curing it. Seemingly, there are no other settings within Volumio to experiment with, so my attention shifted to the configuration of the Pi itself.

Reconfiguring the Pi

I found a handy thread on the RPi forums, which suggests a couple of solutions (see ‘Workarounds’ at the end of the page):

www.raspberrypi.org/forums/viewtopic.php?f=28&t=53832

Some of these fixes are also discussed in a thread on the Volumio forums:

volumio.org/forum/fixes-for-common-usb-dac-problems-with-rpi-t328.html

I noted in the latter that one fix mentioned by the former – using the driver option "snd-usb-audio nrpacks=1" in /etc/modprobe.d/options – had already been implemented within Volumio, and could be ignored. So, first I tried turning off the driver option for fiq_split by editing /boot/cmdline.txt, via the command:

sudo nano /boot/cmdline.txt
And adding:

dwc_otg.fiq_split_enable=0
No effect. So next I tried unbinding the usb-hid driver from the USB device. This was a little fiddly, I first needed to find out the unique bus ID of the relevant USB device – in my case, the Audiophilleo2. For some devices, this will be displayed in the RPi’s boot log, which can be viewed via the command.

dmesg
But in my case, the ID didn't show up in the bootlog, so - after a little digging - I installed a small program called hwinfo, which can provide in depth info concerning a system's hardware. I installed it via the command:

sudo apt-get install hwinfo
And then many lines of hardware info were spewed, following the command:

hwinfo
Here's a shot of the relevant part for me:



This indicates that the device ID is 1-1.3:1.1. With this in hand, I was able to unbind the USB hid driver, via the command:

echo -n "1-1.3:1.1" > /sys/bus/usb/drivers/usbhid/unbind
Note, supposing this worked, it would need redoing with each new boot. But alas, it had no effect. In hindsight, this is unsurprising, since apparently the usbhid interface is typically used for applying volume settings, and the AP2 doesn’t have a volume control, so it's likely that it doesn't make use of the interface.

Next, I tried forcing the Pi from USB 2.0 to USB 1.1, by adding "dwc_otg.speed=1" to boot/cmdline.txt. This worked! No more glitches. But unfortunately, it’s not an attractive solution for me, since forcing to USB 1.1 would limit me to nothing above 16 bit files, and since I have a fair few files at 24/48 and above, this is no good. Still, it was progress of a sort.

I then found two pages which proved very useful:

www.raspyfi.com/anatomy-of-a-pi-usb-audio-quality-and-related-issues-on-pi/

This gives some background to the Pi's USB issues, which are apparently related to some driver problems.

wiki.linuxaudio.org/wiki/raspberrypi

This offers advice on setting up the Pi for use as a DAW (digital audio workstation). It’s on this page that I found advice concerning overclocking. For those who are new to the term, overclocking is a matter of setting a system's CPU to run at a speed that's higher than the speed at which it’s supplied. I discovered that the Pi comes with a number of preconfigured overclocking options, which can be accessed via the command:

raspi-config
Which yields the following menu screen:



And 7 yields an overclocking submenu:



I experimented with the various settings, and found that I still experienced glitches with all of them, bar ‘Turbo’. But happily, with turbo enabled, I get completely glitch-free playback, even streaming 24/96 over wifi (and with the small default buffers). For good measure, I also disabled CPU scaling. This is enabled automatically when the CPU is overclocked, and sets the Pi to adjust its CPU speed dynamically, according to workload, and this can also result in glitches as it changes up or down. This is disabled via the command:

echo -n performance \
| sudo tee /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
Note, this has to be re-disabled with each new boot, so I might try to figure out how include the command in a script that runs automatically on booting.

WARNING: Overclocking comes with a risk of overheating. I've since found plenty of reports of users operating in turbo mode without any problems, and I've not noticed it running especially hot. But to be on the safe side, I might add heatsinks to the CPU and RAM chips, and/or switch from the Ninja to a case that's better ventilated, like this one.

I’m very pleased to have eliminated the glitches, as they presented a real stumbling block to my even considering using the Pi regularly in my main system. The Pi is now a much more serious contender, and I can put it head-to-head against my PC

Yes I suspect I will. I've ordered the other case, and will see how that impacts on the CPU temperature. I've just checked this via the command:

/opt/vc/bin/vcgencmd measure_temp
and right now it's at 48.7, after having been on all day. Nothing to worry about really, but still I like the idea of keeping it cool, just to play it safe.

Something else you might like to look at in the config menu is Advanced Options > Memory Split. Here, you can assign a set amount of RAM to be reserved for the GPU. This is set at 16 mb by default, and I figure this can be safely bumped down to 8, given the very minimal use that this kind of application will present to the GPU.

Something else you might find interesting; here's the CPU load while playing a red-book flac.



And here it is playing a 24/96 version of the same track:



These are both notably lower than the corresponding results that you posted, presumably due to the CPU being overclocked.

I've just discovered that dynamic CPU frequency scaling can be disabled simply by adding a line to /boot/config.txt. So, edit config.txt via the command:

sudo nano /boot/config.txt
And add the following immediately below the last line.

force_turbo=1
Job done!

Great stuff, Tom. So batteries don't always win! I am awaiting the arrival of my Digi+, but meanwhile I played with overclocking and turbo=1 and I like what I hear. I only went for the 900MHz overclock, but it's all good so far. I don't get any USB clicks anyway, and look forward to hearing what the S/PDIF output can do.