I think I just solved audio on Linux. - Page 1
Forum section: electronics / general

author: Ampera
author_rank: Super Contributor
timestamp: July 07, 2019, 08:25:22 am
content: I apologize is this is old news to anyone else, but I've always wanted a truly dynamic audio subsystem to exist on my computer, allowing me dynamically route audio between programs and sound cards.If you're a Linux user, you no doubt know how complicated sound gets. We have ALSA, which is the direct driver interface to the hardware, but doesn't have good means to mix multiple programs at once, or do complicated mixing, routing, or anything of the like. This is where sound servers like JACK and PulseAudio come in (the two most popular ones on the platform). The issue is that these systems are very much mutually incompatible.If you're a Linux user, and do not do professional audio, you more than likely use PulseAudio. For most uses, this is fine, it has similar capabilities to the default Windows sound system, and has some flexibility, but a lot of it is hidden under a very complicated and annoying to deal with set of command line config programs, using terms and concepts that, at least to me, are about as intuitive as trying to construct a kit car via instructions you found off the back of a cereal box.JACK is (there are more, but not that widely used), the other option for having a sound server, and it's honestly beautiful. It provides a simple interface for realtime/low latency audio, with a plethora of high polish tools and configuration options with means to do highly dynamic audio and even MIDI device routing. It's my idea of a perfect sound solution, and besides a somewhat unfriendly process (for new users) to set up, is how I wish all sound on all computers worked.The issue is, since this is Linux, they are two standards, and programs written for PulseAudio do not work on JACK, and vice-versa. You also cannot forget ALSA-native programs, which often need to be supported inline on both solutions. Ever since these two sound servers have existed, people have tried to make them work together, but guides on exactly /how/ to do that in a way one would really want are complicated and scarce. If this looks like something you'd want to do, but you can't figure out how I did it, I can write a guide, just let me know.https://prnt.sc/obmlpxThis is a screenshot of what I've come up with, and while I need to polish it for myself, move some stuff around and things, this is exactly what I always wanted. What you are seeing here are two PulseAudio programs (chromium and VLC) playing audio (music). If you see the qjackctl graph you can see that there are two clients, named PulseAudio JACK Sink and PulseAudio JACK Sink-01. In this configuration, chromium is running on 01 and VLC is running on the other one, separately, and independently. I can treat them just like I would any normal JACK client, except they're PulseAudio.The implications for exactly /why/ I'd want this are vast. I do YouTube streaming, but might be doing something that I'd rather listen to music with, but otherwise couldn't since i need to monitor the sound of what I'm doing too, and do not want to stream the music. With this, I can record one program, but monitor the audio from two. There's more applications than just streaming, and I could end up adding things like multiple sound cards, do neat mixing between them, the works.The tl;dr of how I did this is by using pulseaudio-jack to connect pulseaudio to JACK as a client, instead of using ALSA, via loading the module module-jack-sink (another one also exists for inputs). To get multiple programs to route, I just loaded it twice, giving me two sinks I can direct different programs to.I've yet to automate this, as this has a lot of manual configuration nonsense, but that shouldn't be too hard. I just felt like I needed to show this to people who, like me, might have always hated sound on Linux, and would be happy that at least someone figure out how to do it right, with support for everything.

author: Towger
author_rank: Super Contributor
timestamp: July 08, 2019, 03:28:06 pm
content: Back in the day you had to recompile the Linux kernel to add support for a sound card. In my cause it was a Gravis Ultra Sound. It was a whole lot of messing, the end result did not work properly, which is why I gave up using Linux!

author: gnif
author_rank: Unknown
timestamp: July 10, 2019, 12:08:24 pm
content: I am also routing Jack with Pulse, I documented how I did it a while back here:https://youtu.be/a322V4yo3nY?t=618

author: SiliconWizard
author_rank: Super Contributor
timestamp: July 10, 2019, 01:46:11 pm
content: Well, this is not old news, but not particularly fresh news either.Anyway, it all depends on what you want to achieve... on Linux there are just many ways to solve one problem.I personally use Pulseaudio for the mundane audio tasks (because I'm mostly on Gnome, where it's default), and pure ALSA (obviously through a different sound card) for more pro audio playback and recording. So both uses are separate and handled differently.One thing to know is that Pulseaudio eats up more CPU than we would think, and I believe Jack is not that frugal either... it doesn't matter much on a modern desktop computer, but it tends to shorten battery life significantly on laptops...

author: NiHaoMike
author_rank: Super Contributor
timestamp: July 10, 2019, 03:41:26 pm
content: I just use plain ALSA since bit perfect playback is what I prefer. I'm not very into gaming, but the few games I do play work just fine without Pulseaudio. I also don't do live streaming, so no real need for complex audio routing.Not sure why Pulseaudio was created in the first place. The JACK GUI looks to be just as intuitive to use for routing signals as physical audio hardware.

author: Monkeh
author_rank: Super Contributor
timestamp: July 10, 2019, 07:36:20 pm
content: Quote from: NiHaoMike on July 10, 2019, 03:41:26 pmBecause ALSA is utterly terrible to configure, and JACK is very complex and prone to problems.

author: Bassman59
author_rank: Super Contributor
timestamp: July 11, 2019, 05:46:56 pm
content: All of the pro audio people I know use Macs and spend zero seconds dicking around with Linux and its famous lack of support for audio. There are a few instances where we run Windows (either cheap laptops or a VM) because off-line editors for some digital mixing consoles and control software for processors is Windows-only, but everyone has Macs. We have jobs to do, and don't want to spend time dicking around with Linux.If Linux would support multi-channel interfaces from MOTU and Apogee and the like, that'd be great. That's not a Linux issue per se, that's more on the device manufacturers. But as usual, the vendors have to see a market. Is there a Linux-based DAW on the order of Logic or ProTools?

