Hacker News Reader

> 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.

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.

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.

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.

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.

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.

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.

Have you tried Ubuntu Studio?