How To: Enable High Quality Audio in Linux

My wife got me a FiiO E17 USB headphone amp (thanks, hon!) to go with my Sennheiser HD650’s the other day, and it can handle 96KHz 24-bit audio – but by default pulseaudio and alsa are configured for 44.1KHz 16-bit audio. At the 44.1/16-bit settings everything sounds great, but I figure if the quality can go higher and I’m not fussy about a bit of extra CPU usage then I may as well bump the quality settings up a bit to take full advantage. Here’s how to do it:

1 – Check current settings

To see what your current settings are, you can either run the following for the full details:

pacmd list-sinks

Or to cut to the sample rates directly use:

pacmd list-sinks | grep sample

Depending on how many sound devices are connected you should see something like this (in my example I have an Intel HDA internal soundcard as the first sink, and HDMI audio out as the second sink):

$ pacmd list-sinks | grep sample
	sample spec: s16le 2ch 41000Hz
	sample spec: s16le 2ch 41000Hz

You might want to play an mp3 at this point and then look at the pulseaudio cpu usage via the top command so you can compare the current and HQ CPU usage as it might be a factor for you (i.e. depending on the spec of your PC, you might not want to sacrifice 10% or more CPU usage for higher quality audio – but seeing as you’re here and reading this I’ll assume that you are!). As a baseline, with the default settings pulseaudio uses around 2-3% CPU to play an mp3 on my Intel i7.

2 – Modify for high quality

Pulseaudio’s global settings are stored in /etc/pulse/daemon.conf, so edit that with your editor of choice and look for the following lines (the ‘resample-method’ line is above the default-sample-* lines btw – that is, they’re not all together as below):

; resample-method = speex-float-1
; default-sample-format = s16le
; default-sample-rate = 44100

These are the defaults, and are currently commented out (you can use either ; or # to indicate a comment). Uncomment each line and modify it to the below (or even better – just add an uncommented line below each one so you can still see the default values), so you end up with:

resample-method = src-sinc-medium-quality
default-sample-format = s24le
default-sample-rate = 96000

The Arch Audiophile Playback wiki recommends medium quality for resampling, you might want to try src-sinc-best-quality if you’re going for broke. A description of the libsamplerate resampling methods can be found here if you’re interested:

I get about 10% CPU usage on the pulseaudio daemon with 96KHz @ 24-bit audio with medium quality resampling as above, whilst using src-sinc-best-quality results in a rather significant 24% CPU usage just to play an mp3! ( It’s like having a Pentium 100MHz all over again! ;-) ) The ‘s24le’ means 24-bit samples, little-endian order, btw.

3 – Restart pulseaudio and check the settings

Now that’s done we need to restart the pulseaudio daemon (don’t run these as sudo – pulseaudio runs per user so just execute as normal!):

pulseaudio -k
pulseaudio --start

Once that’s done, you should be able to check the settings have taken by issuing:

$ pacmd list-sinks | grep sample
	sample spec: s32le 2ch 96000Hz
	sample spec: s32le 2ch 96000Hz

It’s jumped up to 32-bit samples in this case, but that’s fine. Check the audio still works, and maybe have a look at the CPU usage when playing an mp3 via top again if you want to see how much this is affecting the CPU usage on your machine.

FiiO E17 Amp Check

Now that we’ve set higher quality default settings, if you’ve got some suitable hardware for them like the above-mentioned amp, plug that bad-boy in, switch it on – and it should validate that it’s getting the higher sample-rate and sample-depth:

$ pacmd list-sinks | grep sample
	sample spec: s32le 2ch 96000Hz
	sample spec: s32le 2ch 96000Hz
	sample spec: s24le 2ch 96000Hz   <--- FiiO E17 detected, working at 96KHz 24-bit
Fiio E17 at 96KHz 24-bit via pulseaudio
Fiio E17 at 96KHz 24-bit via pulseaudio via USB (i.e. it’s acting as a sound card). The ’40’ value is just the current volume setting.

Sound Quality Differences

So – does changing these audio setting make a definite, perceivable difference to the audio quality? The short answer is yes!

