Friday 16 October 2015

MEASUREMENTS: A Look at Linux Audio (ALSA, PulseAudio)

What is that you ask? Well, it is the slowest computer in my house :-). It's a "vintage" HP Mini 110 from circa 2009. I decided recently to stick Linux on there just to see how well it ran... Here's the System Information:

As you see, I've got Ubuntu 14.04 LTS (updates current as of Sept 2015) loaded up on the old machine which has been sitting around unused for a few years. It's one of the early Intel Atom N270 CPU's (32-bit, single-core hyperthreading, 1.6GHz), 2GB DDR2 RAM. Slow 16GB SSD as the main drive. Whole OS loaded up on the tiny storage, no problem. Linux runs fine on the machine but it's obviously not fast, but works for light web surfing, E-mail, word processing... Now, how about for audio?

In this context with an aged slow machine, I wondered how would the measurements of the Light Harmonic Geek Out V2 perform (see my previous review of the DAC using Windows 10)? I loaded up all the test tracks on the 16GB SanDisk Ultra USB stick plugged in to the left of the machine running at USB2 speed... Nothing fancy at all, and in fact most audiophiles would probably consider this rather poor as an audio source with no optimization in place nor consideration for stuff like noise or jitter.

Now for playback, Linux (Ubuntu distribution in this case) uses something called ALSA (Advanced Linux Sound Architecture) for its drivers and low-level hardware interface. On top of this, the resampling and mixer layer is called PulseAudio (analogous to the Windows mixer through DirectSound). If you look through the PulseAudio documentation, you see that this is a very complex piece of software. Not only is Linux stable and powerful, it's also highly customizable, this applies to PulseAudio as well. With this level of power and customization ability, it could be understandably confusing for those new to the OS. The "/etc/pulse/daemon.config" file contains a load of settings you can play with... We'll get back to this a little later... Let's start with ALSA and hardware level playback first.

Part I: Direct USB Hardware Playback

In Linux, you often don't have to worry about special drivers like ASIO for direct hardware access, it does already have USB Audio 2 drivers like Mac OS X (come on Microsoft... When in the world are we going to see native support!?). But you do need music player software like DeaDBeeF (strange name but works well!):

As you can see, you can change the output to ALSA and hit the Geek Out V2 hardware (set to default "TCM" digital filter) without conversion. The resulting output:

The digital filter overlay FFT (based off the "Reis Test" described here) and the 16/24-bit J-Test signals look great and are completely in keeping with results from the Geek Out V2 measurements using my Windows 10 Surface Pro 3. Maybe there are a couple more noise spikes in the 24-bit J-Test, but we're looking at noise down <110dB, this is inaudible.

And here are the RightMark comparisons - "ALSA Direct" to hardware without conversion versus "Surface 3" using Windows 10 and ASIO driver:




Numerical results almost exactly the same. The only notable consistent difference is a slightly better THD performance out of the old HP Mini netbook! Note just how small of a difference we're looking at - on the order of 0.001%; not the kind of thing to be concerned about IMO and could just as easily be inter-test variability.

The graphs, clockwise from top left: frequency spectrum, noise level, IMD+N, THD.

I trust the conclusion from all this is rather obvious... Given the same well performing asynchronous DAC, capable of high-resolution and in this situation USB bus powered, I find minimal difference in the measured result based on the analogue output. No objective results to suggest any audible difference, nor do I hear any difference compared to my previous experience with this Light Harmonic DAC. This is despite the very different computer hardware used (2009 low power Intel Atom "netbook" vs. 2014 Intel i5 Surface Pro 3), different OS (Ubuntu Linux vs. Windows 10), and of course the underlying drivers (native USB Audio 2.0 Linux driver in ALSA vs. ASIO in Windows).

Part II: PulseAudio Playback

I mentioned above that in Linux world (at least the Ubuntu distro), there is also PulseAudio, which acts like the Windows audio mixer allowing system and application sounds to play back seamlessly. By necessity, this is not "bitperfect". There is a DSP running at a certain samplerate and bit-depth.

Unlike Windows where we can only set the bit depth and samplerate, in the PulseAudio configuration, we can also set the filter algorithm being used for upsampling... You do this by editing /etc/pulse/daemon.conf (or ~/.pulse/daemon.conf if not superuser) in Ubuntu and changing the items:
default-sample-format = float32le
default-sample-rate = 96000


