Making Sense of the Audio Stack on Unix | Hacker News Reader

Making Sense of the Audio Stack on Unix

venam.nixers.net

179 pointszdw113 comments

Here's my Linux audio anecdote: I've never successfully gotten jackd to run on my computer(s) running Ubuntu or pop_os, and pulseaudio doesn't let me run with low enough latency to be usable in Bitwig. I don't want to spend my time digging through ancient forum posts on why jack/pulse can't "just work" when everything is fine on MacOS and Windows. A reboot is faster.

Sidenote, audio stacks are not fundamentally fragmented. DirectSound is deprecated in favor of WASAPI. ASIO only exists because DirectSound sucked, now WASAPI is good enough not to use ASIO moving forward (with some hiccups, like some software doing SRC under the hood because WASAPI doesn't let you programmatically select sample rate - RtAudio does this, for example).

CoreAudio has been stable for almost 20 years. It is the gold standard. The only problem is the almost complete lack of documentation except for the CoreAudio mailing list.

If you're writing audio software the solution is to use WASAPI on windows, CoreAudio on Mac, and tell Linux users to use Windows or MacOS if they want low latency audio.

I can't say I've had the same experience, I've been using jackd successfully for around 15 years now. The modern Linux answer to audio fragmentation is Pipewire, and that should actually have less fragmentation than on Windows because it preserves ABI compatibility. (It's not entirely stable yet though)

More fragmentation is not the solution to current fragmentation...

I'm not sure what you mean. Pipewire goes out of its way to have ABI compatibility, so all your old applications using Pulse/Jack will just work.

What about ALSA or OSS applications?

I believe there is a pipewire ALSA module, and for OSS there are (were?) numerous ways to get that emulated in ALSA.

Ok so it should not be worse than pre-PipeWire at least. Too bad Linux can't just make /dev/dsp be usable by multiple applications like the *BSDs managed.

While I usually would say the same, as I understood pipewire they are trying to create a unifying abstraction layer with a stable API that handles the underlying cruft.

While I would have wished for a good clean solution from the start, the state of the current Linux Audio stack doesn't IMO really allow for such a solution without breaking every program ever.

If Linux Audio needs one thing it would be something that handles the weird relationships between ALSA/Pulseaudio/Jack in a clear and automatic fashion. Because as for now I have seen Linux Sysadmins with 30 years of experience tear their hair out because they couldn't wrap their head around Linux Audio.

Build a blackbox around it and try to rework it on the inside.

Pipewire API is stable as of pretty recently: https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/FAQ...

It already works better than pulse for bluetooth stuff, by a long shot. wtay is a good guy who is committed to the project, as opposed to the pulse maintainers who are jerks.

Alas, stable API doesn't mean the software itself is actually stable and bug-free

Definitely fair; I still encounter bugs. But that was true of pulseaudio as well, and it is true of pipewire to a significantly lesser extent, especially around bluetooth profile switching, interoperability with jackd, etc.

The Pipewire author is the guy who basically made GStreamer good by overhauling its core logic back in the day - he really knows what he is doing. I fully expect that Pipewire will make audio on Linux really good (latency of Jack, consumer audio feature set of Pulseaudio, reliability of GStreamer) when it's done.

>as opposed to the pulse maintainers who are jerks.

That doesn't seem fair to just throw out without proof. In all the interactions I've seen them in, they've come across alright for the most part.

Sure, here's a good example: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge...

Maintainers unresponsive, talking about making changes but not following up. They strung the guy along for quite a while on this new codec selection mechanism problem. They claim to be in a v14.0 freeze for two months. He updated his code to work on new v14.0 to more unresponsiveness from maintainers about merging. And it goes on from there.

If you've had to use pulseaudio-modules-bt or pali's patched version rather than official pulse, this is why. By comparison, pipewire managed to get it working with little effort because its lead developer is a nice guy and responsive.

I understand both side's perspective here. I've been a contributor just waiting around for my changes to get merged. But I've also been on the other side maintaining a project which is no small feat. There's a lot that goes on that isn't obvious.

Overall a really unfortunate turn of events there. On a personal note I've been watching that space for awhile and was looking forward to Pali's great work on bluetooth.

WASAPI still has important improvements to make. Windows 10 added low-latency shared streams, but it’s dependent on driver support. Microsoft’s own usbaudio.sys crucially does not support them, meaning that for many (most) devices you still have to grab exclusive access for low latency mode.

ASIO doesn't support low latency shared modes either, last I checked you still had to release the device in software when focus changes (which is not strictly the same thing as a true shared mode).