How much it changes the audio quality is going to depend on your hardware (amp, headphones etc.) as well as the actual audio file(s) you’re playing on it. I don’t have any 24-bit audio to try it out on, but I rip everything at the highest possible quality VBR mp3s using lame – so I’ve been testing on the first track of Alt-J’s album (intro) with some Sennheiser HD650’s – and my honest answer? I’d go as far as to say it’s a strong yes (html joke ;-)). The high-frequency elements in particular seem a little brighter with the 96KHz 24-bit sampling, at least when run through the FiiO E17. Now, this could be placebo – that is, you expect something to sound different/react in a particular way so you look for it and (internally, subconciously) try to convince yourself of it. But I’ve honestly swapped back and forth and listed to the same track a number of times during the writing of this article and I genuinely believe it’s sounding better with the HQ settings.

Unfortunately, the schoolboy error I’ve made here is that I’ve changed two (if not three!) things at once: I’ve enabled the higher sampling-rate and sample-size/depth, but I’ve also modified the resampling algorithm to one of higher quality at the same time – so figuring out what elements of the audio sound better because of the audio settings and which are from the resampling-method (because I’m not playing native 96KHz @ 24-bit audio files to test with) can’t really be done. To get any real results I’d need to strip back to default settings and modify each in turn, doing listening tests with notes as I go, which frankly isn’t all that high up there on my priority list of things to do because…


…I’m delighted with the audio quality after these changes! It really does sound great =D

Ideally, I’d prefer to have things set to 44.1KHz on each audio device EXCEPT the Fiio – that way, when I’m playing games there’s minimal CPU used on the audio side (which isn’t really going to benefit that much from upsampling and such, I’d imagine) and then have the HQ settings for the FiiO only so that when I plug it to listen to music I get the HQ audiophile kick. However, my understanding is that I’d need to go into the alsa side of things to configure device specific settings – and again, it’s not really a high priority at the moment.

I’d love to hear what difference (or lack thereof!) any of you find when changing over to HQ audio (asides from the bump in CPU usage) – and if you run or have played with different samplerate/re-sample settings for diff devices I’d be especially interested! Cheers!

How To: Fix Stuttering Sound in 9.04 Jaunty Jackalope

Just upgraded my 8.10 Intrepid Ibex Ubuntu distro to 9.04 Jaunty Jackalope, and bar a slight keyboard configuration issue (paraphrased as: “current layout not found – will leave keyboard config alone”) and having to take a close look at my GRUB menu.lst before deciding to take the package maintainers version (new ver includes updated entries of your current ver – but backup your current menu.lst just in case!) everything went fine. In fact, 9.04 feels more fluid & responsive in some aspects, so all good so far.

The only problem I’ve noticed (and fixed) so far is that using my external Creative soundcard, and likely the Intel onboard card, sound stutters a bit. This is due to ALSA’s “glitch-free” (I kid you not) drivers, having, er, glitches when used through PulseAudio. I guess you could remove PulseAudio, if you really wanted to, but there’s a simple one line fix – just edit the file /etc/pulse/ and add following line:

load-module module-hal-detect tsched=0

Then, either restart PulseAudio with /etc/init.d/pulseaudio restart or reboot – and job done – no more glitching sound.

A quick gnome-based sound test is to run the Sound application in System | Preferences (i.e. gnome-sound-properties) and just click the [Test] button on Sound Events | Sound Playback.