resample-method = src-sinc-fastest

In the sample above, we're telling PulseAudio to use an internal 32-bit floating-point precision (there are settings from 8-bit to 32-bit, integer and float), running at 96kHz (I think max is 192kHz), and using "src-sinc-fastest" as the resampling digital filter method (variants of 'src-sinc', 'speex-int' and 'speex-float') [if you're wondering, src here stands for Secret Rabbit Code]. Because there are so many combinations, it just would not be possible to measure it all... Suffice that I will just show the results from 2 settings that worked on my machine! Remember that I'm running an old, slow, single core Atom processor here... As a result, maintaining "high resolution" 96kHz and 32-bit float for precision, the only resampling algorithms I could run stably without stutter were "src-sinc-fastest" (36% peak CPU use) as above and "speex-float-1" (30% peak CPU use). [The speex filter is based on libspeex, there is a quality setting from 0 to 9. For speed, I'm using one of the lower settings.]

Clearly the algorithms result in different impulse and digital filter composite outputs from the DAC:

Remember the the digital filter composite signals are all 24/44 in origin so what we're seeing here is with PulseAudio upsampling the playback to 96kHz with an internal 32-bit floating point data format. Correlated with a bit more impulse response ringing in the src-sinc-fastest filter, we see a steeper roll-off and significantly less aliasing. There are also fewer distortion products in the noise floor with the 19 & 20kHz signal. The price to pay as noted above is that src-sinc-fastest uses about 6% more of the CPU processing in the case of this HP Mini netbook. Notice that both upsampling algorithms seem to show some "overload" characteristics with the extremely demanding wideband white noise signal with peaks up to 0dBFS.

Okay... So we can see some imperfections here. Again, remember, this is with a very slow Intel Atom-based netbook! On a more reasonable machine, using src-sinc-best-quality or speex-float-9 should result in better looking graphs than those above.

RightMark measurements including up and down-sampling of test tones (ie. 44kHz test tone would be upsampled to 96kHz, and 192kHz test tone would be internally downsampled to 96kHz) first with speex-float-1 algorithm:

What I have here is a summary table with ALSA hardware direct (using Geek Out V2 TCM filter) vs.  speex-float-1 for 16/44, 24/96, and 24/192. As you can see, even though the digital filter test above shows anomalies, RightMark results do not look bad... Remember whereas the filter composite tracings are using remarkably harsh signals like 19 & 20kHz tones of -6dB each, along with loud white noise, RightMark uses more typical signals like the intermodulation test with components at 60Hz (-5dB) and 7kHz (-17dB).

We can see the different frequency responses using the speex resampler (96kHz would not be resampled and the curve would be the same as through the hardware):
Left: 16/44 frequency response - notice speex rolls off earlier than Nyquist 22kHz although as suggested above, aliasing suppression not as good. Right: The downsampling of a 24/192 signal to 96kHz can be seen.
Similarly, here's the src-sinc-fastest algorithm:

And again, we can see the difference on the frequency response due to resampling:
Left: 16/44, steeper than speex with a bandwidth of 80% [~18kHz] as described here. Right: 24/192 test signal downsampled to 96kHz.
You might be wondering then, what about the presence of jitter with all this PulseAudio resampling taking >30% of the little netbook's CPU processing?

