A guideline for minimal audio configuration

Optimize your system for ultimate performance.

Moderators: MattKingUSA, khz

Post Reply
crocket
Established Member
Posts: 68
Joined: Fri Mar 29, 2019 11:56 am

A guideline for minimal audio configuration

Post by crocket »

If you don't stick to this guideline, expect to spend weeks and months and still experience sound problems.
  • Don't make ALSA or pulseaudio send audio to JACK through alsa_in, alsa_out, zita-ajbridge, alsa jack plugin, pulseaudio jack plugin, etc, ...
    • If you do it, expect xruns, crackles, and pops.
  • If you want to send audio over network, use netjack with jack.
  • Do not add more than one soundcard to one jack server via zita-ajbridge, alsa-in, or alsa-out.
    • If you do it, expect xruns, crackles, and pops.
    • But, this is still doable if you know how to tweak real-time process priorities with cgroup CPU real-time scheduling or fully preemptive linux kernel.
  • You can alternate between ALSA PCM devices by sending audio to multiple ALSA PCM devices simultaneously and un-muting only one mixer control at a time via a small program that you write.
    • To send audio to multiple ALSA PCM devices simultaneously, use route plugin on top of multi plugin on top of dmix or hw plugin.
Minimalism pays off by freeing a lot of your time for really important things.
Last edited by crocket on Tue Dec 17, 2019 1:08 am, edited 9 times in total.

User avatar
milo
Established Member
Posts: 698
Joined: Wed Sep 06, 2017 2:55 am
Location: Southern Utah, USA
Contact:

Re: A guideline for minimal audio configuration

Post by milo »

crocket wrote:Minimalism pays off by freeing a lot of your time for really important things.
I generally agree with that sentiment.

Correct me if I'm wrong, but doesn't JACK sit on top of ALSA? I didn't know it was possible to run JACK without it.

User avatar
CrocoDuck
Established Member
Posts: 1103
Joined: Sat May 05, 2012 6:12 pm
Contact:

Re: A guideline for minimal audio configuration

Post by CrocoDuck »

milo wrote:Correct me if I'm wrong, but doesn't JACK sit on top of ALSA? I didn't know it was possible to run JACK without it.
You are correct. Jack runs in user space and it routes audio to a back-end. Doesn't have to be ALSA: it can be OSS, FFADO, Core Audio (on macs) or many others. The actual audio functionality on your system is provided by the audio drivers. In Linux world, those are typically provided by ALSA, which in fact is part of the Kernel itself.

crocket
Established Member
Posts: 68
Joined: Fri Mar 29, 2019 11:56 am

Re: A guideline for minimal audio configuration

Post by crocket »

milo wrote:Correct me if I'm wrong, but doesn't JACK sit on top of ALSA? I didn't know it was possible to run JACK without it.
It's very difficult for an ALSA playback device or a pulseaudio sink to send audio to JACK without xruns or a lot of latencies.
On the other hand, it's very straightforward for JACK or a pulseaudio sink to send audio to an ALSA playback device.

Openmastering
Established Member
Posts: 43
Joined: Thu Dec 05, 2019 10:27 am
Location: Tübingen, Germany
Contact:

Re: A guideline for minimal audio configuration

Post by Openmastering »

@crocket

I love to disagree with you.
• First, because my experience is different. Pulse audio is always bridged to jack on my system and it never caused a dropout/xrun. I have to run it on my commercial machine because my customers always said "hey check this video, I want to sound like them". And I can't afford saying "ah, wait a minute, I just need to close your session, kill Jackd, start something else and... Magic!
So I'm glad it "just works". I'm using a vanilla Ubuntu and cadence with its bridge.

• Second I'd love to hear more about why. Is it a personal experience? A kind of trend? Where is the real problem exactly? Resampling? Devs wouldn't release those bridges if they didn't work at least for them. So is it a soundcard problem? Drivers? Please give us some background to your statement.

• third, it shouldn't be like that.
Don't get me wrong, Jackd is great and I use it daily, even for commercial purposes, but why is audio on Linux such a problem? Why can't we just have something that works? Or even 2-3 audio backend that are working. GNU/Linux has loads of display managers. And they all do their thing.
</Rant>

In the end, I can say that Linux audio might be a pita or not.
As I started using it, it wasn't anywhere near where it is now. I'm endless grateful to all those people working on and with it. And I'm proud to be a part of the community.
Audio mastering for open minds: https://openmastering.studio
I master music using only free/libre softwares and DIY hardware.
Contact me for a free mastering sample.

crocket
Established Member
Posts: 68
Joined: Fri Mar 29, 2019 11:56 am

Re: A guideline for minimal audio configuration

Post by crocket »

Openmastering wrote:Pulse audio is always bridged to jack on my system and it never caused a dropout/xrun.
Openmastering wrote:Is it a personal experience? A kind of trend? Where is the real problem exactly? Resampling? Devs wouldn't release those bridges if they didn't work at least for them. So is it a soundcard problem? Drivers? Please give us some background to your statement.
Does your pulseaudio jack sink maintain a constant low latency while CPU and HDDs are under full loads for at least 5 minutes? My CPU cores are often under full loads for linux kernel compilation and linux package compilation. I use Gentoo Linux.

I don't think you can maintain total latencies below 50 milliseconds under full loads with a pulseaudio jack sink and jackd. Pulseaudio is not designed for low latency under heavy loads. You want latencies below 50 milliseconds for synchronization between video and audio. In other words, lip sync. Plus, pulseaudio doesn't allow me to tweak samples per period and periods per buffer. Pulseaudio's port system is flawed, too. I chose headphone port in pulseaudio, and my speakers and headphones were both getting sounds. At least, with ALSA or JACK, I can configure them manually exactly as I like. Pulseaudio tries to automatically configure ALSA mixer controls, and I couldn't disable its automatic mixer control configuration.