From some further reading, it seems tsched=0 is a kludgy workaround that can cause higher CPU usage for sound playback, and the real problem lies with the Ubuntu kernel being high latency.. (see Ubuntu Forum link below, post #43 onwards). I think I’d rather higher CPU usage than the sound breaking up on me, and playing some mp3s in VLC (just because the new Amarok’s still busy scraping together collection details from the NAS :) ) takes 2% of a single core on my laptop. When running at the lowest possible speed of 800Mhz.

I don’t think that’s gonna be a problem…

Sources: lglinux, ubuntu forums

Even with the above fix, sound would sometimes be a pain on an upgraded 9.04 – mute channels you had to unmute in alsamixer, xine and Gstreamer engine config woes, mplayer has sound but vlc doesn’t, or vice versa, or neither have sound but firefox does… I decided to just wipe the entire system (backing up the /home partition first for a file-system change over) and start again clean.

I think the glitches were from upgrading 8.04 to 8.10 to 9.04 and everything being a mish-mash of legacy code and deprecated configs held together with gaffer-tape and bubblegum… It wasn’t pretty. But with a fresh system slapped on EXT4 partitions, I get zero sound issues, the system boots and runs quicker than I’ve ever seen it go, and it only took a little while of checking some boxes in synaptic to get things back to pretty much where I left off. I’d definitely recommend installing 9.04 fresh – nothing else has that minty new-OS zing, or lack of seriously annoying glitches. Final Note: Be aware that if you go for EXT4 as your filesystem you will have to set some options and cross your fingers if you want to resize the partitions using the tools available in Jaunty, and that there can be a problem with delayed allocation and 0-byte files if the box falls over before committing data. If that doesn’t sound like it’s for you, XFS is fast and safe – and knocks EXT3 into a tinfoil-hat.

Update 2:
I somehow managed to get it so Nautilus and Firefox would play sound (through PulseAudio), but VLC or MoviePlayer or anything else wouldn’t… no idea how – perhaps by having the audacity to use my frackn machine? So obviously some programs are using pulseaudio, which seems to work, and others are trying to use ALSA, which isn’t working because pulseaudio is raping it… Anyway, I tried about 5 things to fix the sound – here’s some details:

1.) From the Simple Guide to Sound on Hardy, Intrepid & Jaunty, I ran:

sudo apt-get install asoundconf-gtk alsa-oss libasound2 libasound2-plugins padevchooser gstreamer0.10-pulseaudio ubuntu-restricted-extras

and rebooted. Did this help? No. And most of it was installed already.

2.) I upgraded ALSA to 1.0.19 (while 1.0.18 is the one in official jaunty repos at the mo) using the script here. Did this help? Not immediately. But it won’t have hurt.

3.) I installed vlc-plugin-pulse – and after changing the audio output to Pulseaudio server, VLC would produce stuttery sound, which is a start.

3.) I read a bunch of this stuff: Multiple Sound Solution, some more, and then even more.

4.) I went System | Preferences | Default Sound Card and chose MY SOUND CARD – *not* pulse audio (you can also do this from the command line with: asoundconf set-default-card CARDNAME – to find out which cards are available, run: asoundconf list). I then went to System | Preferences | Sound and changed all my settings away FROM Pulseaudio TO Alsa Mixer for my soundcard (the reason I say my soundcard is that I’ve got an onboard Intel soundcard, and an external USB Creative one I prefer to use because it has optical input/output) – if you hit the [Test] button with ALSA used for playback and it doesn’t play, that’s your glitch.

5.) ALSA decided it would play, I changed VLC back to ALSA output from Tools | Preferences | Audio – and *bang* – no more suck-ass, stuttery, crackly pulseaudio sound. Pure clean audio from all applications.

I wish I could be more specific about exactly what fixed it for me when I was having no sound – but I genuinely don’t know exactly what combination of steps fixed things. One minute ALSA mixer wouldn’t play, the next it would – it’s some kind of pulseaudio/alsa conflict, and using ALSA gives me the best sound, when Pulseaudio doesn’t hijack it… There are steps to remove pulseaudio, and at the present time, as much as I like the goal of it it’s not doing the job, so the next conflict I get I’m going to go the full hog and purge.

As a last resort if you have no sound make sure none of your mixers are muted by running alsamixer -c 0 for your first soundcard, alsamixer -c 1 for your second etc.. and make sure none of the playback mixers have MM (i.e. Muted) on them at the bottom, pressing ‘M’ on them will unmute and change it to the bizarely named ’00’ – to do this from a nicer GUI, just install gnome-alsamixer.

Last Chance Saloon Update:
If you’ve got sound in some things but not all, check your gstreamer-properties (by typing that very thing at the console) and make sure you’ve got your audiosinks right. gstreamer-properties is just a front-end for the gstreamer part of gconf-editor btw. I’ve discussed it a bit here.

Last LAST Chance Saloon Update on 16/02/2010: If you’re sure it’s pulseaudio which is messing your application up, launch it without going through pulseaudio via pasuspender NAME-OF-YOUR-APPLICATION. I came up against this when trying to fix ScummVM sound the other day under Karmic 9.10.

Good luck!