Well there might be a tiny +/-1kHz sideband for the speex resampling but this is so far below the primary signal (we're talking more than 110dB below the peak!) that it's not of any concern... As I have said (and demonstrated) many times, these days, a decent asynchronous DAC is just not likely going to be affected by jitter unless something really has gone wrong!

Part III: Conclusions

As requested by some a few months back... A look at Linux. As you can see, this Ubuntu 14.04 LTS installation (latest version is 15.04) works just fine as an audio player with the Light Harmonic Geek Out V2. Using a program like DeaDBeeF (there are others, check out this somewhat dated HowTo) that allows output to ALSA directly to the hardware drivers, I can demonstrate essentially identical performance to my previous Geek Out V2 measurements with Windows 10, ASIO driver, using a much more powerful Surface Pro 3. Samplerate and bitdepth switching works on-the-fly with no issue on Linux with this USB DAC. I hear that DSD playback with Linux can be done with JRiver - didn't try as I only have the Windows version.

Ubuntu uses PulseAudio as the resampling and mixing layer (I believe JACK is another option on top of ALSA). Just like in Windows, when you're using the default Windows mixer output, we're not looking at "bitperfect" output any more. As such, audiophiles would consider this a "compromise" rather than the ideal. Nonetheless, PulseAudio is well endowed with a number of resampling algorithms of various quality, allows up to 32-bit floating point calculations, and sampling rate up to 192kHz. Even with the "weak" HP Mini netbook and lower quality algorithms due to CPU speed limitations, the PulseAudio output measured well... Sure, the digital filter test was not ideal, but in real-life playback, the PulseAudio sound from the Geek Out was great through my Audio-Technica ATH-M50 headphones.

One final observation... Whether in the past with Mac OS X, or Windows, and now Linux, there is no evidence that operating systems make any difference to sound quality if you're playing "bitperfect" to the hardware directly (ie. ALSA to DAC with no software conversion similar to Windows ASIO, Kernel Streaming or WASAPI). Obviously this statement would not apply to sounds running through an internal mixer/DSP like PulseAudio or Windows mixer. Likewise, I see no evidence that we should be concerned about jitter of any audible consequence these days with asynchronous USB DACs like the Geek Out V2.

I suppose if I didn't need to use Windows on my machines for work purposes and to maintain consistency across the computers I have here at home and work, I would be open to deploying Linux for duty as my HTPC/audio player. Certainly from what I see here, Linux these days has matured well over the years and as far as I can tell, sound quality is excellent even with this old/underpowered machine...


I mentioned last month that Onkyo will be honouring extended warranty for their receivers suffering loss of audio and network connection related to overheat/solder issues on the HDMI daughterboard (2009-2012 models). It took a total of 3 weeks and it's great to have my TX-NR1009 receiver back now. Seems to be good as new... Even though ideally "product recalls" like these should not happen, at least Onkyo is making it right and covered my 5-year-old unit even though I bought the receiver used.

It looks like they replaced the daughterboard with a DTS chip with a "New" sticker on it :-)

For extra protection, I stuck a little adhesive-backed heatsink on there...

For my first movie now with multichannel sound back on-line, I checked out Mad Max: Fury Road. Wow! Intense!

Happy listening everyone!


  1. Great article and this comes from a Linux user.
    Glad someone wrote about DeadBeef...I'm using lollypop as a music player these days but DF is still my to go software for converting.

  2. Well this clearly demonstrates that a good modern PC (like an Intel I3) can deliver "perfect sound" in any situation, with upsampling and DRC on-the-fly.
    By the way, your article about our ear/brain limitations was absolutely amazing! Thanks for all that info.

    Have a nice weekend!

  3. I use Ubuntu studio which basically is the same Ubuntu but with all kinds of audio/video/photo/publishing programs already installed.
    Audio is low latency.
    The audio section is more intended for recording music.

    For certain operations and programs I am used to I still like to reboot to Windows (dual boot install).

  4. Great read dear Archimago!
    I am a part of an audio startup in Vancouver. Your blog is perfectly aligned with what we are doing here. I would love an opportunity to chat with you about a possible collaboration of likeminded individuals :)
    Please email me at

  5. Thank you for this thorough and interesting testing of Linux audio and the comparison with Windows equivalents. I'm glad I found your site, and that you provide an RSS feed. Great!

  6. Thanks for the detailed work.
    I use Kubuntu 14.04 to drive a Teac usb dac directly through alsa. I removed pulse audio from the system. Mpd (music player daemon) is the software installed to play music and I control it using remote clients on my tablet and laptop.

  7. Hello, and thank you for all the work you are doing!
    I just wanted to comment that based on your measurements THD is actually half in Linux vs Windows. Also Linux has dedicated distros such as Audiophile Linux (based on Arch Linux) that "sound" better than Ubuntu. I have invested (read - wasted) a lot of time on Windows with solutions like Jplay, Audiophile Optimizer, etc. only to discover that Linux sounded much better in my system. The sound was always very "clean", I guess THD explains it.

  8. Hello, thanks for great article.

    May I invite you to read my question at here?

    It's a long thread so I think you have no need to scroll down, but simply focus on my simple question.

    Should the two different signal paths (coreaudio/ALSA)

    send the same bitstream to the USB DAC?