Subjective Impressions of Sound Quality - Audirvana Studio on Linux

My personal impression regarding these sorts of audible differences you are describing, is they are primarily related to available RAM and memory speed/bandwidth, along with the reduction of induced noise, due to component to component isolation as well as the optimization of slew-rates across the platform topologies, these elements in aggregate, serve to reduce the intrinsic jitter of the platform.

:notes: :eye: :headphones: :eye: :notes:

What I did was somewhat different. I used the same hardware (desktop computer and SBC connected by optical Ethernet), connection protocol (UPnP), player software (Audirvana Core for Linux) and UPnP software for the endpoint in each case. Only the Linux distribution on which Audirvana was running on the desktop changed.

Whether that ought to have made any objective difference to the sound, I don’t know; likely not. But I found one Linux distribution I liked better than the others purely from a subjective viewpoint, and so I have happily settled on that.

I did that same test before this one.
I tried Ubuntu 24.04 and Arch Linux 6.9.1 on the same hardware, which was a low power quad core N5105 CPU based SBC in this case.
I optimized both versions to my best knowledge and liked Arch best as well, so focused on Arch from thereon.
I also have completely gotten over my Aargh experience with Arch :slight_smile: It’s worth it.

1 Like

I have one more (possibly aargh! :wink: ) test to suggest:

Try Audirvana playing on Arch Linux to a UPnP endpoint, then Audirvana playing on Arch Linux directly connected.

1 Like

Try Audirvana playing on Arch Linux to a UPnP endpoint, then Audirvana playing on Arch Linux directly connected.

Which UPnP endpoint do you suggest I should try? That endpoint should also run Arch right?

It can easily be one of your SBCs. You know how to install software on Arch, so if you install mpd (from the Arch repositories) and upmpdcli (from AUR if I remember correctly) and configure them, you have made a UPnP endpoint. You can use the same SBC to run Audirvana in the direct connection test, so the same computer will be connected to the DAC for both phases of the test.

1 Like

That’ll be the next experiment!

1 Like

No scientific testing whatsoever: all I can say, I am impressed with the sound quality when I connect my Mac Mini straight via USB to my Devialet, and just the same with AS running on my old MacBook Air under Linux. My impression is that these things also depend on the DAC how ,immune‘ it is against so-called computer noise. My Devialet seems to do a fine job in that respect.


Still running AS in Linux Mint. I meant to investigate other distros but the sound is that much better than the Win 10/11 version that the moment the music goes on, I just can’t be arsed! This Linux version of AS is out there on its own. Volumio is good but, in my experience, not getting close to this level of SQ.


Agree entirely! I, too, have Audirvana Studio running under Linux Mint. The sound is superb, going straight into my Devialet via USB. I am tempted to try other Linux distros, but I need to learn more about Linux to use sleek, command line-based systems.

I am totally happy with the system I have, all the more since it’s running very stably on my old, re-purposed MacBook Air.

Well done, Audirvana team!

1 Like

I have been comparing the Linux version with the Mac version.

Network setup
The Mac version is running on a general purpose MacBook Pro with M1Pro processor. This MacBook is used as a daily workhorse and is connected through WiFi.

The Linux version is running on a Raspberry Pi 4, with 2Gb memory (I had this Pi in a box in the cupboard, it is for doing experiments).

Since Audirvana makes a point of suppressing processes, giving priority to CPU and Audirvana when running it on Mac or Windows, I have been searching for a stripped down version of Linux with APT or RPM support. I am not a Linux guru in any way, so it has to be within my skillset. After some poking around on the internet, I landed on DietPi OS. I chose this one, because the company Allo, known for the audio HAT’s for Raspberry Pi, turning Pi’s into audio devices, uses DietPi as well.

The Pi is connected through ethernet to a DLink GS108 switch. The switch is powered by an LHY power supply and the Naim streamer is connected through ethernet to that DLink as well. A Wifi Netgear Orbi satellite is connected with ethernet to that DLink switch as well.

Local audio files are located on a Synology NAS located somewhere else in the network at home. The NAS is mounted as a drive on both the MacBook and on the Pi.

The Pi is powered by an iFi iPower2 power supply. Compared to a standard 5V power supply a very audible addition in a positive way.

The MacBook Pro runs on its internal battery most of the time, but I don’t hear a difference if I hook the MacBook Pro to an USB C PD cable to recharge the battery.

At first I thought the MacBook had more tone depth, more depth in the stereo image and oomph , but after extensive comparisons I figured out this impression is caused by a different focus of the stereo image and a bass reproduction that is less controlled.

The Pi wins hands down. The bass is much more controlled, runs deeper and has more texture, and as a result the presentation of the soundstage is quite different. It is more spacious, but also less mid-centred, which gives an impression of less depth as compared to the MacBook Pro reproduction.

Because the bass is much more controlled, the midrange gets more texture as well. Since the placement of instruments and voices is even more firmly put on their spot in the wider stereo image, it is easier to listen ‘between the instruments’. Especially noticeable with classical music.

The highs feel more extended, but maybe because the Linux version opens up the highs because it has the larger soundstage and more room to let the music breath. As a result, it feels lighter and with less oomph than the MacBook. But again, you hear more.

Having a more mid centred and focused stereo image has its advantages. It is one of the reasons I still play CDs a lot, it gives you a more organic feel to the music.

But if I have to weigh the differences between the MacBook version and the Linux version, the overall grip of the Linux version in this setup makes for longer and more relaxed listening sessions.