I don't think ASIO has been updated in several years either.

I believe you’re correct. My point was more about Windows still lagging behind other platforms on this point.

Most modern ASIO drivers I've used are multiclient, which means that several ASIO applications can run simultaneously. Or maybe by “shared mode“ you meant something different?

Yea, there are tons of old drivers that rely on the older WavePci or WaveCyclic interfaces instead of the newer WaveRT model.

I've had no such issues with Jack, but it's still much fiddlier to set up than win/Mac. PulseAudio's very existence is absolutely infuriating - they had a chance to build something like CoreAudio that could handle both desktop and pro needs, with RH's backing to get support into client toolkits, and they couldn't be bothered.

Have you tried Ubuntu Studio?

Try Ubuntu studio or another audio distro. I actually have the opposite problem, where Linux is the only one where latency is decent and reliable.

I wonder to what extent this is all just hardware dependent...

It is mostly hardware dependent. Most people don't have a clue what they are talking about. The software layer is only there to take care of buffering going towards the hardware and conversions that needs to happen such as resampling. When it comes to low-latency, the difference lies in how that buffer is handled. Otherwise you can always play in bit-perfect mode where no software changes anything in the stream. I gave a small overview of it in this section: https://venam.nixers.net/blog/unix/2021/02/07/audio-stack.ht...

I concur, Ubuntu Studio is an amazing user experience out of the box. After install, everything is onboard and just works.

Not to mention, neither Mac or Windows come anywhere NEAR the awesomeness that is Zynthian .. and if anything demonstrates the amazing flexibility and power of Audio on Linux, its the Zynthian system.

http://zynthian.org/

Simply amazing audio!

> I don't want to spend my time digging through ancient forum posts on why jack/pulse can't "just work"

This means "I don't want to think about it" installing a whole distro is way too much work for someone with this attitude.

> I've never successfully gotten jackd to run on my computer(s) running Ubuntu or pop_os, and pulseaudio doesn't let me run with low enough latency to be usable in Bitwig.

Are you trying to hook Bitwig up to other realtime software with jackd? Because if not-- e.g., you're just trying to output sound from Bitwig with the lowest latency possible-- there is absolutely no point in running jack. Go straight to ALSA.

Note: I'm not familiar with Bitwig and am assuming it isn't a weirdo that somehow prevents you from setting ALSA as the backend on Linux.

The downside to "straight-to-ALSA" is that a realtime prog will gain exclusive control over the audio subsystem. So someone who wants to watch a youtube video demo on realtime prog Z and run realtime prog Z to monkey along will end up with a frozen video as it blocks (or perhaps Pulse blocks) waiting for prog Z to release the audio to it. (Or if the video started first, prog Z will (hopefully) error out trying to gain an exclusive connection to ALSA that it cannot get.)

Pulse is valuable because its default behavior solves this use case. Jack can be set up to do this, too-- I have used Qjackctl or whatever to automate this use case when setting things up. But at least last time I used Jack I had to "opt in" to this obvious setting of "pipe the running stuff to the speakers, please." E.g., I had to do business with my brain and some global mutable state. Not sure if that's changed.

ALSA has had support for software mixing for more than a decade now. Similarly, PulseAudio can work with ALSA to route any application that uses the ALSA API through PulseAudio.

AFAIK ALSA-only distros tend to have SW mixing configured by default and PulseAudio-based distros have ALSA intercepting enabled by default. So in practice an application that needs some basic audio playback can just use ALSA and it'll work everywhere.

> So in practice an application that needs some basic audio playback can just use ALSA and it'll work everywhere.

"In practice" doesn't mean what you think it means.

The behavior I described was with a Pinebook Pro which only came out about a year ago. That was running whatever version of Debian they shipped-- either stretch or buster, can't remember now. And there was no fancy or custom audio setup-- it was just an XFCE desktop environment with Pulse running however it's configured to run by default.

Also, as a maintainer of realtime audio FOSS software I can tell you users have reported these exact problems on other Linux distros. Over at least the last year and a half.

It appears that in Debian testing the configuration of Pulse "just works" as you describe. I would rankly speculate that Ubuntu 20.04 probably has a similar default setup. But to turn that rank speculation into "in practice" we'd need to actually test and see, and it sounds like neither of us have done that yet.

You wont find a sound setup that will work in all Linux distros, it is how the sound landscape in Linux is. However in terms of API availability, ALSA is available everywhere, is the "native" sound API and people can use it without installing anything extra. This is why i say 'in practice' - with anything else you'd need to rely on dependencies that may or may not exist. ALSA is the Linux sound system.

