Audio systems in Linux are terrible. You’ve never known true pain until you’ve tried to set up a recording or broadcasting workstation running Linux. I did, twenty years ago, and nothing has changed since. This wasn’t really a problem when Linux was either used in server spaces or some nerd’s battle station, but now we have small single board computers that everyone uses and wants to turn into a modular synth. Welcome to paintown, because the Linux audio stack is terrible.
For the past ten years, [Dynobot] has been working on improving audio in Linux. This is a decade of reading manuals from IBM and Oracle, and a deep knowledge of how to adjust settings so audio actually works. All of this work is now combined into a single script that improves everything. This means the priority of the Audio group is changed, the thread priority is better, the latency is better, and for anyone who wants to set up a local streaming service, the network latency is better. It’s not everything, and there’s no mention of recording multitrack audio, but we’ll accept the baby steps here.
There are two relevant Github repositories for this, the first containing audio adjustments for Debian-based systems, including the Raspberry Pi. This should work on any single board computer running Debian, and has been tested on all the Raspberry Pis, the Allo Sparky, ASUS Tinkerboard, and the Odroid C2. There’s also a version for TinyCore-based Linux systems that improves the priority of the audio threads, changes the thread scheduling from ‘whatever’ to FIFO, and improves the latency. If you’re running Linux, and you’re doing something with audio, this is what you need.
This…is really good news, thank you.
I have a box here still running the last realtime kernel ubuntu studio, 9.04 I believe it is, have to look.
Now if the drivers for my Delta44 were any good…
Yes, thank you! Any progress on this front is welcome.
Recently, Linux Mint has done something to make audio work (I don’t know what), which is also much appreciated.
I remember spending hours searching Google to figure out what incantation to use to make audio work on some of my previous Linux installs. It seems like audio should be easy, but apparently not….
The biggest problem with Linux audio was when they tried to make it work like the overcomplicated Windows audio system. My home PC just uses plain ALSA with dmix disabled – basically just streaming the bits directly out the S/PDIF port.
You are complaining about Linux Audio now. Back in the day all we had was Sound Blaster cards and we had to make our own drivers for Software Audio cards that had drivers in Windows but not in Linux. The same for Dial Up modems and DSL Modems.
And don’t get the IRQ jumpers wrong or your sound will stop working whenever you move the mouse.
Ahh, the good old days before Plug and Play.
I never did get why people hated setting those jumpers so much. Was it really that hard?
Rule 1 – don’t put two things on the same number
Rule 2 – Some things have standard IRQs or memory addresses (like the first couple of com or lpt ports and things like modems that included internal com ports). You can chose not to use them but if you do software configuration will be harder. So just do yourself a favor and use them.
Most of the time follow those and you are good.
It only got a little harder if you had an unusually large number of peripherals. Then you might HAVE to share IRQs. Some kinds of hardware would tolerate that. Some wouldn’t. So know which is which. But it was only necessary anyway if you had a REALLY “tricked out” PC so… meh.
These days things usually do just work but for the first 10 or 15 years or so after the hardware manufacturers stopped giving us the option to hard-set our IRQs and memory addresses via jumper it sucked. Plug n Play or “Plug n Pray” as we called it was ridiculously buggy for a long time! I had a hard time believing what I was seeing, that companies could get away with marketing such junk!
Yes, it’s much better now. But I still wonder how much boot time could be saved, OS complexity and therefore bugs could be reduced if we just went back to hardware jumpers.
“Plug n Play or “Plug n Pray” as we called it was ridiculously buggy for a long time!”
That’s because you’re thinking of ISA Plug and Play, which was ‘back implemented’ into ISA. Which means you mixed devices who could configure themselves and be interrogated to figure out what they were trying to use with devices that *couldn’t*, *and* you were doing it on a bus that couldn’t guarantee you were talking to a single device. Of course it wasn’t going to work well.
In order for any autoconfiguration process to work well, you need to be able to interrogate all devices on the bus to find out what they’re using (so you know what resources are available) *and* the ability to speak to only 1 device at a time. ISA didn’t have that. PCI, PCI-Express, USB, etc. all did, which is why autoconfiguration works fine on them.
“Yes, it’s much better now. But I still wonder how much boot time could be saved, OS complexity and therefore bugs could be reduced if we just went back to hardware jumpers.”
Oh my God, no. You’re seriously crazy for thinking that.
For devices like serial ports, you don’t need too many jumpers. Obviously for ‘standardized’ COM ports you only need 2 jumpers, since there are only 4 options to select from.
But even if we limit ourselves to “dumb” I/O boards which *only* communicate via a base address in I/O space and the ‘classic’ master/slave PIC, you’d need 15-16 jumpers to set the base address and 12 jumpers to set the IRQ line. That sounds like tons of fun to configure.
But nowadays it would be *far* worse than that. The amount of peripheral configuration that an operating system does dynamically now would require *hundreds* of hardware jumpers. Locating the base address alone – which is the minimum thing you could do – would take 62 jumpers! It would also be incredibly stupid, obviously, because PCI, USB, PCI Express all have perfectly working isolated configuration space accesses.
The complexity and time it takes to configure everything *reduces* bugs, it doesn’t *increase* them, because the OS can literally make sure that all of the hardware it *thinks* is there is still there, and put everything back into a known state.
If you *wanted* to you could build an OS which doesn’t bother trying to map everything into viable configurations, but which uses a static configuration based on some configuration file and just dumps the configuration into each one immediately at boot. That’s basically what Linux does with device tree files.
My crew called it “Shrug and Pray”.
Right! We bought motherboards based on what IRQs were available.
I had people call me on the phone and ask me what IRQs they should use with whatever device they were trying to install.
Getting sound to work was a triumph!
Plug and Pray was exactly what it was when the vendors wouldn’t tell you anything about the hardware you were trying to get working which is still a problem today sadly.
Crap, I remember having to cut a trace and solder a wire to a different irq line on the isa bus to get sound working on my old 386 compaq.
Sound blaster cards!
Luxury!
I still have my homebrew parallel port to R2R to LPF to lm741 8bit audio sound ouput device lying around.
Parallel port!
Luxury!
I still have the cup and string that I had to wiggle by hand at a frequency dictated by a series of indicator lamps. Going over 10KHz really made the forearm ache.
You had cups? Sigh.
Wait, you had string?
Sound Blaster?
I guess you didn’t have it’s predecessor, the Game Blaster.
I did, and I wish I didn’t, so I could have spent that money on something really useful.
I recently tried to get a simple console level CD player going on my Debian box. Cdcd found libcdaudio and pretended to play the music, to complete silence. MOC will play WAVs, but not from the (sorta) file system on an ordinary CD. Mplayer works, but has a 6,500 line (or so) man page, and uses long cryptic BASH commands for anything you want to to. (Best to put them in a script file or an alias.)
Fortunately, the X-based players work much better!
If I remember correctly libcdaudio makes the CD drive play the audio, CD drives used to have (not sure if they still do) an audio jack for that output which you could route through your sound-card. Certainly modern systems don’t tend to have that audio connection made.
So your problem in this case wasn’t really to do with the Linux sound system.
That’s correct. Just tossed a handful of those cables in the recycler.
Yes, when you use libcdaudio to play a CD, it sends the audio directly through an analog output on the optical drive (if the drive has one, which I don’t believe is guaranteed with new drives) which must be hooked directly to an input on your sound card or motherboard. If the drive and the motherboard / sound card still have the ports, I still hook those cables up (which means most of the time I don’t), but they aren’t used most of the time anymore.
Really, though, I just rip my CDs to files anyway. You can use FLAC if you want “perfect” reproduction, or Ogg Vorbis or Ogg Opus if you don’t mind a lossy compression in order to save more space. Then the files can be played from the command line or a GUI with no problem.
Whippersnappers!
Back in my day we had to compile ALSA and patch it into the kernel ’cause OSS was a dual-licensed thing which supported almost nothing in the free version in the mainline. And your Yamaha DS-XG or whatever had really strange volume levels that you had to go in a nearly peg the mixer after every boot. And you did it in the terminal because X-configuration apps were barely a thing and half broken when they had your option.
Whippersnappers? Compile ALSA?
HA HA HA HA!
You mean ALSA already existed in back in “your” day?
Linux used the Open Sound System (what BSD uses today) for years before ALSA was even a gleam in a programmers eye.
“My name is Linus Toravalds and I pronounce Linux Linux”
If you don’t read that quote and immediately think “sndconfig” you had better go check your baby teeth for wiggles.
….Shouts “pulseaudio” and runs away….
…screams in terror…
Seriously, though, ALSA is fine for most everything but can be a configuration nightmare. Once it’s set, it’s solid.
JACK and JACKv2 (potayto, potahto) are awesome.
Pulseaudio has been nothing but trouble for me, which is a bummer b/c it’s the default in Ubuntu among others.
I can’t imagine doing anything serious with audio on Linux *without* using JACK.
JACK / ASIO? I know only ASIO and for me it works well enough, doesn‘t it? What‘s with JACK? Any experiences?
Linux audio is indeed a total train wreck and crap shoot. If you works, you are luckly. If it doesn’t, you are screwed and there is no hope. Buying a USB sound dongle can sometimes solve things when you are hopeless, but troubleshooting sound that doesn’t work? Forget it. I’d rather get a root canal.
I had to get a root canal a few years back. My dentist specialized in children and he was super gentle. After he was done i said “THAT was a root canal?? Why do people make it sound so bad?”
There are alot of things i would rather get a root canal instead of. Like a Greyhound ride especially.
I miss the days before all those peripherals were merged onto the motherboard. No Linux drivers for my sound card? No problem! <Pops it out and pops in a new one>. Video card? Network Card? All the same. Sure it cost money but It appeared to be a one time deal. I would of course just buy a new motherboard/CPU when it was time to upgrade and move all the old card over. The first couple generations of my PC even the RAM could move with me.
Having a 100% Linux compatible PC was easy! Just don’t buy any parts before reading up on it’s Linux support online.
Then ISA went away. Then PCI (not express) became legacy with only maybe one port or so per mobo. And newer versions of everything are all soldered on anyway.
The other day I remember seeing an article about the latest Xorg having an update for the SiS6326 driver. It was questioning why they bothered and if anyone even still uses that old of a card. I got a chuckle out of that. Back in “my” day that was the chip in seemingly every budget video card. Go to the store and buy a new card, if you aren’t shelling out for gamer video it probably is a 6326. Buy a box PC from a store? If it’s not a gamer PC it is a 6326. But 6326 was not yet supported in Linux! You had to really go out of your way (or pay a lot of money) to find something else. I guess somewhere along the way it finally got support. (probably after it ceased to matter). Now it still gets updated. How I wish I could send that code to myself via a time machine!
I did a fair bit of multi track recording on Linux. Using Firewire multi channel interface (focusrite Saffire) via jackd into ardour. This was because I was sick of protools (7 or 8) crashing on OSX. Now I’ve swapped ardour for the Linux build of Reaper.
I found the main source of difficulty wasn’t Linux but drivers, many of the cards/interfaces required specific drivers and many manufacturers didn’t play ball. But I didn’t come across all of the doom and gloom that surrounds Linux audio.
Some cool little tools built around Jack. Loved a tool that used a circular buffer to record constantly, let you hit record to capture “back-in-time”. Was great just after you played something and thought that was awesome did I record that?
I didn’t realize audio in linux was bad..
I mean, I’ve tried audio in windows.. In linux I have pulseaudio and pavucontrol, wonderful tools that allows me to route different applications inputs and ouputs just as I see fit. In windows, getting an application to even understand that the “output device” has changed seems like a pain, and, unless the application itself supports it, there’s no convenient way of making one application play on one device, and another on a different device, and just forget all hopes of looping audio around between two applications..
voicemeeter banana or voicemeeter potato is your friend
The bad part of Linux audio is that there’s both Jack and Pulse. Pulse took a very long time to not be total garbage.
JACK isn’t supported by everything, it’s meant for pro audio. Pulse can’t do low latency.
I’m really hoping PipeWire fixes the whole mess.
Right now I’m on and off trying to build an audio mixer that can replace HW mixing boards with lots of USB soundcards and resampling, and JACK seems to be the only reasonable option.
Aw crap, this diagram needs to be updated to show where PipeWire fits: https://i.warosu.org/data/g/img/0519/10/1450374432445.png
Hmm…disagree.
I have not only a complete tri-amp system in my man cave, voice over system in my office and multitrack recording system at the theater where I’m tech director, and in the process of adding recording studio at that theater.
All use Ubuntu Studio or AvLinux and JACK audio.
And, I love Ardour.
This smells of bullshit. 10 years reading manuals for a few easy tweaks, yeah right. The OP reads like one of these inflated ego wannabe experts, great it took you 10 years to learn some basic settings but don’t get too full of yourself. And empirical listening tests, you wot? None of these settings would change the sound at all, unless the audio was stuttering, there’s no “best sounding” settings. Which brings us to the next problem, these settings are in no way universal and the optimal values depend on many factors.
Also, about the article, nothing has improved in 10 years, really? Linux audio being horrible has become a meme at this point and is blown out of proportion when in reality, it just works on most systems nowadays.
+1
You are so right with all you say. And besides the improvement over the past decades linux audio has many advantages over any other OSes audio implementation which would be low latency, easy patching, network transparency, multichannel capabilities (recording and playback), codec abailibility to name only a few.
Sure you have to know what you are doing but playing in a band and having a guitarrist who is Aplle fanboy I can sure say – the moment we plug a second (or third) audio interface in his MAC he has to redo all settings in all involved SW parts and he never knows which device goes where. Multitrack recording with MAC OS sucks hard. I use jack on my linux machine and get a pretty nice latency of 5.2ms with my Behringer UMC22 (a USB! audio interface) and of course it sounds excelent because audio is digital when it reaches the PC. How are you supposed to improve this? Oxygen free bits?
I have a linux box running VDR and MPD using two audio devices with SPDIF/TOSLINK outputs and they stream everything to my surround amp. PCM, DTS, AC3 you name it, I play it. And again – it sounds great ’cause it’s digital. And this setup works for decades now.
Linux audio just works!
I just wish Linux audio was remoteable in the same way that X is.
If I log in remotely and start music playing I want the terminal I am sitting at, the one that is displaying the video to play the audio. And I don’t want to have to type any extra commands, start a streaming server or anything like that to make it happen. X apps know where to display because a $DISPLAY variable is automagically set when I log in. Audio should be the same!!!
And if 2 people log into the same machine at the same time from different locations and both play audio.. each should hear their own audio coming out of the terminal they are logged in from and only their own audio!
Back in my early days, when I was just starting to switch to Linux from Windows I thought Linux was awesome in part because it had remote display capabilities baked in. Back then Windows remote desktop did not exist and to get that functionality on Windows one had to buy expensive 3rd party software.
I thought bringing audio into it was a natural extension that surely would be coming shortly.
Now 20 years later Windows had had remote desktop WITH AUDIO for over a decade now and Linux is still no better than it was! And worse, with that damn Wayland being pushed on us we might not even have remote display soon.
Way to move backwards! What’s next, no more multitasking?
I know pulseaudio can do remote sound, but it wouldn’t be synchronised with your X forwarded display.
Lots of things can do remote sound. That was never my problem. I used to do it using Arts ages ago when I was in college. That kind of sucked though because what I wanted was to be able to fully interact with my pc using school lab PCs or friends’ PCs in their dorms. Those were all Windows and there was no Arts client for Windows. I could at least use it with my laptop though.
Then came eSound. YAY! eSound had a java client! I had my PC serving a web page that included SSH, VNC and eSound clients as java applets. But what a PITA to get it all connected!
Now there is PulseAudio. It can be used similar to eSound but is a lot harder to configure. The fact that there seems to have been several changes making changing the contents of it’s configuration files in the past (typical Poettering) thus trying to find any help via Google is useless unless you already know it well enough to identify which posts are talking about outdated information doesn’t help. (if I knew it well enough to do that I wouldn’t need to search for help would I)
What I really want though is remote audio that is as simple to use as X. When I start an X application in a remote terminal regardless if it is in VNC or ssh with X forwarding or whatever the application just knows where to display. (ok it’s the $DISPLAY variable but I don’t have to know that). It just works! Why aren’t audio servers written to work the same way? How can not working that way not be a bug?
Is that what you (Shannon) meant by “synchronized”? Or did you mean synchronizing video frames with the audio track? Is that why we don’t have this? Because developers think that to do it right it has to be perfectly synchronized?
I don’t think so. Don’t get me wrong, it would be nice to get that perfect. Just having sound though would be a big improvement over not. If I want to watch a movie I don’t expect VNC to be the best way to do so! That’s not what it is for.
Well, anyway. PulseAudio does have some sort of Xorg plugin. Is this what it is supposed to do? If so has anyone ever seen it actually work? I looked pretty hard but couldn’t find any non-ambiguous documentation regarding what that does or how to use it.
“Audio systems in Linux are terrible.”
Thus, the opening sentence makes the byline redundant.
B^)
Not everyone that runs Linux is looking for audio so the default settings may not be ideal. Those that are focused on sound should expect to do some configuring to get what they’re after. Most who make an effort tend to be satisfied too. And yes digital audio can tend to get complicated. That’s the nature of the beast. 99% of the people I’ve helped with audio problems in Linux just needed to turn mute off in a mixer. Oh and PulseAudio is cancer.
pfred1@five:~$ aptitude show pulseaudio
Package: pulseaudio
Version: 10.0-1+deb9u1
State: not installed
What?!?!
Not everyone wants it so the default configuration should be crap. Is that what you are saying?!?!
If you are building a server or some other no-audio computer then don’t install audio drivers. Don’t install OSS, Alsa, Pulse, etc… When setting up a server most of us use cut down installers that do not include Xorg and I would think would not include the above things though I haven’t checked. When setting up a desktop machine one uses a desktop installer that will include X, a desktop manager and a ton of crap that nobody wants on their server.
That desktop installer has no excuse not to get the default sound configuration right. There may be some portion users that do want an otherwise full desktop install but minus the sound. They will be a small minority and have many choices. First they can simply not plug in speakers. Second they can hit the mute button. They could also take the hard route and start uninstalling all the audio support if they are that OCD about it. Defaulting to a bad sound configuration though for desktop installers.. that is a bad idea.
If you want good sound get a USB external DAC. My MusicStreamer II works fine with Linux Mint and no drivers were required.
Stopping and disabling irqbalance is also highly advisable, as I noticed recently.
And modifying /etc/pulse/daemon.conf according to https://medium.com/@gamunu/enable-high-quality-audio-on-linux-6f16f3fe7e1f.
Thank you so much for this, it works like a charm.
I have tried Voicemeeter’s produce and got nowhere. I thought I didn’t know Jack but by clicking and learning I ran two instances of ZynAddSubFX and put one on the front pair and the second on the rear pair and lush quad sounds happened. Audacity has wasapi for Windows which is a click or two to record any stream. Jack can do the same, to screw the hole-e-wood recording cartel.
In terms of audio, Ubuntustudio (one word) is a single download-install that does it all has it all. Ready to go, yes you have to click down into the mixer to view all of the sliders and buttons.
> Audio systems in Linux are terrible
> twenty years ago
Why waste 10 years of your life when there is BSD???
I tried BSD. It was on my laptop for a few months last year.
It’s like Linux but just ever-so-slightly less bloated
Things are named ‘funny’ (to a Linux user)
And there is no way to watch Netflix.
And that is why I am back on Linux. I had Netflix to watch.
It was a fun challenge to get jackd and ffado (firewire audio hardware) working well enough to do multi-track audio recording 10-15 years ago. I recorded a bunch of songs for my band using all the array of open source plugins. It was a great hobby in and of itself, and a triumph to have access to thousands of dollars worth of effects on an open source system running on a Dell D620 laptop. That was actually a complicating factor because the laptop ieee 1394 interface didn’t have the desirable Texas Instruments chipset for making ffado run cleanly… still had a minor amount of xruns and generally had to disable the wireless network to keep the audio performing well. I was about to buy a card for the PCMCIA card to remedy that, but moved away from the band and haven’t got back into it.
I’ve had nothing but trouble with Jackd.
I want to get Jackd off my computer.
Has anyone here ever gotten Jackd off?
Can someone help me get Jackd off?
Hello, what about AV linux with RT Linux in it , The latency is done to 1ms, if i remind correctly ..
AV linux is here and update
http://www.bandshed.net/2019/04/03/av-linux-2019-4-10-released/
hey people, talking about 20 years ago is fine, but in 2021, following your links seems rather complicated too. should i take my soldering iron to take all these 404s away ? moreover, i use a redhat type system (fedora), which is certainly bad, but has a linux kernel inside like the others. with more new additive components supposed to simplify audio handling, like pipewire and wireplumber (i don’t invent), and the result seems to me even more messy than before. of course i can boot windows to run reaper, or even a debian os if i was sure it would fix anything, but it annoys me a little bit. is there any synthetic doc somewhere, with alive links, to try to understand how all this patches ball is supposed to work in linux ? thanks to any respectuous answer :)