How to read this
Just a small word of warning: I have been listening for longe times, comparing a lot. I think if you walk into the room and you are being asked on the spot ‘what’s playing now, the Linux version or the Mac version?’ I wouldn’t be able to tell them apart. If I did not have the luxury of the comparing, I wouldn’t think I would miss out with either version.

In the end, I’m glad I can have a dedicated, cheap, energy efficient solution to have a dedicated streamer, just an app to start and stop music for everyone in the household and enjoy all the music from one app. Well worth the money!

Curiosity will drive me to compare a small NUC to a Raspberry Pi using the same OS, just to find out if computational power makes an audible difference.

Furthermore, I can play around with some upscale power supplies, to see if that makes a difference. I expect it will, from experience I know that power supply makes much of a difference to streamers. The question is where the limitations of the Pi are, since it is a general purpose cheap design.


You have not removed the variable of the network configurations in your juxtaposition of playback systems…

A better comparison would have you connecting both systems via direct Ethernet transmission to the DAC (no routers involved) in either case… I understand that you have this network configuration established and it is what you are using for playback, however, we do not hear Audirvana output… We hear the results of how the digital-audio signals presented to the output bus(s) have been delivered along the transmission path and ultimately, the D/A conversion output…

Another factor to consider is file latency differentials due to distance from the server and pathways, in the case of your comparison.
:notes: :eye: :headphones: :eye: :notes:

I’m looking forward to your improved comparison.

Another interesting experiment is to optically isolate the player/endpoint ethernet connection using fiber media converters. Feed the one connecting to the endpoint from a linear power supply and you are in for a treat.
Of course the endpoint needs to be on a good linear power supply as well.

Cheers, Hans.

1 Like

There’s a bit of a shortcut around this that may be (though is not certain to be) lower cost.

Let’s start off the system leading to the endpoint with a switch that has 10G optical Ethernet capability (an SFP+ transceiver cage). Why? Because the spec for 10G requires not only low jitter, but that if the system sees higher jitter, the switch will reduce it to the levels required by the spec. Amazon has a QNAP switch meeting this description for $129 US (though it was recently on sale for $89).

Then let’s have an endpoint that can accept this SFP+ input, the Fitlet3. Nicely configured with optional optical Ethernet input, I bought it for a little over $400, though I haven’t looked at the price for a few months. Since the optical input is SFP+, it meets the low jitter specs I mentioned above.

Notice we haven’t spent money on power supplies yet. (But also note that the power supplies for the switch and Fitlet3 can’t cause undue noise or jitter or those units wouldn’t meet the required specification.) Don’t worry, we’ll be taking care of that.

To the USB output of the Fitlet3 we’re going to attach an optical USB cable. This is not one of those cables with the fragile little copper wires running through it. There is no end to end copper connection. I’ve put a link at the end of this message. The optical USB cable is $240 (ouch, though not as much as some higher priced copper cables). In order to meet the USB spec that requires supplying 5 volts, there is a provision for power injection at the downstream end of the USB cable. Here we want clean power. I used the excellent Teddy Pardo “mini-Teddy,” which cost me less than $400. (The smaller less expensive supply is possible since we only need to meet the USB 5v spec.)

If your DAC operates on 5v USB power, you can stop there. I “gilded the lily” somewhat by buying another mini-Teddy for my DAC, again less than $400.

So you have double optical isolation, low jitter by spec, and good quality linear power supplies at both the signal and power inputs to the DAC, for <$1200-<$1600.

1 Like

@Jud this optical USB unit, do you know it’s jitter specs?
I mean the description “USB photoelectric chip self-developed China chip” makes me wonder a little…

I tend to use optical isolation to create a ‘clean’ side isolated from the ‘dirty’ network side, like this:

The image shows a Roon implementation but this can be any streaming app or equipment, Audirvana preferred of course :slight_smile:

The general idea is to have only clean linear power supplies and equipment in the clean side, and whatever dirty equipment (including switches, routers, wall adapters etc) on the dirty side.
The data connection going from the dirty to the clean side is a very important one, the trick that works a little magic is to replace this connection to a set of fiber media converters with a fiber line between them.

In this case, unit A is on the ‘dirty’ side and can be powered by a switched mode power supply wall adapter, unit B however is on the ‘clean’ side and MUST be powered by a linear power supply.
Noise from the ‘dirty’ side of the network will not be jumping over to the ‘clean’ side through the fiber connection, and the audio data gets re-clocked by nature of the way these media converters work.
I usually go the extra mile to replace the clock source in unit B with an ultra low phase noise TCXO.

It may be interesting to find out if the optical USB further improves things, but I am already very happy with the way this setup sounds…

The principal of an audio manufacturing company told me the electronics used in the USB cable are top quality.

In the case of a comparison of Audirvana running on an Apple Mac platform versus Audirvana running on a Linux platform (on the exact same transmission protocol and transmission path) the level of jitter created and delivered to the DAC will be what it is, and the cumulative jitter produced by either system will play into the assessment of subjective sound-quality in the final audition.

Noise is created In any transition from physical interface to physical interface component topologies… It is the cumulative level of noise/ “Jitter Stew” that we are trying to mitigate… Yes, optical does isolate power/ground/earth related loops, but as you allude to, the optical interfaces have all of the other electronic/mechanical noise- potential influences on the digital-audio bit/packet signals…

:notes: :eye: :headphones: :eye: :notes:

1 Like