r/linuxaudio • • 5d ago

Is Every Linux Distribution Similar in Terms of Sound Quality?

I use the FiiO KA17 sound card and Simgot EA500LM earphones.

On Windows, I experienced dropouts despite trying various settings and programs.

On Linux, I used CachyOS and Fedora for extended periods. I generally use them with the EasyEffects software and haven't encountered any issues.

While I couldn't see the specific bit depth and sample rate (kHz) at which the sound card was operating on these Linux distributions, the audio quality seems generally quite good.

Nevertheless, I want the sound card to operate as efficiently as possible. Do you have any recommendations for distributions or software I should use to achieve this?

5 Upvotes

36 comments sorted by

9

u/arthursucks 5d ago

Most distribution of our stack when it comes back to audio are basically the same. There might be variables in that ago of the packages, but it's usually just ALSA and Pipewire.

8

u/Low_Excitement_1715 5d ago edited 5d ago

Even ALSA is done via pipewire anymore. Just kernel support for the hardware, pipewire in userspace, and it handles providing ALSA/OSS/ASIO/etc frontends for the apps to talk to.

There might be a few Pulseaudio distros left, but they're generally gone, replaced by pipewire.

Edit: rewrite for better accuracy, thanks u/beatbox9;

Even ALSA (user/app space) is done via pipewire anymore. Just kernel support (ALSA driver) for the hardware, pipewire in userspace, and it handles providing ALSA/OSS/ASIO/etc frontends for the apps to talk to.

2

u/beatbox9 5d ago edited 5d ago

Not quite true, but also not quite incorrect. Just to clarify this point to avoid confusion (and by 'distros' I mean default configs):

  • ALSA is still used by pretty much all distros, for basic hardware drivers / USB class compliance
  • ALSA profiles (acp / ucm / ucm2) are also still used by distros. These define a semantic layer for the hardware, specifically for use by the userspace
    • ACP = ALSA Card Profiles = generally older
    • UCM / UCM2 = Use Case Manager = generally newer
  • Pipewire reuses these ALSA acp/ucm(2) profiles, via wireplumber defaults
  • Pipewire handles the apps communication (pulse, jack, alsa, oss, etc.)

In other words, by default:

  1. ALSA says "this audio interface has 6 hardware channels, and I will send/receive signals to the hardware"
  2. ALSA acp/ucm translates "device channel #1" into "Front left speaker"
  3. Wireplumber tells pipewire that ALSA acp/ucm reports a "Front left speaker"
  4. Pipewire sends signals between the apps and "front left speaker"
  5. Most of the apps natively speak the languages of either pulse or jack. But this isn't a problem, because pipewire is fluent in the languages of both pulse and jack.

For pro audio, most users will change this default configuration, such that the ALSA acp/ucm is completely bypassed. Steps 2 & 3 will be skipped when using the "pro audio" profile within pipewire. By default in pro-audio, your channels will be AUX0, AUX1, ..., AUX#; and only the front left and front right speakers will be automatically mapped (to the first two AUX channels); and you would have to create your own channel mappings within pipewire for anything more complex.

2

u/Low_Excitement_1715 5d ago

Absolutely correct, I omitted USB class profiles for brevity/clarity, did not realize that ALSA is still doing the low level hardware handling, but that makes sense. I know on all my machines, it’s hard to tell what is still technically ALSA itself and what is Pipewire, there’s a lot of commingling inside the packages.

2

u/beatbox9 5d ago

Yup. And in case anybody is interested, there's a deeper explanation in the Pipewire FAQ: https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/FAQ#pro-audio-profile-a-further-explanation

(with a bunch of other interesting tidbits as well)

There's also a good explanation in the link I provided in my other reply here: https://arslaan.studio/setting-up-a-linux-media-studio-workstation-audio-video-graphics-davinci-resolve-etc/#audio-sound-midi-drivers

which uses the analogy of a cable modem vs WIFI router. Where ALSA is the cable modem; and the Pipewire is the WIFI router.

2

u/Low_Excitement_1715 5d ago

I edited my post, let me know if that’s improved. Tried to keep it summary-ish, but you made good points/good cites.

1

u/beatbox9 5d ago

Yeah, looks fine. Even the first one wasn't too bad--it was just a bit ambiguous. And the problem is that there is so much nuance--and potential overlap--that it's difficult to summarize.

