Guide to configuring FreeBSD as an audiophile audio server: setting up system and audio subsystem parameters, real-time operation, bit-perfect signal processing, and the best methods for enabling and parameterising the system graphic equalizer (equalizer) and high-quality audio equalization with FFmpeg filters. Linux users will also find useful information, especially in the context of configuring and personalising the MPD player and filters.
As a non-audiophile I really enjoyed this dive in to FreeBSD. I use FreeBSD every day but I've never needed to dig in this deep. I really shouldn't be surprised that it was an audiophile that would just keep digging until they got what they wanted. Thanks, most interesting.
This is missing a good justification for digging into realtime processing. For me that was to create a DIY receiver, so the equaliser/room correction needs to happen quickly and consistently to maintain lip sync. I'm not sure it's quite so justified for an audio/music server
FreeBSD never crossed my radar as a viable platform for realtime audio processing, instead I had good luck with Linux + RT patch + Pulseaudio + https://github.com/bmc0/dsp. (Pulseaudio really shines in this kind of use case, will resample to correct for slight differences in input/output clocks etc)
Also an aside, "USB cable: WireWorld ULTRAVIOLET 8" is a controversial thing to mention
I expected that USB cable to be $250+ but I see them for $50-$70 which is still super expensive for a USB2.0 cable. But I guess if you like the look of it, it makes sense.
Audiophile USB cables are pure placebo, there's no controversy here. Changing the medium doesn't magically make digital signal higher quality, only reduces data loss, if anything.
Lennart Poettering. That guy is smart and writes a lot of code. However he is also very controversial: anyone who loves Unix hates him because his ideas are very contrary to the "unix way".
Poettering didn't create pipewire - he created pulse audio which pipewire closely emulates though, and so that will be unfortunate.
The other issue is pipe wire had a very ambitious list of features they wanted to support and it took many years to make everything work according to their vision. Pipe wire has been out for several years before it was good enough that normal people could trust it. I've been running it for a couple years now, it is good now, but it wasn't. Pipewire supports video in ways users really want, and so there was pressure to put pipewire everywhere long before it was ready and so this is unfortunate.
Today I will tell everyone to just use pipewire. It works and supports everything you really want to do.
Bugs, instability, crashing, latency .. compatibility issues, difficult to configure at first .. bluetooth audio is lower quality than it could be (AptX and LDAC codes unsupported) .. performance is not that great compared to pulseaudio and jack ..
I'm ready to believe that pipewire is imperfect (although I have personally experienced no crash, and did not have to configure anything), but the sentence from the original post is:
> Therefore, I naturally omit the use and configuration of additional audio layers in the form of a Jack server, PulseAudio or the unfortunate PipeWire from RedHat.
I cannot understand this sentiment. I have used all three for years each. If I had to qualify one as "unfortunate", it would certainly not be PipeWire (nor would it be Jack for that matter).
> performance is not that great compared to pulseaudio and jack ..
Jack makes different trade-offs by default, so for some definition of performance, yes, one could see it as superior to PipeWire. But in my experience PipeWire is better than PulseAudio on all axes (at least: latency, CPU usage, resampling quality).
> performance is not that great compared to pulseaudio and jack
I'm aware that performance is not quite as good as Jack (but not by significant margins AFAIK), but how is performance worse than PulseAudio? That cuts against every datum I've ever heard about the two.
As a humble 'good enough' audiophile, I have a fleet of Fiio devices and assorted cans and IEMs, but never have enough spare cash to consider a "real" audiophile setup. I've had experience with studio monitors and really good audio coming through mixing desks and what not, but I've never had the opportunity to try a real expensive kit.
Flac is my source, decent DAC, decent cans, good enough I guess
Audiophile's are famous for spending a lot of money on "snake oil" to get results that objectively cannot be heard and then claim the sound is better. Sometimes the sound is better, but the human ear cannot tell (lab equipment can). Of even the best lab equipment cannot find a difference.
Good enough if you are happy is good enough. Maybe you can do better in ways you can hear, but with "Flac is my source, decent DAC, decent cans" you are probably getting close to the edge of what the human ear can hear anyway (assuming good audio in that Flac, and the DAC/cans really are decent as you claim)
For me personally, a little cannabis or psilocybin is 10x more effective at improving listening experience than any of the lengths that more serious audiophiles typically go to.
I recently got into making some sort of budget hifi setup, and found audiosciencereview.com quite helpful - a good amount of reviewed gadgets with focus on measurements. Ended up with kali lp-6v2 speakers and a SMSL SU-1 dac. Please don't tell me I screwed up. :-)
I have a pair of Hifiman Sundara that I take out for proper listening (they’re a bit heavy). But more often than not I listen through a pair of creative pebble which is more than enough for me.
It does not, it serves no purpose for only listening to music.
Producing, broadcasting, or any sort of scenario that require reliable low latency can benefit from a real time kernel, but not merely listening to music.
I sometimes play live (I don’t enjoy it) using Spectrasonic’s Keyscape, which loads many dozens of gigabytes into RAM. If I have one more “mystery” buffering issue I’m going to tear my hair out
This is on an ultra locked down, high spec dedicated PC
I would be absolutely enthralled if my software/hardware had a consistent schedule like that prioritised by an actual RTOS
It’s why almost all actual musicians use industry standards like Nord for keyboards. While my Keyscape VST sounds much better, I can’t reliably use it in live contexts because the Windows/Mac stacks are just too precarious
I don’t need it to crush numbers, just have the gap between best case and worst case scenario for computation to be effectively zero
Live performance craves near-deterministically performing instruments and tooling
RTOS does not improve playback of music but is crucial if you e.g. want to produce music. Imagine a situation where you connect some MIDI keyboard and play some music - you want OS to produce the sound "real time" instead of "scheduling it".
A good way to demonstrate the problem is by trying to use a music-making app through a Bluetooth headphone or speaker. That delay completely kills the ability to stay on the beat.
"Note
There is a rumor that real-time scheduling improves audio quality. That is not true. All it does is reduce the probability of skipping (audio buffer xruns) when the computer is under heavy load."
If your audiophile playback machine is under "heavy load" then you are definitely suffering a bad case of priority inversion.
RTOS means that if you are listening to music and doing something else the music plays without issues (clicks). Take a modern 16 core computer and load it up such that the load average is over 200 and your sound playing will have issues. Of course realistically nobody loads their computer down that much, but if you manage to anyway like that you will have issues with sound. Because you won't though RTOS won't matter for playback. Still if you try you can cause issues without a RTOS - I leave this as an exercise to the reader.
As other have said RTOS is critical for live sound because there they have to make compromises that mean much less load is needed to cause issues. If you configure your sound playback with the same compromises you will see issues on playback - but for just playing music on a regular computer those compromises are a don't do that situation.
Theoretically, an RTOS improves the quality by ensuring that the audio subsystem is fed cpu time and data with enough granularity that there is no interruption or delay on the sound stream (no "buffer underruns") and there are no glitches on the output.
In practice this should not be an issue if you are just playing music (at worst, add some more buffering) but it can be if the music must be synchronized with something else and you need low latency AND the system is busy doing also something else.
I found Linux in particular to be surprisingly bad at this when mass storage is involved (copy files on a spinning disk, somehow playback of audio from an SSD is affected... why?), although low-latency versions of the kernel help in that regard.
The submission's article here is a little too concerned with irrelevancies -- BSD vs Linux, graphic equalizers -- and is not concerned enough with the biggest improvement in audio quality over the last twenty years: measurement and realtime correction of audio playback systems.
The simplest example is with headphones, because the measurement can generally happen once per model, rather than each time you move things around in a room. Take moderately capable headphones -- this does not correlate with price, there are good choices for $25 and bad choices for $2500 -- and measure their frequency response from 20-20000 Hz. Construct the minimum set of parametric equalizations to bring them to a target curve -- that's the bit which has gone from deep expensive magic to ten seconds on a modern CPU -- and apply that from now on. Your $25 headphones are now 97% as good as the best available in the world.
The standard cautions, because HN is full of pedantic floccinaucinihilipilificators: the headphones must not distort too much; ear canals differ and must be accounted for individually; preference in target curves differ; Olive and Toole's curves are representative of what a reasonably large sample size of humans "like"; uncalibrated microphones introduce their own distortions. Speakers in rooms must be measured in those rooms, as currently configured in terms of furniture and anything absorptive or reflective at audio frequencies.
The second biggest issue, the one not related to quality as such, is the availability of sufficient and sufficiently cheap bandwidth and storage to allow people to run their own music servers and personal/household music streaming services.
> The standard cautions, because HN is full of pedantic floccinaucinihilipilificators
I think (I am not sure, I’m more familiar with the in-room speakers style of audio reproduction) the “biggest” issue is that different speakers have different time-based nonlinearities. This should be most clear in impulse responses. At an extreme example, a headphone that has terrible resonance at 400hz can never be fixed purely by EQ using a standard amp.
> The standard cautions, because HN is full of pedantic floccinaucinihilipilificators
I think (I am not sure, I’m more familiar with the in-room speakers style of audio reproduction) the “biggest” issue is that different speakers have different time-based nonlinearities. This should be most clear in impulse responses. At an extreme example, a headphone that has terrible resonance at 400hz can never be fixed purely by EQ using a standard amp.
Now, this could be solved at least partly using current drive amplifiers. Apple has apparently done this on their AirPods. But it’s not a common thing at all.
It's true, which is why that's in the standard cautions.
But it's also the case that you can get reasonably priced headphones and speakers (reasonably priced by the standards of nonaudiophiles!) that do not have terrible resonances. So: you can't fix everything, but if you're paying attention before you buy, you can avoid making mistakes.
E.g.: Kali LP8v2 are frequently on sale for $400/pair; that includes amplification. Moondrop Chu II IEMs are under $25.
reply