BTW what i describe is how Debian was for years when i used it by default, not just testing. It is possible that the version of Debian Pinebook Pro shipped was altered. Or something else wasn't configured as i had it, who knows.

I don't think that's important. In practice you can also use the pulseaudio API and that will work everywhere because of this: https://github.com/i-rinat/apulse

Apulse is much more cumbersome to use and not something you can really rely on - AFAIK it was originally written as a workaround for Firefox dropping ALSA support so you can still watch videos on YouTube, etc. Also isn't something that is installed system-wide, you need to explicitly call something through it.

My experiences are similar.

I had it all working with Pulse + Jack a year ago, on a previous workstation build, but it was a massive pain to get there. I had my m-audio USB keyboard working, along with Tracktion Waveform and VCV Rack. (None of which give tolerable audio quality with vanilla Pulse, even on new Ryzen 5600 + dedicated Sonar audio card.)

Based on the last experience, this time I'll take a snapshot of current .deb packages installed, a full copy of /etc/ and all my dot files (audio stuff seems to be spread far and wide under app-specific ~/. files as well as the expected places ~/.local and ~/.config).

I recall even when it was working, occasional upgrades (albeit Debian unstable) would stop various components, and troubleshooting an audio stack, if it's not something you do regularly, is slow and frustrating work. Referring back to earlier configuration files and package names should make this easier.

First step though is working out again why Debian still has jackd1 and jackd2 packages. The first search result for that question is from 2011, and it sounds like OSS / ALSA is the only reason jackd1 would be preferred. And there you have a fantastic example of how befuddling audio on GNU/Linux can be for the casual user.