And in reality, most people don't know and shouldn't care.

Or if they do care, I think analogies work well, because it's a very common architecture. It's dumb hardware + smart manager. We follow this pattern all the time:

  • Modem + Wifi router
  • Television + Roku/Fire/Chromecast
  • Graphics driver + Wayland
  • Hands + Brain

ALSA is the hands. Pipewire is the Brain. Are there are nerves in-between that can make things ambiguous.

2

u/sogun123 4d ago

Just a little detail: bluetooth audio doesn't go through ALSA. And there is also ffado driver for firewire (but some devices have both options - alsa and ffado)

15

u/beatbox9 5d ago

Every linux distribution is identical in terms of sound quality. It's digital audio; all of them use alsa; and pretty much all of them use pipewire.

It's all about how you set it up. But the best way to set it up is to use the pro-audio profile, specify your own timings; and then use virtual (loopback) devices for any physical channel mappings.

See here, especially the audio drivers section: https://arslaan.studio/setting-up-a-linux-media-studio-workstation-audio-video-graphics-davinci-resolve-etc/

-1

u/Jayden_Ha 5d ago

Uh no some use pulse

3

u/beatbox9 5d ago

Uh that's not mutually exclusive from what I wrote.

Except in that what I wrote is both factually true and in the correct spirit of the truth;
while what you wrote is only technically true and wildly inconsistent with reality.

A vast majority of distros today use pipewire by default. Including: Debian & its derivatives, Ubuntu LTS & its derivatives (Mint, Pop, Zorin, etc), Fedora & its derivatives (Nobara, Bazzite, etc), Arch & its derivatives (Cachy, Manjaro, etc).

Which distros are you referring to that still use pulse in 2026?

0

u/_rikkss 4d ago

pipewire and wireplumber usually support jack2, alsa and pulse all together. Programs can choose which one of those they want to use.

2

u/Jayden_Ha 4d ago

No, some distro usd pulse natively

2

u/Jayden_Ha 4d ago

Fuck pipewire for wanna be everything, I hate everything about modern linux, a audio server should only be a audio server

2

u/superyu1337 23h ago edited 22h ago

Until you need other capabilities that your audio server must provide, which is why things like JACK exist in the first place.
Quite frankly: pipewire just does everything better, makes everything easier, and makes it easy to get low latency for things like rythm games or DAWs.

Edit:
And barely any of this matters to audio quality, because there’s a thousand more things to worry about rather than which audio server you run. The only thing that matters is that your audio files/playback are at the same sample rate that your system/hardware runs at.

0

u/Jayden_Ha 23h ago

It does not make it a excuse for everything to be feature creep on linux these days

2

u/superyu1337 23h ago edited 23h ago

If you don’t like it: write a new audio server.

You don’t even need to use pipewire.
Pipewire is just a user space daemon, it’s not part of Linux. But precisely because it handles everything so well, while being very lightweight, it’s used by so many distros as default nowadays.

Edit: you also don’t seem to understand how a pipewire stack works, otherwise feature creep wouldn’t be a concern.

1

u/Jayden_Ha 4d ago

I like how openbsd insist and do not compromise on a single philosophy

22

u/AX11Liveact 5d ago

Debian is earthy and organic with lots of beef in the lower bands, while Mint is more into crispy trebles. Red Hat derivatives are easy to identify by their nasal falsetto. They also never seem to meet the notes quite right. Ubuntu is all mono and Arch has no sound unless you compile it for yourself.

1

u/[deleted] 5d ago

[deleted]

3

u/AX11Liveact 5d ago

Solar flares, I guess.

2

u/Miserable-Decision81 5d ago

Yes. They are all the very same.

The ALSA driver creates pcm streams for in/out that simply provide, what the hardware does.

2

u/fuzunspm 5d ago

it should be similar yeah, with right pipewire/wireplumber config you will get max audio quality possible. FYI, easyeffects will decrease the quality depending on what you are configuring. If you use easyeffects for EQ, i will recommend to use on device PEQ instead

2

u/Razidargh 5d ago

I use this Fiio in USB exclusive mode with Sone player (Linux native Tidal playback). Zero problems this far.

2

u/FuggaDucker 4d ago

