One of the things I couldn’t get working at the time of writing my last article on the CubieTruck Sinc Upsampling Sound Server, was the src-sinc-medium-quality resampling algorithm.

I really wanted to do this as it is considerably better than the lowest quality src-sinc-fastest algorithm – which is itself a massive improvement on CD quality.

I’ve had a few goes at various ways to solve this over the last month, but have eventually found an easy way to do it, which I will have a look at here.

What was the actual problem?

Even though the CPU wasn’t being overly taxed, there were far too many dropouts for comfortable listening. These dropouts went away when using the lowest quality sinc algorithm. Using this, the system was hardly being pushed (one core at around 25%), so surely there was a way to improve things.

What sort of difference does it make to the sound?

Given that we are starting from a point already above CD quality, the difference between the two sinc algorithms is a general improvement.  The main hardness from CD replay is removed, the top end is softened and the realism of instruments is further improved (especially cymbals and drums). With CD, I find the harshness seems to jump out forwards from the speakers, so this makes the music sit a bit further back. At low volumes, it is easier to have something unobtrusive, at higher volumes of course, everything is more obvious.

How is it fixed? – An attempt to use real-time scheduling

Credit is due to this blog which I am adapting here for the CubieTruck. Essentially the problem is an inadequacy in pulseaudio; we need to make it real time and to change the scheduling algorithm.

Add mpd user to the real-time groups:

groups mpd shows the mpd user (the user that runs the music player daemon process) is only a member of the audio group. We need to add a new pulse-rt group and add mpd to that along with the existing pulse-access group:

sudo groupadd pulse-rt
sudo usermod -a -G pulse-access,pulse-rt mpd

Then add the realtime configuration of the pulse-rt group:

sudo vi /etc/security/limits.conf

add these entries:

@pulse-rt       -       rtprio          99
@pulse-rt       -       nice            -20

Then go back to the pulseaudio configuration:

sudo vi /etc/pulse/daemon.conf

Add or amend what’s there to get these entries:

cpu-limit = no
high-priority = yes
nice-level = -11
realtime-scheduling = yes
realtime-priority = 8

However I think this is not actually setting the real time priorities since when I do (after restarting the services):

ps -eo rtprio,pri,nice,cmd

to show the real time priority, the normal priority, the nice value and the command, I get this in the output, with nothing in the first column:

 -  19   0 /usr/bin/mpd /etc/mpd.conf
 -  19   0 /usr/bin/pulseaudio --start --log-target=syslog

There might be some real time thing happening as there are a couple of processes with 99 in the first column – they have ridiculous priorities though (139), so they are likely to be a couple of deep system processes. Maybe this is not a feature supported by this kernel or processor / operating system combination. The nice-level of -11 seems to be ignored as well.

The manual (man pulse-daemon.conf) says “Please note that only the IO threads of PulseAudio are made real-time. The controlling thread is left a normally scheduled thread.” This may be what is being shown here. The only way I tried and got this working is when doing this section and the next, I did not attempt any other combinations.

The magic

Maybe this is the only thing needed – apparently a newer pulseaudio scheduling algorithm has created this problem. So we need to tell pulseaudio to go back to an earlier version:

sudo vi /etc/pulse/default.conf

Find the line

load-module module-udev-detect

and edit to be

load-module module-udev-detect tsched=0

Then we need to change to use the new algorithm:

sudo vi /etc/pulse/daemon.conf

and edit this line to look like:

resample-method = src-sinc-medium-quality

Consequences

Now reboot, or restart the mpd & pulseaudio systems. In my case, the cpu for pulseaudio now goes up to around 65-70% of a core and the sound quality improves.

Copying files over while playing can make the CPU for pulseaudio breach 100% (more than 1 core used), this causes pretty horrible break-ups. I used renice on the copying processes (sshd, sftp-server), but this didn’t fix it completely – it was better (acceptable) after also setting the nice values of the music processes:

• sshd: 19
• sftp-serve: 19
• pulseaudio: -20
• mpd: -10

This can be done in various ways, but I used sudo top and then the r command.

There are also audible disturbances when mpd’s music database is updated (for example, when changing a filename).

I’m pretty happy with this in general as one core is being used much more than before and the sound is excellent. It is really quite amazing that such a small device with free open-source software can be used as the front end to a great HiFi system.

I did test the src-sinc-highest-quality algorithm again but unsurprisingly, CubieTruck is not able to do it. In a future article, I’m hoping to look at the differences between these algorithms in more detail and we’ll see that this one has much higher computational demands.

I would very much like to know if there are any other people who are interested in high quality sound reproduction who have got sinc upsampling to work. It can’t just be me! You can test it using pretty well any Linux computer as long as you have a decent replay system with a DAC at 96,000kHz or over. Drop me a note if you have it working and thanks again to mega-nerd.com