I dedicated months to eliminate xruns, pops, and crackles between the bridge between ALSA and JACK. I made it work. I literally watched videos while CPU and HDDs were under full loads, but I stopped using it because maintaining it without xruns consumed a lot of time for very little rewards.

Anyway, if pulseaudio jack sink works for you, keep using it. I think that's the minimal solution for you for now.

Openmastering
Established Member
Posts: 43
Joined: Thu Dec 05, 2019 10:27 am
Location: Tübingen, Germany
Contact:

Re: A guideline for minimal audio configuration

Post by Openmastering »

@crocket
You raise interesting questions. And you're entirely right that Pulse audio wasn't designed for low latency.
I have to admit I don't compile Linux kernels while doing audio work.
And the bridge is just a mean to quickly watch/listen to something outside of the jack ecosystem. I'd be much more concerned if I had to record some Skype calls, using both PA and Jackd while doing production stuff.

I'll try putting my system under load, and see how (un)stable it is. Do you recommend a specific way to test this?
Audio mastering for open minds: https://openmastering.studio
I master music using only free/libre softwares and DIY hardware.
Contact me for a free mastering sample.

merlyn
Established Member
Posts: 693
Joined: Thu Oct 11, 2018 4:13 pm

Re: A guideline for minimal audio configuration

Post by merlyn »

It's fairly obvious not to compile a kernel while using low latency audio.

In @crocket's other posts he was listening to mp3s and using JACK to switch between speakers and headphones.

This may be possible while compiling a kernel by pinning processes to cores -- leave a core free for audio.

The most reliable way of using two soundcards I have found is audioadapter -- a JACK internal client.

@crocket's findings are not particularly relevant to audio production.

User avatar
milo
Established Member
Posts: 698
Joined: Wed Sep 06, 2017 2:55 am
Location: Southern Utah, USA
Contact:

Re: A guideline for minimal audio configuration

Post by milo »

Openmastering wrote:I have to admit I don't compile Linux kernels while doing audio work.
LOL. I think we found the problem.

I had a good friend back when I was in school who was a Gentoo user. Always compiling something-or-other. "Why would I use someone else's binaries?" he used to say, as if he just couldn't see the price he was paying to have such a sleek and efficient system.

I was an Ubuntu user at the time -- this was before the Unity desktop fiasco left such an awful taste in my mouth that I vowed to leave Ubuntu and never return -- and I rather liked the time efficiency of using official binaries from trusted repositories.

Guess which one of us is still a Linux user? I talked to my friend a few years after graduation and was surprised to learn that he had burned out of Linux and was now using Windows. Why? Because it took less time to maintain his Windows computer! Now that he was a busy dentist he just didn't have time to groom all of those text files and compile all of those binaries himself.

crocket
Established Member
Posts: 68
Joined: Fri Mar 29, 2019 11:56 am

Re: A guideline for minimal audio configuration

Post by crocket »

Openmastering wrote:I'll try putting my system under load, and see how (un)stable it is. Do you recommend a specific way to test this?
stress-ng --iomix 8 --ionice-class idle -t 5m

or

stress-ng --cpu 8 -t 5m

8 is the number of my CPU cores. Be careful with IO tests because it burns an SSD to death quickly.
I burned an SSD to death by running "stress-ng --iomix 8 --ionice-class idle -t 5m" multiple times.
Stress your CPU cores, but not your storage devices.

crocket
Established Member
Posts: 68
Joined: Fri Mar 29, 2019 11:56 am

Re: A guideline for minimal audio configuration

Post by crocket »

milo wrote:I had a good friend back when I was in school who was a Gentoo user. Always compiling something-or-other. "Why would I use someone else's binaries?" he used to say, as if he just couldn't see the price he was paying to have such a sleek and efficient system.

I was an Ubuntu user at the time -- this was before the Unity desktop fiasco left such an awful taste in my mouth that I vowed to leave Ubuntu and never return -- and I rather liked the time efficiency of using official binaries from trusted repositories.

Guess which one of us is still a Linux user? I talked to my friend a few years after graduation and was surprised to learn that he had burned out of Linux and was now using Windows. Why? Because it took less time to maintain his Windows computer! Now that he was a busy dentist he just didn't have time to groom all of those text files and compile all of those binaries himself.
Gentoo is not about producing efficient binaries. Gentoo is about producing perfect binaries that work with each other and about freedom of system configuration. You can compile firefox with ALSA but without pulseaudio on gentoo. You can even compile firefox with JACK on gentoo.
The Firefox binary produced by Gentoo's package system works perfectly while firefox binary from Arch Linux sometimes is buggy due to linking errors made by repository maintainers. I could not get a perfect firefox binary on ArchLinux. My gentoo system uses only ALSA.

Also, after you get the hang of gentoo maintenance and document the upgrade process, you never have to spend much time on maintenance anymore unless you want to compile packages for ARM single board computers(e.g. Raspberry Pi) on X86 machines.

If all you do is to maintain a single desktop computer, Gentoo is perfectly useable by a busy dentist who documented the upgrade process long before becoming a dentist. The point is to document the upgrade process long before you become a busy person. Nowadays, I just open up the upgrade document and follow the procedure. It's as easy as that.

Gentoo should be learned long before you tackle your life purpose.

Post Reply