author: Monkeh
author_rank: Super Contributor
timestamp: July 11, 2019, 06:34:03 pm
content: Quote from: Bassman59 on July 11, 2019, 05:46:56 pmWhich is nonsense, there's always been audio support and it's been the best it can be with no documentation, no vendor assistance, vendors actively sueing developers, and so forth.QuoteChicken, meet egg. No hardware -> no point in software. No software -> no point in hardware. Perhaps the companies making hilariously large profits would care to improve matters?

author: ve7xen
author_rank: Super Contributor
timestamp: July 11, 2019, 08:10:47 pm
content: Quote from: Bassman59 on July 11, 2019, 05:46:56 pmIf vendors would use standards like the USB Audio Class rather than implementing their own janky device protocols, then they would just work (tm). To be fair, Windows has shit support for USB Audio Class 2, so there was a bit more reason for them to do their own thing, but it would still make more sense to implement UAC2 and write a driver for it than start from scratch. And if they feel the need to do something weird, if they would document their janky protocols so that someone else could implement drivers. This complaint really grinds my gears - there's no reason for it other than vendor idiocy.QuoteI'm not an audio engineer, so I have no idea the relative 'goodness' of it, butArdouris pretty polished and I've fooled around with it for a few projects. It seemed to work well and be pretty featureful. Like much open source software, it's probably not on the order of a $1000s niche professional tool, but likely gets 90% of the way there. And you don't really need to spend long dicking around to try it out, just download an Ubuntu Studio live CD.As far as the topic at hand, I don't really have a problem with Pulse. It's flexible enough and simple enough for everyday use, and for the past few years it now works reliably. Pretty similar in capabilities to the Mac audio server, I think. It could be a little less obtuse in its terminology and configuration, but for the most part you don't need to touch it. JACK of course is the most flexible thing I'm aware of on any platform. It's pretty neat what you can do with it.

author: Ampera
author_rank: Super Contributor
timestamp: July 11, 2019, 11:33:56 pm
content: I think you guys are getting a bit backwards here.For me, this is awesome because I use Linux, and want great audio. Linux /does/ have perfectly fine audio examples that, if you know how to use them, work amazingly well. JACK is one of these examples, and it is the go-to choice for /all/ Linux audio engineers and hobbyists. There is no real problem with JACK, and I'd argue it's as good as any other solution out there.My issue, and the issue of so many other people is in using Linux as a desktop operating system, for desktop tasks. PulseAudio is geared towards this intent, with a simple to use design intended to be more plug and play than actually diverse and usable, much like Windows Audio. What is so awesome here is that now, on Linux, you can have the flexibility of JACK, with the program support of PulseAudio, in a fairly simple configuration (start JACK, start PulseAudio, load module-jack-sink and module-jack-source for however many programs you wish to route separately).If you like your Mac environment, that's great, but that's not what this is about, and I'm not telling you it's time to ditch your fruity DAW, I'm saying for average Linux users who occasionally want to do fancier routing (we are the type who often like to tinker in general), that an easy to use solution exists that I've used, but just isn't well documented.

author: NiHaoMike
author_rank: Super Contributor
timestamp: July 12, 2019, 02:26:02 am
content: Quote from: Monkeh on July 10, 2019, 07:36:20 pmMy experience as of the last 10 years is that ALSA "just works" if basic audio playback and recording is all you need. Why couldn't Pulseaudio just be a lightweight abstraction on top of JACK or ALSA?

author: Ampera
author_rank: Super Contributor
timestamp: July 12, 2019, 09:07:16 am
content: Quote from: NiHaoMike on July 12, 2019, 02:26:02 amNot sure what you mean by lightweight, as that's relative, but that's effectively what it is.

author: NiHaoMike
author_rank: Super Contributor
timestamp: July 12, 2019, 01:16:28 pm
content: I was thinking that it should present a simplified way to configure ALSA and/or JACK, but do only minimal processing of the audio data itself. I have a clue a lot of the criticism revolves around the processing that is actually not necessary for common uses. In my experience, apps that actually need elaborate audio processing (e.g. games) make use of libraries like SDL.

author: Ampera
author_rank: Super Contributor
timestamp: July 12, 2019, 01:50:07 pm
content: "processing" here means "mixing".As far as I am aware, ALSA does not have great native support for mixing two sources of audio to one output, like trying to run multiple programs. For the longest time it didn't have any, thing I believe something came along that allowed it to do that, but it doesn't work very well, and is indeed why we have sound servers (or one of the reasons) on Linux in the first place.PulseAudio does all that it needs to do, the big complaints are about it being a pain in the ass to configure (as opposed to JACK), incredibly simplistic, and not giving two shits about concepts like latency. It makes up for this by having high software support above ALSA (for whatever reason), potentially having nicer library implementations (afaik ALSA's are a bit stupid, but I could be wrong), and for in generally being more of a requirement than a benefit to any system, especially once you've seen JACK (though it does have its own problems).This configuration makes me hate PulseAudio, and audio on Linux much less, as I can now do all the fancy routing I've always wanted to do (and up until this point was never able to do) while still using my environment, with my programs, and almost no complicated configuration or QoL hits.

author: NiHaoMike
author_rank: Super Contributor
timestamp: July 12, 2019, 02:45:41 pm
content: ALSA has had dmix for a long time, only used on hardware without hardware mixing. It was enabled by default at one time although audiophiles generally disable it as it conflicts with bit perfect playback.It also turns out a lightweight alternative to Pulseaudio does exist.https://github.com/i-rinat/apulse

author: Ampera
author_rank: Super Contributor
timestamp: July 12, 2019, 09:45:50 pm
content: I've used apulse, it doesn't work on the programs I've tried, maybe different now.