Hacker News Reader

Comment by jmillikin | Hacker News Reader

I wish Linux video would go the way of Linux audio.

Linux audio just works. There's a single userspace API (PulseAudio), a single kernel driver API (ALSA), and all the old nastiness of the '90s (ESD, aRts, OSS) is dead and gone.

In contrast, getting video to work properly involves figuring out what hardware you're running (nVidia? ATI/AMD? Intel? misc other?), then hunting down the drivers, installing them, rebooting, hoping the hardware gets detected correctly, and so on until the user gives up and settles for a half-broken system. I consider myself fairly skilled with Linux stuff, and I still can't figure out how to get my desktop to have both kernel modesetting and accelerated OpenGL at the same time.

View on HN

Except that it doesn't just work. Ignoring the hardware aspect altogether for a moment, PulseAudio itself is inherently buggy. If you run it for long enough with its volume control app open, the daemon sometimes crashes and everything stops playing sound. (It looks like that might be due to a bug in the peak volume reporting code resulting from an incredibly misleading variable name, but I'm not sure - none of it's commented, so it's impossible to figure out how it's meant to work). Resampling glitches out randomly and requires a restart of the daemon. There was a patch to the resampling code in the latest release which was outright incomplete and broken but got included anyway, and since the PulseAudio devs don't release stable versions, the only release with the fix in will be a major one with a whole bunch of new regressions. I've encountered major bugs with fixes in the Fedora package that weren't submitted upstream at all, and the patches were written and added by Lennart Poettering himself.

Then there's the hardware-specific fun: headphone outputs that don't mute the speakers when they should due to driver or hardware quirks, outputs and inputs that plain don't work, weird volume glitches where exiting one app causes all the others to shift in volume due to PulseAudio's info about the hardware volume control being wrong...

Another problem with PulseAudio is with latency and routing, which is why a lot of professional audio programs on Linux use JACK instead of PulseAudio. It's sometimes very hard to get JACK to play nice with PulseAudio, and this is exacerbated by the fact that ALSA only allows one program to use one audio device at a time. So it doesn't always "just work"...

Isn't it kinda the kernel's job to allow multiple processes to access shared resources? Imagine if only one process at a time were allowed to access the disk.

Resources that require low-latency low-level access cannot be multiplexes easily

So have multiplexing desktop mode by default, and give pros a "reduce my latency" button?

Why couldn't the kernel perform simple mixing of the audio streams with just as low latency as something like JACK?

I've heard that you can get PulseAudio to connect to JACK, which in turn connects to ALSA. The idea here is that latency-sensitive applications that use routing will connect to JACK, while applications that connect to PulseAudio (like Skype, Firefox, etc.) don't care about latency. However I haven't been able to get this to work properly (why isn't this set up as the default on any of the distros I've tried this on?)

Frankly both audio and video "just work" in Linux, and have for years. It has been several years since I bothered to look up what chips a computer had and what Linux support was like before making a purchase.

I just buy the hardware I want, assume it will work, and find that it does. Maybe I've been getting lucky, but I don't think so.

The only real remaining pain in the ass is printer support, but who the hell uses printers these days?

My HTPC has the desktop off the top of the TV and frequently the HDMI audio doesn't work.

With my ATI graphics card on my desktop I have a script that runs on startup to force the display drive to to detect my 1920x1080 monitor otherwise it displays the screen with big black bars all around the edges.

Audio and video are still a pita for me.

Proprietary driver I assume? That always has been, and always will be (as far as my crystal ball permits me to see), a clusterfuck. If you opt-in to that sort of pain, don't act surprised when you receive pain.

Have you tried this?

  sudo amdconfig --set-pcs-val=MCIL,DigitalHDTVDefaultUnderscan,0

Audio just works if you're not a power user, or use only programs compatible with each other. Try using a JACK application alongside an ALSA one and you'll see it doesn't "just work".

Even then, if you stick to ALSA applications, you'll have a few issues:

1) You're going to be limiting yourself to a lot less possibilities (Skype uses Pulse, IIRC, for example)

2) You can't have simple settings such as per-application volume control.

Sure it "just works", but it does if you use a set of programs which only the people who say "it just works" (a lot of people, I know) restrict themselves to. While it may work for you, different people have different needs.

I'm still waiting for the day Linux audio (and video, but less hopeful because of proprietary drivers) simply works in the same way it does under Windows/Mac.