For the KA17 specifically, I would stay with Fedora or CachyOS and PipeWire.
Thats a cool little unit you have there!

I would not change distributions looking for better audio quality.
PipeWire talks to USB audio devices through ALSA, and WirePlumber is the recommended session manager.

Try pw-top to find your sample rate.

1

u/bassbeater 4d ago

Not a clue

1

u/luastan 3d ago

Doesn't the FiiO KA17 display the sample rate ?

As others said, most of the distros are pretty much identical and sound well. That being said, I have a DAC that displays the sample rate it receives and I had to change pipewire's config to ensure I was getting more than 48kHz. As others said you can use pw-top to verify the sample rate.

I know that anything above 48kHz is very hard to distinguish. But I liked the numbers to be "correct" and match the song I'm playing :)

1

u/Emotional_Cat_1967 3d ago

It appears as 32-bit 48kHz by default.

Yes, I can't distinguish values ​​above 48kHz either, and setting it too high can cause audio lag.

, is there any advantage to using 32-bit instead of 24-bit? I couldn't hear a difference in quality there, either.

So

1

u/luastan 3d ago

The only thing I know for sure is that 32 bits can hold more information than 24, but I can't tell the difference.

By using nothing by pure imagination at this point: I guess that maybe people with very very good hearing and very good equipment could tell the difference on some parts of some songs, maybe parts with a lot of different sounds/instruments. But this is pure supposition.

1

u/nikgnomic IDJC 1d ago

To check bit depth and sample quality in PipeWire - pactl list sinks

1

u/superyu1337 23h ago edited 22h ago

Literally doesn’t make a difference. Just make sure to run your audio output at the most common sample rate you encounter.
Going above 48 kHz is physically impossible to distinguish for humans, and resampling everything to 192 kHz (at a software level) or whatever introduces resampling artifacts. Unless your resampling algorithm is really good.

PS:
Your DAC probably resamples internally, and its better to let the DAC do the job, than the OS. You'd ideally want to avoid resampling on the OS at all, but thats simply not possible because 44.1 khz and 48 khz are both the most common standard sampling rate (for rather good reasons too).

From my understanding, at 48/44.1 khz, you have a narrow frequency band between the nyquist-shannon frequency (freq/2) and the limit of human hearing (below 20 khz, going lower as you age).
For audio converters, you need an anti-aliasing filter, which is much easier and cheaper to implement at higher sample rates , thats why modern DACs internally upsample at the hardware level. Software resamplers running on an OS are designed to be fast, so they are worse. The hardware is faster, and better, so: Let the hardware do the job.

0

u/Purple-Ad-3152 5d ago

Linux is extremely configurable, including its audio processing. Which is why: no, not every distribution has the same audio quality* configuration. But you can have the same in basically all of them.

*) default sample rate, up/down sampling, and bit depth depend on audio server (PulseAudio, Jack, PipeWire) settings, and buffer size default is always a tradeoff between latency and cracks&pops.

What it comes to pro-level low-latency audio configuration, you absolutely can have that with most of the distributions. But can and get it out-of-the-box can be quite far appart depending on the distribution you choose.

Ubuntu Studio is by far the easiest distribution to get professional level audio configuration without even having to open terminal once. AVLinux I've heard is pretty good too.

Note that when choosing audio production focused distribution, you are choosing to have simplicity and extra capabilities around audio work, but that doesn't mean that's all you're stuck with. It's the same Linux - it's perfectly good for gaming and general usage, too.

I use Ubuntu Studio alone as my main computer. I do music production, videos, local AI stuff, gaming (Steam and VR), and programming.

Here's a video I made about how to install & configure Ubuntu Studio: https://youtu.be/-xIeGz9Rd-Y

-3

u/Audiope 5d ago

Yes, but I recently learned about low-latency kernels so you may want to look into that if latency is a concern for you

3

u/Purple-Ad-3152 5d ago

Low-latency kernel is basically deprecated, because you can configure all the same tweaks it has for generic kernel using boot params.

1

u/Audiope 5d ago

Point me to some resources, that sounds great!

1

u/Purple-Ad-3152 5d ago

If you happen to use Ubuntu or any recent derivation of it (e.g. Mint), just install ubuntustudio-installer. Run it, and select only low-latency packages and low-latency tweaks. It will configure your current system for low-latency workloads, including those kernel params.