The simplest solution is having a dedicated audio interface for music production (I assume that's why you want to use jackd). Run jackd on your pro audio interface, and Pulseaudio on the onboard sound card for everything else.

Use a distro designed to make audio processing a first class service, and you'll never have to reboot again - i.e. kxStudio or Ubuntu Studio.

My Linux DAW easily outperforms my Mac DAW, and I have tens of thousands of buckaroos invested in the latter, but only a couple hundred in the former. Ubuntu Studio is simply the best out-of-the-box DAW user experience around.

>If you're writing audio software the solution is to use WASAPI on windows, CoreAudio on Mac, and tell Linux users to use Windows or MacOS if they want low latency audio.

This is nonsense advice. I'll instead tell Linux users to use a decent distro, and target JACK+Alsa for my Linux builds ...

This! Still I totally understand the OPs point. It's a hassle to start with, especially using a general purpose distro. The interoperability of Jack and Pulse reminds me of Windows ASIO inabaility to utilize shared modes. Yes, there's the PulseAudio-Jack Bridge, but that one's really unstable.

So looking at Pipewire, let's hope for it to make Pro Audio and Consumer Audio interoperable on Linux. Because I really like the flexibility of Jack and the PulseAudio way of user experience.

With the small difference that on Windows the other stacks are available and usually require no user setup to get going.

This includes attempting to use ubuntu studio. Still no joy, I have never gotten jack to work properly with relatively vanilla audio gear.

As a weirdo who makes music and uses Linux as their only OS, I suppose I'll leave a little positivity in this thread. Yes, JACK does take some effort to setup and configure but once everything's in place it really is a dream environment. One of my favorite features (which I'm sure exists on other platforms but just works so well on Linux) is using Catia to route audio and MIDI between software and hardware devices on the fly. It also works perfectly with my external USB audio device (Behringer UMC404HD) which always gave me problems on Windows for some reason.

I've been running this on my Ryzen desktop with Arch Linux installed for about a year now and it's been incredibly stable and reliable. I haven't had any issues with playback or recording latency either. Along with Bitwig this is my favorite audio production setup ever and I used Ableton on a Mac for years. If you're looking for a good tutorial on configuring JACK, I'd highly recommend this video from Unfa on YouTube [0]. He does a lot of Linux and free software audio production content which you might find interesting.

[0] https://www.youtube.com/watch?v=vgrqMv3Lzfk

You're not alone, I know tons of musicians who are moving to Linux for their DAW, having invested too much in Apple and facing re-licensing fees.

So the cheap alternative is to throw away the whole setup and DAW plugins and start from scratch....

Bitwig will work with all of your existing VSTs, MIDI hardware and of course media (audio samples, Soundfonts etc.) as will Ardour and any other DAW worth using. There's no need to start from scratch.

As far as I know a lot of those api's like aRts and ESD have not been relevant for 10+ years. An article from 2021 mentioning them seems a bit strange and contributes to the impression that things are a lot more fragmented then they really are.

Thing have come a long way since old days when apps used to exclusively lock the sound card.

Yes.

This is what it looks like if you only include things that are actually relevant (or don't try to actively make it look bad, IDK why else OpenBSD's sndio would be included in the Linux diagram):

https://aurora.nox.tf/tmp/linux-audio-output.svg

NB: this is specifically the Linux situation, and the original file on wikimedia has a deletion request on it because it's so bad.

The audio stack on Unix is easily in my top three pet peeves of the desktop environment. It feels like a huge case of too many cooks in the kitchen.

To this day, every time I upgrade my distro to a major revision I just can't assume the audio will keep working. Latest upgrade of Ubuntu, and I had to download alsamixer to get audio coming from my headphones again on Zoom meetings. Both the output selector in Zoom and the selector in Settings just... Stopped working. I could select the headphone output, and nothing changed.

Keyboard configuration of the login screen is another favourite of mine.

I'm personally partial to the GPU drivers.

Every now and then I get booted to cli on startup and I have to reinstall the Nvidia drivers to get sddm to launch properly.

Also every time I reboot it's completely random if the login screen will be at 1080p or 4k (I have a 4k monitor).

Maybe it's because I've got an Nvidia card.

I'm scared to update because I know I'll have to spend hours fixing the audio and video, and whatever else again.

In the case of nvidia drivers, at least there is the (valid) excuse that the hardware vendor is purposefully hostile to linux. But failings of sound and localization are entirely of linux making.

Yeah, I know people “need” Nvidia but, I really wish people with the know-how would put some serious effort into making the deep learning stacks work well and easily on AMD cards: they may not be as fast, but AMD’s strategy is much more linux-friendly and it’d be nice for the FL/OSS community to work to make a Vega or Navi card easy to use for GPGPU.

Expending considerable effort to support each Linux release with Nvidia drivers is the opposite of being "purposefully hostile to Linux".

They shouldn't need to "support" any Linux "release" if they only published the specifications for their hardware like a civilized hardware vendor.

Like AMD, that only supports GL 3.3 on a GL 4.1 capable card?

For a few ten year old card models. Everything before and after supports whatever the HW can. Maybe it's time you let go of this grudge.

Maybe it is time to stop advocating open source drivers as something that benefits everyone.

Apparently old models get dropped just as with binary blobs, or maybe not, given that the Windows drivers work today just as 10 years ago with GL 4.1 and DX 11.

Well your hardware is from a time when AMD was still primarily pursuing the binary fglrx driver - if your card had an open source driver back then it would still work. What got dropped is the proprietary driver, not functionality from the open source driver. And with r600g being open source, people (mainly Red Hat's Dave Airlie) have been adding to it - in particular, there is OpenGL 4 support for some cards now, just not for all yet.

Just because you are unhappy that your card was too old to be included in the current open source driver does not mean you have to spread FUD about it.

It is not FUD, rather the proof that having open source drivers don't translate to support.

If anything, it helped my decision to focus on Apple, Microsoft and Google platforms, and let go of "Year of Linux Desktop" mantra.

FTR: I use Archlinux and the Archlinux maintainers take care of all of this for me.

The only surviving netbook where I still bother to run Linux bare metal now decided to start enabling the keypad overlay (for whatever reason), which naturally breaks the password entry.

So now I have to go through Fn+NumLock dance every time I bother to use the netbook.

> The audio stack on Unix is easily in my top three pet peeves of the desktop environment. It feels like a huge case of too many cooks in the kitchen.

This is also my opinion, which is why I was surprised by the conclusion of the article. Money quote:

> The audio stack is fragmented on all operating systems because the problem is a large one. [...] The stack of commercial operating systems are not actually better or simpler. [...] Linux is the platform of choice for audio and acoustic research and was chosen by the CCRMA (Center for Computer Research in Music and Acoustics).

I guess my gripe is this disconnect between "desktop audio" and "pro audio". I have my PulseAudio set up the way I want it, and that's what I need 99% of the time, but I would like to use Ardour when I want to record a podcast, but whenever I read the Arch wiki about how to have PulseAudio and JACK coexist, it looks like a huge mess that I don't want to deal with. Here's hoping PipeWire really shapes up to be my savior one day.

The simplest way to do this now is to install pulseaudio-module-jack, that works pretty seamlessly in my experience.

Without this one simple module, PulseAudio would have been entirely eradicated from my life long ago. Now its just hanging around in the background while JACK does all the work.

> whenever I read the Arch wiki about how to have PulseAudio and JACK coexist,

https://github.com/brummer10/pajackconnect

start jack, start pulseaudio, run pajackconnect, done

Since the last update PulseAudio keeps randomly switching streams from my analog output (which I connected my headset to for video calls) to my USB amplifier that drives my speakers (for listening to music).

This used to work perfect, now I always have to keep pavucontrol open when I'm in a conference so I can quickly switch the streams back.

Ah, I wish I'd have had this article back when getting working Audio on Linux was an uphill struggle. Even knowing what to Google was a challenge. Those times when things would all be working and then you reboot and now nothing works, or getting to the end of an MP3 (played in XMMS, of course) and then hearing 25 queued-up Gaim notifications.

Thankfully, the last ten years have been plain sailing. It just works. Oh, except that on Gnome the volume remote half way up my headphones cable adjusts the Pulse Audio master level rather than the volume of the headphones themselves, but I can live with that.

On a tangent this makes me feel old. Unix, wasn't that solaris, aix, ... ?

Today I learned: Unix now is Linux and free bsd.

Get me right, this sounds good, great, actually. Still, it amazes me.

Unix was never a single OS, it was mostly about being POSIX compatible. In the "Unix war" everyone wanted to call themselves Unix but couldn't because of AT&T trademark so they chose different names.

- AIX is Unix from IBM - A/UX is Unix from Apple. - They’re both AT&T System V with gratuitous changes. - Then there’s HP-UX which is HP’s version of System V with gratuitous changes. - DEC calls its system ULTRIX. - DGUX is Data General’s. - And don’t forget Xenix—that’s from SCO.

So if we want to talk about the most popular POSIX compatible systems today that are free we're left with the different kinds of BSDs and Linux OS. I also mentioned MacOS in the article, in relation to CoreAudio, but decided to leave it out as its design can't be inspected and compared properly. And also it's not a very popular OS amongst my readership and the world in general.

coughiOScough

There's also the part where writing about it is not super interesting, because it mostly just works like it should.

And sgi had irix, sco, let's not talk about sco, and even windows nt and os/2 claimed a posix layer, and I'm old enough to have used a couple of them, always "configure; make; make install"-ing GNU in top to get true interoperability, lol

And the binary compatibility of GNU/Linux, the interchangeability of suse, debian/ubuntu, red hat, keeps the promise that posix gave.

Which leads to the tangential point: a new generation which is growing up with "unix? That's Linux, right? Oh, and free bsd..."

Great, great article, btw

> "unix? That's Linux, right? Oh, and free bsd..."

Arguably, this is sort of true today, adding MacOS to the mix. With Oracle Solaris discontinued, and Oracle Linux being where the work is at, plus a bit of IBM AIX and HP-UX used in some companies server but less common. That's mostly where the POSIX/Unix-like landscape is at today.

Pipewire has been making great progress lately and is already successfully replacing Pulseaudio on my Buster allowing me to do stuff I could not before (like connecting Jack-only apps with Pulseaudio-only apps).

It's not perfect and still have bugs to iron out. I just can't wait for it to reach 1.0 ! Yet, I also hope that it does not get pushed too soon into distros as default ...

There is a factual error in the article. Middle C is not 440hz, which is an A...

It depends which OS you are running ...

Fixed, thanks.

> The audio stack is fragmented on all operating systems because the problem is a large one. For example, on Windows the audio APIs being ASIO, DirectSound and WASAPI. Perhaps MacOs has the cleanest audio stack, CoreAudio, but nobody can clearly say if they can’t look at the code. PulseAudio was inspired by it. The stack of commercial operating systems are not actually better or simpler.

Maybe so for developers, but as a user on Windows or MacOS I don’t have to know or care about any of that stuff. Things just work, and work sensibly.

> Maybe so for developers, but as a user on Windows or MacOS I don’t have to know or care about any of that stuff. Things just work, and work sensibly.

depends on the kind of user you are. If you're looking for the lowest-latency possible (for instance because you play guitar with an effect stack going through your computer) then windows with ASIO or linux with Jack give you a better mileage on the exact same hardware than CoreAudio

As a non-musician, how much latency can be tolerated?

Personally I can easily notice >50ms audio desync in videos, but I imagine one might be more latency sensitive due to the tactile feedback?

You aim for 3ms, 10ms can be described as annoying. 50ms is really bad.

In reality you either move to analog processing when you reach that much delay or design your creative workflow around it (learn not to expect immediate feedback) so you move towards offline processing.

As a guitarist, 8-10ms of processing latency is playable but feels somewhat strange especially if you compare to plugging the guitar right into a tube amp. 2ms is entirely indistinguishable for me.

And, with the "normal" system APIs (except CoreAudio which fares a bit better) it's pretty hard to get below 15ms in my experience, even with beefy computers.

I would say that's not at all true on Windows if you ever have to install multiple ASIO drivers.

Things can just work if your expectations are low and specific requirements are common, and this is true independently of OS. Where Linux shines (in general), is with customization or uncommon requirements, which in this case would AFAIK be things like low latency audio.

Yet that is not true at all. The other day i noticed that whenever you use a bluetooth headset on ms teams, it uses its own method to connect directly to the headset, skipping the windows mixer and other infrastructure. The net result is that I cannot play any other sounds throught the headset while teams is using it, unless I also set windows to target the HFP profile on the headset.

As a desktop Linux user who don't really care about that stuff, things have always “just worked” for me. When I started using Linux back in 2009, I've heard horror stories form the past about how pulseaudio was a nightmare and never wanted to run, but I've never had issues with it myself (nor on my mother's and wife's computer, which have also been running Linux for a few years).

> UCM (Use Case Manager - for presets separation, like notifications, voice, media, etc..)

Ok, some domain expert on HN:

What is the UCM, when was it added to ALSA, what is its purpose, who is the target audience (e.g., is this something that helps driver author?), and how does it relate to Pulse?

I'm especially concerned with the last question, because at a glance it seems like Pulse and the UCM overlap partly in purpose.

Pulses reason for existing was that ALSA couldn’t handle multiple sources running at the same time _yet_.

It was always on the table though and now it has been implemented. That’s why there’s significant overlap, those projects are not complementary, they are somewhat competitive.

Whenever given the opportunity, I immediately yank PulseAudio and replace it with a properly configured JACK+Alsa rig. This happens mostly on the workstations of musician friends who think they are being clever by using an enterprise Linux distro like RedHat, instead of an audio-specific distro like kxStudio or UbuntuStudio - the former is guaranteed to be a headache, the latter is smoother than anything else out there ..

It's like a routing system for audio based on use case. You could say for example: "Play notifications on this device", "Play media on that other device at this volume", "Mute anything that's VOIP", etc.. Kind of like what you have on mobile operating systems. As far as I could see, this isn't used by anything major. PipeWire is planning on making use of this in the future.

>sndio is not only available for BSD, it also has a backend for ALSA, so it can run on top of it.

Void Linux has many programs compiled with sndio support now:

* https://docs.voidlinux.org/config/media/sndio.html

> OSS, the Open Sound System, is the default Unix interface for audio on POSIX-compatible systems. Unfortunately, like such standards, it isn’t compatible everywhere. It can be perplexing to understand because different systems have branched out of it.

And this is why pure UNIX desktops never go anywhere.

> Linux is the platform of choice for audio and acoustic research and was chosen by the CCRMA (Center for Computer Research in Music and Acoustics).

This is definitely not the case as anyone that hangs around professional musicians can tell.

Just go into YouTube and see how many bother to do tutorials with Ableton on Linux.

Don't confuse things. Music production and acoustic/audio research are two entirely different domains.

Not confusing, I also bet audio research using Linux is doing stuff like coding audio compression algorithms Fraunhofer style.

Just, no. Not really at all. In fact, quite the opposite:

https://github.com/zynthian/zynthian-sys/issues?q=is%3Aissue...

So many wonderful audio devs gathering around the Zynthian (Linux-based audio DAW) waterpool. Synth developers, FX developers - everyone.

EDIT: The Zynthian project even helped Apple M1 users get software on their platform that would not, otherwise, have been an easy task .. if it weren't for Linux Audio/synth hackers, this wouldn't have happened nearly as quickly, nor as smoothly, as it did:

https://github.com/surge-synthesizer/surge/blob/main/README....

.. you don't often see things going the other way (i.e. MacOS -> Linux) ..

What I see here is a research institute in Barcelona without any reference on research market share regarding audio papers, selling Raspberry PI based stuff.

While interesting, hardly any leading number 1, top of the tops.

Ableton runs just fine on Apple M1.

Whats your point? That Linux hasn't yet taken over the audio world?

Well, my point is: its happening, even if its not being done with whitepaper sniffers and marketing people involved.

There are far more audio hardware manufacturers using Linux in their products than ever before. There are also far more pro-level audio applications being developed for Linux, than ever before. It is a rapidly expanding market for Linux, and it has the potential to seriously undermine the current leaders with disruption. Once the pro-audio world catches wind of what can be done with Linux Audio, packaged in a nice box (a la Zynthian), I'll wager that within a year this situation of Linux-as-underdog in the audio world will be very, very different.

Its already happening in studios around me - I see people freaking out over the M1 move and Apple lockdown, looking for alternatives. UbuntuStudio is a godsend for those in that situation ..

EDIT: notice that I linked to the CLOSED issues for Zynthian, and that a majority of those are from 3rd-party developers getting their synths and effects products packaged for Zynthian. This represents a sea change - not to mention the fact that this work from the Linux Audio world is rapidly propagating great value to the M1 (Apple ARM) situation ..

That is the whole point of baseless statements like "Linux is the platform of choice for audio and acoustic research and was chosen by the CCRMA (Center for Computer Research in Music and Acoustics).", without any numbers to prove them.

I can be gladly proven wrong, assuming you have numbers to share, otherwise we are talking about "Year of Linux Audio".

would you be up for sharing any professional producers, engineers, or studios that you know are using linux audio?

I'll never understand why there is not that many pro audio applications on FreeBSD. Its OSS seems to be lot simpler and nicer than all the n+1 systems I see in the linux world...

Because potential user base is even smaller than on Linux is my guess.

The problem is that the OSS model of needing to call read/write for audio I/O is pretty hard to fit with the expected pro audio model of "get a callback called when data is ready", likely through some hardware interruption.

OSS supports mmap, at least on FreeBSD.

I've been using linux since around '99 and if I had a map of linux subsystems then audio would still fall right in 'Here be Dragons' territory for me. I knew enough to come up to the border and set up an outpost to get audio out but I dared not venture deeper.

To be fair besides getting audio out I never really needed to go deeper until I started an audio-heavy personal project a few weeks ago. This article certainly helped clarify quite a bit of the map.

I really enjoy write ups like this. They comprehensively cover all the parts of a system without being too vague or too verbose. My life would be much easier if I could find the for X technology.

There's not an easy way to make your audio out mono on Linux. In 2021. Jeebuz.

How so? In alsa just configure your sink as mono. In JACK downmix to mono (or discard one channel) then plug output to both L and R sinks.

I guess what you describe as "such simple thing as output mono" has multiple solutions once you think about it, so no-one is forcing one

Anyone who is serious about audio would not seriously consider the *nix environment, except, of course for macOS. I have read many blog posts about people who have successfully gotten Ardour to work on Ubuntu (and variants) but this was after an unreasonable amount of patching and troubleshooting. I’m a busy professional with very little time for my music and audio production hobbies, and I want to spend zero time on diagnosing issues. Inspiration is a harsh mistress and does not wait around for me to finish installing some obscure library, or worse, compiling it from source.

The biggest hurdle is with hardware. If you need low-latency, high-performance interfaces, you absolutely a need tightly integrated hardware/software stack - think something like Universal Audio’s Luna system. You simply cannot make that kind of tight integration work outside of macOS.

Ubuntu Studio just works, and it’s way more stable for my workloads than windows. Debugging windows broken and slow midi support was just too painful.

It really depends on what someone is doing. Ubuntu went off the rails years ago, and I would default to recommending OSX, but as someone who uses all three, Linux has been the least painful for me.

I think the Linux-audio naysayers just don't have the experience with professional audio that they think they do.

Once you get UbuntuStudio installed, out of the box - it just plain works, and is bundled with SO MANY GREAT THINGS. I once installed UbuntuStudio alongside a friend of mine in the pro studio, who had just gotten a new Mac.

I was up and running and working on projects within 20 minutes from a fresh install - he was still hassling with UAD licenses and dongles, a week later.

Seriously people, if you think you are an audio professional, and haven't yet had a dive into kxStudio or UbuntuStudio on a spare machine, you are missing one of the greatest parties in the audio world right now.

And then, if you want to get REALLY sophisticated, as an audio professional, you NEED to dig into - and most important of all, understand - what is going on with the Zynthian folks.

http://zynthian.org/

This is the future of audio - not just for DAW's, but embedded audio devices, too. When you grok what Zynthian is, and how it works, and what it is doing, you will change your mind about everything you think you know about audio on Linux.

(Hint: it takes the extremely powerful Linux Audio/DAW software ecosystem, wraps it in a functional and simple UI, and exposes EVERYTHING in the Linux Audio world to the musician .. from synths to FX units to MIDI processing and generators and beyond. Simply a massive leap forward for audio professionals...)

I think this is a filter bubble thing. Considering the difference in the time of the posts, I'd say the user base that was previously commenting was mainly from the USA where Apple is king and has its own bubble. Around the world it might be different.

A lot of it has to do with the perceived elite nature of the MacOS platform for Audio/Video in comparison with other systems.. and its true, Apple have prioritized audio/video on their devices for decades - see for example, iOS versus Android audio thread priorities, which until recently were very much in Apples favour.

The trouble is, most "audio pro's" don't really have the technical chops to understand why this is the case with MacOS, nor why Linux represents a parallel advance in audio processing technology. You can do things with Linux audio that are impossible with MacOS, due to its general-purpose nature - but MacOS still provides great value to the consumer, not just professionals.

The great thing about Linux audio is that the devs pushing it forward don't have any of the constraints that the MacOS/iOS folks have to work under. This gets mis-underestimated by audio pro's, imho.

But with things like kxStudio and UbuntuStudio and Zynthian out there, this is going to change radically. I think the audio world is in for some very big upheavals in terms of Linux adoption over the next few years .. but I have all of these systems operational in my pro studio, and have poked these beasts multiple times. Linux rules for audio, and hardly anyone knows .. thats another kind of elite realm left to be explored by the curious and adventurous.

Great points, thanks for the insights.

I am actually somewhat aware of UbuntuStudio and its related technologies, and one of these days I will take a week or so to set up a spare machine. My original point was more about hardware than anything else. I do not think (please prove me wrong) that there is any DAW/hardware solution that actually offers true zero-latency monitoring (and I don’t mean direct hardware monitoring, which has been around for decades, I mean true analog-like near-zero latency monitoring of your input channels with effects, synced with your playback tracks) other than UA’s Luna system which was just released last year. I don’t mean to sound like a UA shill, but this (ARM - Accelerated Realtime Monitoring) is a brand new unprecedented technology that has and will revolutionize audio production. The caveat is that it only works with macOS - even though the Luna system is available with Windows, ARM is not and likely never will be. This can only work because of the extremely tight hardware/software integration and thunderbolt connectivity. Does UbuntuStudio or or anything in the *nix realm offer anything like this? I’m not just being oppositional - I am just truly unaware of an equivalent.

you are clearly very passionate about this subject. breathlessness aside ("if you think you are an audio professional...", "you _NEED_ to dig...", and implying that the massive amount of audio professionals who don't use linux are somehow out of touch with their actual level of experience (your first sentence - not sure if that's what you meant to imply)) -

zynthian has a nice website. it seems like a cool idea and I'm sure it has some great use cases. it's still a kit which strikes me as not pro-level.

more concerning is that it appears to have what I would call completely unusable issues regarding latency and jitter (5-20ms of latency is unusable for realtime audio), can you comment on this? how about jitter? what is your experience with it (and if you have any, what are your use cases?)

searching the internet for solutions here seems to show a lot of unresolved issues. I see the developers asking users to file GitHub issues as recently as a couple of months ago. I know very few audio professionals who are going to want to use something with this degree of maintenance / instability / unreliability.

how would you describe the ease with which you can interface the tools you describe with outboard gear using USB or MIDI e.g. audio interfaces, mixers, synthesizers, etc, compared to the apple ecosystem? which tends to be quite plug & play. one reason why it is so widely used.

I think audio pro's who spend the time complaining about tools that are known, outside their sphere of influence, to work quite well - simply aren't professional enough to admit when they haven't learned enough to get similar results as others, who are .. and UbuntuStudio has had decades, literally, to become that kind of tool. It is used by pro's all over the world to supplant what would otherwise have been a significant financial investment.

It is free, after all, and yet out of the box comes replete with tons of stuff that you'd have to spend, literally, a week getting installed on MacOS/Windows, dealing with licenses, etc.

Zynthian: The latency is really not noticeable - I have a 12 track multi-timbral project running on it right now, it sounds just as rock solid and tight as the 3 rows of 19" rack synths/effects and the half-a-room full of other hardware synths in my studio. It is an extremely capable little box, and its built around existing Linux audio technology - so the point is, it serves as a pretty good reference for how good things can get. Jitter? Haven't noticed it.

Zynthian integrates with all the DAW's in my studio, including UA and MacOS systems, just fine. Its a dream to be able to set it up for remote control over rtpMIDI, for example, and not have to run any cables.

Github issues are a professional way to interact with developers. If I had 2c for every time I heard someone complain about the support they -didn't- receive from Apple because of bugs in Logic, or crashes that Steinberg/Yamaha refuse to fix, or updates to Ableton Live that resulted in unusable projects .. I'd have enough to afford a decent UAD system .. ;)

On the other hand, if you look at the closed issues in the Zynthian github, you'll see so many successful contributions from around the world, making the Zynthian a better product. This is the future.

Reply on news.ycombinator.com