Footnote: I completely forgot to mention latency issues, which is awful for audio processing.

JACK is not apart of the standard Linux sound experience for anybody but sound technicians or musicians. I'll fully concede that this particular situation may be shit, but it does not represent the typical Linux user, or even the typical Linux power user, experience.

Can't say I've ever noticed Pulse latency, even while playing Quake, except when using Pulse's networking features. Maybe I have crude ears.

I'm trying to convey the fact that you need something like JACK in order to do real time audio DSP, while in Windows/Mac, it just works. More importantly, in 2013, per-application volume control should be a given. It's possible under Pulse AFAIK, just not under ALSA.

It may not represent the typical Linux users, but while audio processing also doesn't represent the typical PC user, it works under mainstream operating systems. Until such a simple thing also "just works", I won't be happy with sound on Linux.

Basically, I'm from the group of people who want things to work on Linux for the same use cases they work on mainstream OSs before I state that it "just works". I believe saying things "just work" only because it works for most of my needs is detrimental, as it gives a wrong image and may frustrate people trying to do something different , as it has happened to me in the past, I've caught myself trying to do non-standard things a lot (read: most) of the time.

> I'm trying to convey the fact that you need something like JACK in order to do real time audio DSP, while in Windows/Mac, it just works.

There's a ton of Windows applications that take over audio and do a lot of driver weirdness. There's still ASIO incompatibilies, latency issues, etc. In fact it happens in the same space where PulseAudio and JACK intersect on Windows.

Having something that just works similar to the way CoreAudio just works would be a killer feature to have in Linux. Instead, we get ALSA and Pulseaudio, the odd couple of audio interfaces.

Did you try nVidia graphics + UEFI bios + encrypted disk?

Wasted a whole day at work with that one. The nVidia drivers don't support framebuffer consoles, only VGA, but UEFI doesn't provide VGA console I/O. And an encrypted disk needs human interaction to type the password in at bootup, meaning some kind of graphical support. Meanwhile, the non-proprietary drivers crash the X server if you so much as jiggle a window about.

Your best bet with desktop Linux is still to buy old, cheap, common-denominator hardware. Anything recent is a gamble unless you're very technically adept or have access to professionals.

"Did you try nVidia graphics + UEFI bios + encrypted disk?"

Not with proprietary drivers. AMD/NVidia's failure to produce usable drivers of their own isn't particularly relevant as far as I am concerned. In fact, it serves to highlight just how good the the FOSS drivers are at "just working".

"Meanwhile, the non-proprietary drivers crash the X server if you so much as jiggle a window about."

That makes absolutely no sense whatsoever. Frankly, I do not believe it.

It's a fact, verified on two brand new identical spec machines side by side, with GTX 670 cards. I have multiple witnesses!

All you had to do to crash X was move a window quickly from side to side. The proprietary drivers are infinitely better in so far as they don't crash.

Yeah, I was given a poulsbo netbook as a "present" few years ago.. at that time I thought cool, intel has great linux support... not! I'll stick to NVidia for now despite all the fuckyou they get.

I've had real problems with the display stack once in the last maybe 10 years. And that was simply a case of the software support for Ivy Bridge not being released far enough before the hardware, and thus not supported out of the box on the latest stable release of anything at the time. (Of course our criteria for working might be different -- I care about stuff showing up on my monitor and X not crashing. Couldn't care less about kernel modesetting).

In contrast, audio tends to randomly completely break after every other update. Most recent major breakage I had: for one whole Fedora release, the headset mic input would not work in the one app where I need it to work (Skype). Worked fine on the previous and next releases, with the same Skype binary.

Minor problems that can be worked around just randomly come and go. Right now one one machine all audio playback will stop working every few days, until pulseaudio is killed. Another computer randomly goes to a mode where all audio playback from Chrome is accelerated by IIRC 7%. Just enough to make you uneasy due to things being off somehow, but not enough to make obvious that there's a problem. This persists until pulseaudio is killed and restarted, of course, which magically fixes things.

The only time I have hunt down video drivers for Linux is when I decide to use the closed nVidia driver. Other than that it's all kernel/X supplied drivers.

You must be drunk or something.... I for example.owned a machine.where audio only worked after I installed OSS4 in the kernel. AND removed PA and Alsa so they stopped crashing some Wine stuff.

Reply on news.ycombinator.com