Volumio for Raspberry PI with Experimental Real Time Kernel

In the last times I’ve been researching on how to improve the Sound Quality of Volumio, particularly with USB DACs, trying to squeeze the best out of the Raspberry PI and its USB BUS.

I’ve always been very skeptical when it came to Real-Time kernel usefulness for audio reproduction: my belief was that they were really useful when producing music, and their use in music playback did have little logic reason.
However, on the Raspberry PI, a RT kernel significantly mitigates the USB IRQ issues, and I must admit I’ve been pretty surprised by the sonic results of the tweaks I made.

I’ve also took the chance to add some USB Quirks to enable DSD Direct on a wider range of DACs. For some reasons that I don’t understand, currently enabling DSD direct requires the USB VID\PID of a particular DAC to be added to a list in the Kernel. I really hope in the future the Linux kernel will adopt a better and standardized way of recognizing such capability.

Also, I’ve implemented a patch to handle properly DSD silence, and avoid the nasty bumps when skipping, playing or stopping DSD in DSD Direct mode (it’s not included in 4.9, but it is in 4.10).

So I’m publishing this experimental release to know your feedback, and if you notice any improvement or degradation, compared to previous builds.
I’m trying the most empirical approach, but I am really keen to hear some subjective impressions from you guys.

Please note, this is an experimental release, and it will be excluded from normal update cycles, so if you would like to retain your settings and use future OTA updates, make sure you try this on a spare SD Card. Also make sure, that every time you select an audio device, restart your system for the optimizations to happen (this won’t be necessary in future builds).
Last, this is only compatible with Raspberry PI2 and 3.

You can download it here:
updates.volumio.org/pi/volumiort … pi.img.zip

Enjoy and let me know!

Hi Michelangelo…i dont have a usb dac, but ill try this real time kernell distro…
Thank you very much for your hard job :slight_smile:

After same hours listening music…
In my system everything seems the same as before…all sounds good in my kali, piano 2.1, rpi3.
Maybe, but is certainly psychoacoustic, some instruments seems more present in the central part…
I definitely do not hear pop and crack between one song and the other…in hires songs and dsd.

Dear Michelangelo,

I have just discovered this thread and immediately flashed a new SD card to test the solution with my USB DAC.

Installation was straighforward, apart for the language, mixed of French and English. Not a problem for a development version.

Soundwise, I am just starting the listening and it looks as if this is slightly better. Of course, not easy to make an A to B comparison.

For the moment, tnis is looking promising, there is certainly a small difference. I will take the time to continue the comparison…

Congratulations for your efforts to constantly improve the product!


… i notice that music inventory and update when i add some music is really slow…
Sometime music stop playing or stuttering when i do that…

I am trying to figure out how and where a RTK can help in improving SQ. The use-case of better, or at least more smooth, data throughput on the Pi USB bus I can understand. If a RTK is less prone to interrupts and therefor the USB bus can output its data more steady, this will improve the use of the USB bus especially when the sampling rate is going up (192 and up and also for DSD).

But the way the USB bus is used really depends on the connected USB DAC. The best use should be asynchronous transfer, meaning the DAC is the Master providing some leeway for not so steady datafeeds over the USB bus. Here the impact of a RTK is less I assume. And also off course the same DAC should provide (a very precise) good Master clock so the timing can be at its best providing quality analog output.

Not a lot of DAC’s, even ones with USB input and supporting async data transfer, seem to be running as Master and providing a very good Master clock signal as well. Or at least I can not find enough information/tech specs to check it? Maybe something that could be made visible somewhere in the UI of Volumio to check this?

So in all other cases, the timing of everything is based on some kind of clock signal coming from our PI (or an additional device that does re-clocking using better clocks) embedded into the data transport. This could be on the USB bus or I2C. This is where I am wondering if a RTK can help on improving the timing in these signals as with a RTK things could run in a more steady pace with less (or shorter) interruptions.

Anyone any thoughts on this?

I did several swaps between the two versions, listening the same song this evening and I confirm I can hear a difference. I cannot explain why… :question:


Thank you guys for your reports. I noticed the system is a bit more unstable. Working on this.

As for SQ, I don’t believe there is ANY direct improvement in SQ related to this, but only less dropouts on USB transfer.

Just to clarify, for those of us using i2s DAC’s is there any real advantage to use this version over the main stable one or are the changes only useful/noticeable to those using USB DAC’s?

Sent from my iPhone using Tapatalk Pro

USB only

Verzonden vanaf mijn iPhone met Tapatalk

I continue the comparisons.

First, I have more interruptions with the real time kernel than with the latest standard version of Volumio.

Then, I continue to identify a difference in Sound quality. It might be an illusion, but it is also the opinion of my wife. Quite strange…

Is this real time kernel version subjet to futur update?


I am also getting very strange results with this kernel, and I can’t seem to be able to fine tune it in a way that the whole system is stable with a wide variety of devices.
So I will continue to do testing and release a new image when I’ve found a better balance

I am using it with a modified hfb dac pro. It works ok. Had some dropouts streaming from bubbleupnp…with squeezebox server on pc… could be my network…

After having experienced many drop outs, I tried to modify buffer values and got a crash. Finally restarted 3 hours ago and works perfectly since, no drop-outs and super sound !


Do not give up!


What are the values which give you the best results?

Strangely, the same as the defaukt values, 8Mb, 10s, but different behaviour, as if despite displaying originally 8 Mb, the setup was in fact different…