LPC: Linux audio: it's a mess

Posted Sep 19, 2008 3:32 UTC (Fri) by elanthis (guest, #6227)
In reply to: LPC: Linux audio: it's a mess by Richard_J_Neill
Parent article: LPC: Linux audio: it's a mess

Remove PulseAudio if you want. Don't ask distros to remove it, though. I don't know about you, but I prefer having modern conveniences like USB hot-plugged audio hardware and Bluetooth headsets just working without having to restart my entire desktop to get applications to reconnect to hot-plugged ALSA hardware devices.

I like having software sound mixing that actually works. dmix never worked right for me. Not once. The few times it played sound, it played like crap. PulseAudio just works (except for Flash). Sounds great, no skipping, just works.

You have bugs you run into, I don't. Your solution is to throw away features a lot of people need to go back to the stone age where the shitty poorly-coded drivers and apps managed to narrowly avoid each others' bugs and happen to work. Intelligent people's solution is to go "OMG bugs! Let's fix them!" And then we all have perfectly working audio all the time by default.

File bugs. Or turn PA off. But don't scream about how PulseAudio is useless when it solves problems that ALSA never has and never will be able to solve, like hot-plugged devices.

(Personally, I still think ALSA was a mistake. These days all it amounts to is Linux being incompatible with every other UN*X OS's sound interface, practically _forcing_ developers to pick a sound server or wrapper library or some such just to have their damn app work on more than one distro.)

LPC: Linux audio: it's a mess

Posted Sep 19, 2008 4:16 UTC (Fri) by drag (guest, #31333) [Link] (9 responses)

> (Personally, I still think ALSA was a mistake. These days all it amounts to is Linux being incompatible with every other UN*X OS's sound interface, practically _forcing_ developers to pick a sound server or wrapper library or some such just to have their damn app work on more than one distro.)

It's too bad that OSS didn't open source itself much sooner. It had lots of improvements that no distro could ship and the kernel couldn't support.

Considering the lack of resources devoted towards Linux sound driver development I think that the Alsa folks have done a good job.

LPC: Linux audio: it's a mess

Posted Sep 19, 2008 18:51 UTC (Fri) by dmarti (subscriber, #11625) [Link] (7 responses)

sitting at Plumbers Conference right now listening to Lennart Poettering summarizing the audio track. Problem is: "OSS is not virtualizable." Write to the OSS API and you can't feed it to a sound server -- it has to be on the hardware.

LPC: Linux audio: it's a mess

Posted Sep 20, 2008 13:12 UTC (Sat) by cortana (subscriber, #24596) [Link] (6 responses)

Isn't that the case for ALSA too if you directly fool about with the nodes in /dev/snd?

The virtualisability of ALSA comes from the alsa-lib library that all applications use. But that could, presumably, fire off data destined for the sound card to /dev/dsp instead of /dev/snd/pcmC0D0p...

Yes

Posted Sep 21, 2008 3:43 UTC (Sun) by dmarti (subscriber, #11625) [Link]

Yes, as Lennart pointed out, only 70% of ALSA apps use it in a way that will work with a sound server -- the other 30% only work if they can get access to the hardware.

LPC: Linux audio: it's a mess

Posted Sep 21, 2008 22:39 UTC (Sun) by mezcalero (subscriber, #45103) [Link] (4 responses)

OSS is practically impossible to virtualize. There are hacks like LD_PRELOAD and stuff like CUSE. But they will never be able to fully provide virtualization. Stuff like mmap audio access (which is used by far too many applications unfortunately) cannot be emulated completely. Also, the timing model in OSS is too simple to really fit on a sound server backend.

OSS as a software is dead on Linux. I really hope OSS as an API will die, too. (as soon as libsydney is more than just vaporware)

ALSA can be virtualized much better than OSS, since it has better semantics and is a shared library which supports plugins and stuff. But in the end it's an API desgined for hardware devices, and the devil lies in the details: 100% ALSA compat in PA will stay a dream.

Lennart

LSB

Posted Sep 21, 2008 23:29 UTC (Sun) by dmarti (subscriber, #11625) [Link] (3 responses)

But it sounds like ALSA in some form is on track to make it into LSB -- and once it's there, apps and distributions will depend on it and continue to support it for a long time. Possible to make sure that the subset of ALSA that's in LSB is PA-safe?

LSB

Posted Sep 22, 2008 0:21 UTC (Mon) by mezcalero (subscriber, #45103) [Link] (2 responses)

Yes, of course. Applications that use only a "safe" subset of the ALSA API should work fine with PA. That's what I'd call 70% compat.

Lennart

ALSA safe subset

Posted Sep 23, 2008 8:57 UTC (Tue) by sdalley (subscriber, #18550) [Link] (1 responses)

Is this safe subset of ALSA documented as such anywhere? If so, we need as many people as possible to BANG A REALLY BIG DRUM about it/write a beautiful Programmers Guide about it/write love songs in it, so that Linux sound applications everywhere can start getting things right now and not break/have to be ported again when libsydney comes along.

ALSA safe subset

Posted Jun 29, 2009 16:23 UTC (Mon) by pharm (guest, #22305) [Link]

Just in case this pops up in Google searches:

ALSA safe subset documentation, amongst other things:

http://0pointer.de/blog/projects/guide-to-sound-apis

LPC: Linux audio: it's a mess

Posted Sep 21, 2008 22:42 UTC (Sun) by mezcalero (subscriber, #45103) [Link]

OSS's general design (i.e. having device files as API for applications and stuff) is a big failure. I am pretty happy we are not stuck with OSS.

ALSA is great. It's API is complex, has issues, but still far better than OS. *far* better.

Lennart

LPC: Linux audio: it's a mess

Posted Sep 19, 2008 9:51 UTC (Fri) by NAR (subscriber, #1313) [Link] (22 responses)

I prefer having modern conveniences like USB hot-plugged audio hardware and Bluetooth headsets just working [...] PulseAudio just works (except for Flash).

How many people want to use USB hot-plugged audio hardware and bluetooth headsets? How many want to watch (and listen to!) Flash? I think there are a couple of order of magnitude difference between the two. If a project goes for the first class of users instead of the second, then it doesn't have place in the default installation of a general purpose distribution. Actually Ubuntu Hardy breaking Youtube with PulseAudio was the last bit of motivation for me to move back to Windows on my home desktop.

LPC: Linux audio: it's a mess

Posted Sep 19, 2008 12:35 UTC (Fri) by shalem (subscriber, #4062) [Link] (20 responses)

Really people,

You should refrain from making comments about something you've clearly not given a serious try. Yes flash does not work as is with pulseaudio because its a *closed source* app which is abusing the alsa interface in many horrible ways.

Not working as is does not mean that it does not work though, Lennart has gone to many troubles to make it work. So all you need todo (on Fedora, other distros will have something similar) is: "yum install libflashsupport" and after that flash will work fine with pulse. Since you are manually installing flash anyways, having to install an additional package which helps integrate flash better into the system (it does more then just get pulse to work with flash) is really not all that much to ask.

LPC: Linux audio: it's a mess

Posted Sep 19, 2008 13:04 UTC (Fri) by NAR (subscriber, #1313) [Link] (16 responses)

Actually I did install libflashsupport, but no luck.

LPC: Linux audio: it's a mess

Posted Sep 19, 2008 14:12 UTC (Fri) by drag (guest, #31333) [Link] (15 responses)

Don't blame Pulseaudio for Ubuntu's goof with it. I know people still had some issues, but with Fedora it really did work very much better then Ubuntu.

The PA in Hardy was, as far as I can tell, a victim of bad QA.

And Adobe Flash does crash out my browser quite often. Most of the time when I close out a window which I just watched a video, which follows that race condition described in the above article. This hasn't anything to do with PA, since you know, I am not actually running it.

I am sure you have other good reasons, but switching to Windows to fix Youtube is a bit drastic when it could of been solved by turning off PA or/and installing some other flash player. :)

LPC: Linux audio: it's a mess

Posted Sep 19, 2008 14:24 UTC (Fri) by NAR (subscriber, #1313) [Link] (11 responses)

Well, the youtube problem was just one too many. It used to work with Gutsy, didn't work with Hardy. Turning off pulseaudio didn't solved the problem and the audio wasn't in sync with other flash players.

Actually the browser window problem didn't affect me, because I use tabbed browsing, just one window which I don't close.

LPC: Linux audio: it's a mess

Posted Sep 19, 2008 14:47 UTC (Fri) by drag (guest, #31333) [Link] (9 responses)

I understand what your saying. It's too bad because more and more common to see experienced Linux users switching to Mac or Windows-based systems because they've just plain gotten tired of hacking around the same problems over and over and over and over again.

The Linux desktop experience is much more buggy and crash happy then Windows nowadays. People need to learn that having the source code is not a acceptable substitution for binary compatibility and good quality control mechanisms. It hurts open source software just as much as closed source stuff.

LPC: Linux audio: it's a mess

Posted Sep 19, 2008 18:06 UTC (Fri) by einstein (guest, #2052) [Link] (8 responses)

> The Linux desktop experience is much more buggy and crash happy then Windows nowadays.

LOL, I don't think so - although, who knows - I haven't run windows for some time, does it not crash anymore? Wow, that would be one for the books.

The linux desktop with pulseaudio has been working well for me (suse 11.0 at home, ubuntu hardy heron at work) but then again, perhaps my sound hardware is blase? (intel built-in) I do the usual, some web browsing, some gaming, some movies, some music. Other than a wrapper script that I needed for my 9 year old copy of quake 3 arena, everything just seems to work, out of the box.

Alternative for Adobe Flash users

Posted Sep 19, 2008 18:40 UTC (Fri) by dmarti (subscriber, #11625) [Link] (3 responses)

Don't know about anyone else but I have replaced Adobe Flash on my main laptop with Gnash. When I started running it this spring, it played YouTube usually, other Flash video sites almost never. Now YouTube always works and other Flash video sites work sometimes. Not ready for Grandma yet, but I'm not a big net video watcher and don't play Flash games much, so close enough for me.

Alternative for Adobe Flash users

Posted Sep 20, 2008 10:08 UTC (Sat) by DonDiego (guest, #24141) [Link]

What about Gnash's speed? Adobe Flash is already incredibly and annoyingly slow, will I have to invest in new hardware to run it? Yes, I still happily use a 500MHz PC...

Alternative for Adobe Flash users

Posted Sep 20, 2008 19:04 UTC (Sat) by jlokier (guest, #52227) [Link] (1 responses)

I ran Gnash on my Ubuntu Handy install for a few months - and it worked ok, and played Youtube videos for a while. But after a while it stopped playing Youtube and all other videos - it would just sit there with a spinner.

So I had to remove Gnash and replace it with the original Adobe Flash plugin.

(Unfortunately although there's a straightforward UI from Firefox asking which Flash plugin you'd like to install (I'd picked Gnash), there seemed to be no UI for removing or changing it.)

Disable Flash in the Browser

Posted Sep 25, 2008 13:12 UTC (Thu) by alex (subscriber, #1355) [Link]

Install both and then disable one with Tools/Add-ons/Plugins in Firefox 3?

LPC: Linux audio: it's a mess

Posted Sep 19, 2008 22:11 UTC (Fri) by nix (subscriber, #2304) [Link] (3 responses)

Windows never crash? Well, it doesn't bluescreen much anymore, but it's
still deadlock-prone, especially if it loses network connections.

e.g. the backup domain controller went down at work today (our desktops
are Windows XP *sigh*). Within seconds *everything* on *everyone's*
desktop had frozen. Even my VNC and X sessions were stalled. Most of the
mouse pointers had frozen (but not all), and ctrl-alt-del did nothing.
Even the primary domain controller froze. It all stayed stalled until both
the primary and backup domain controllers were simultaneously rebooted.

That's robustness for you. (If everything's frozen solid, it can't crash.)

The time was when heavily-interlinked NFS systems could do that in the
Unix world, but I haven't seen anything like it for many years, and even
at its worst Unix gave you more tools to diagnose it than roomfuls of
simultaneously-frozen boxes. In some ways Windows is going *backwards*,
even before you look at the Vista trainwreck.

It's not the only mess

Posted Sep 21, 2008 10:07 UTC (Sun) by man_ls (guest, #15091) [Link]

But still it is true that the Windows desktop has advanced a lot in that respect: my corporate w2k desktop has not frozen once in a year. Mac OS X has similarly become a lot more robust in the intervening years since I stopped using it. Meanwhile Linux (and its many variants) regularly breaks hardware compatibility, shows multiple regressions and makes you play with your kernel every once in a while.

Maybe I'm biased because I use only debian testing, and maybe Mandriva or Suse are better. And of course there are areas where it excels (such as performance and support for older hardware). But I'm not sure there aren't at least some engineering reasons for the lack of quality. Windows or Mac OS X have one wireless API well thought from the beginning, and most gadgets work fine with it (while Linux still struggles with common wireless chips). More to the point, they have not had two major rewrites of their sound systems in a few years (ALSA and PulseAudio).

Things should just work, and once they are working they should just keep working, without excuses.

LPC: Linux audio: it's a mess

Posted Sep 21, 2008 20:29 UTC (Sun) by NAR (subscriber, #1313) [Link] (1 responses)

The time was when heavily-interlinked NFS systems could do that in the Unix world

This is very much present tense at my workplace...

LPC: Linux audio: it's a mess

Posted Sep 21, 2008 23:57 UTC (Sun) by nix (subscriber, #2304) [Link]

'-o bg' solves most of that these days :)

LPC: Linux audio: it's a mess

Posted Sep 21, 2008 22:55 UTC (Sun) by mezcalero (subscriber, #45103) [Link]

The flash crash happens when you close a Flash animation (i.e. usually change/close a web site), not when you close a window.

LPC: Linux audio: it's a mess

Posted Sep 19, 2008 14:56 UTC (Fri) by ewan (guest, #5533) [Link] (2 responses)

And Adobe Flash does crash out my browser quite often.

As well as having a working libflashsupport Fedora also runs plugins inside nspluginwrapper, even on 32 bit installs. That means that flash runs isolated in its own process and doesn't take out your browser when it dies.

It is possible to get this right; if Ubuntu isn't doing it that's just an Ubuntu bug.

LPC: Linux audio: it's a mess

Posted Sep 19, 2008 15:02 UTC (Fri) by drag (guest, #31333) [Link] (1 responses)

Well this is Debian Lenny/Sid with epiphany-webkit.

Also the problem crops up in other applications that can support Mozilla plugins, like Liferea.

I will take a look at nspluginwrapper, though.

LPC: Linux audio: it's a mess

Posted Sep 20, 2008 6:35 UTC (Sat) by drag (guest, #31333) [Link]

Just for the record.

I installed and got PulseAudio working in Debian. And everybody above was right.. flash 9 doesn't work for shit. If I do the "export FLASH_FORCE_PULSEAUDIO=1" I can get it to sort of work for firefox, but not for anything else.

So I installed the Flash 10 beta and it seems to be much much better. Works happily with pulseaudio, but I had to disable framebuffer compression with the Intel driver stuff to get it to work without video corruption (of the flash video, not the display). This was in Debian Sid.

LPC: Linux audio: it's a mess

Posted Sep 21, 2008 22:53 UTC (Sun) by mezcalero (subscriber, #45103) [Link] (2 responses)

Actually libflashsupport does not fully fix the problems Flash9 has with PA.

The libflashsupport interfacing in Flash9 is racy. Thus you might get a freeze or crash in some cases when you close a web site in your browser. All people that had a look on this problem agree that we cannot really work around this in our code -- it is Adobe's job to fix this. And you know what? Adobe actually did so, in Flash 10.

So, in summary: Flash 9 on PA is not perfectly stable, regardless how you run it. But the people to blame for that are not us, it's Adobe. Please point your fingers in the right direction when you complain!

(Running Flash 9 in libflashsupport in a plugin wrapper is the best way to run Flash on PA right now. That way crashing flash will not bring your entire browser down -- and if you ask me, allowing closed source software to run inside the browser process is a bad idea anyway.)

Lennart

LPC: Linux audio: it's a mess

Posted Sep 22, 2008 7:41 UTC (Mon) by NAR (subscriber, #1313) [Link] (1 responses)

But the people to blame for that are not us, it's Adobe. Please point your fingers in the right direction when you complain!

From the developer's point of view, you're right. From the user's point of view, you're wrong. Youtube used to work with Ubuntu Gutsy (I don't know about your browser, but it doesn't crash mine), doesn't work anymore after the Hardy upgrade (which introduced PulseAudio), so it's obviously PulseAudio is the one that broke my user experience.

LPC: Linux audio: it's a mess

Posted Sep 22, 2008 8:16 UTC (Mon) by ceplm (subscriber, #41334) [Link]

No, it's Ubuntu which did not make sure, that flash works.

LPC: Linux audio: it's a mess

Posted Sep 21, 2008 22:46 UTC (Sun) by mezcalero (subscriber, #45103) [Link]

Priorizing support for broken closed-source software over a good, modern, well supported core sounds like a really really bad idea to me. If you really think that we should allow Adobe to take the Linux audio system hostage like this than please ... go away, use Windows.

Adobe's audio interfacing in Flash 9 was a big failure. But they fixed things in Flash 10 for us now. It's getting better.

Lennart

LPC: Linux audio: it's a mess

Posted Sep 19, 2008 15:03 UTC (Fri) by smorovic (guest, #52892) [Link] (7 responses)

ALSA isn't forcing anyone to move to a new API. The old OSS v3 emulation is in kernel for all the older apps.

For solving pulse (but also alsa) oss compatibility problems, I have high hopes on this project:
http://lwn.net/Articles/296389/

If it can provide near-100% emulation it would be a silver bullet for PA voes, because many Alsa apps also support OSS.

LPC: Linux audio: it's a mess

Posted Sep 20, 2008 13:16 UTC (Sat) by cortana (subscriber, #24596) [Link] (5 responses)

The problem with the alsa-provided /dev/dsp is that programs using it don't get software mixing. So such programs will block off all sound for all other programs on the system; or if sound is already playing, they will fail to play sound themselves.

LPC: Linux audio: it's a mess

Posted Sep 20, 2008 20:43 UTC (Sat) by adamgundy (subscriber, #5418) [Link] (4 responses)

the 'cuse' OSS emulation smorivic linked to is an attempt to fix that disastrous mess..

as you said, if you use ALSA's built in OSS emulation, that's a kernel module, and competes with any other ALSA source for the sound device. most newer sound devices (consumer, at least) only support a single playback channel, and expect software mixing to be done... but dmix (ALSA's mixer) is a userspace mixer using the ALSA drivers, which means the ALSA-OSS kernel module can't use it, hence blocking audio (it also means no mixing is available for OSS users, so only one at a time can use OSS)

CUSE is a way of providing /dev/dsp and friends for OSS emulation from userspace, so of course a userspace OSS emulator can use dmix, pulseaudio, or whatever and play nicely with other apps.

CUSE lets a userspace program catch the full range of operations on the /dev/dsp device, so it can be a full emulation, unlike tools like aoss which hack into glibc's open calls and try to detect opens of /dev/dsp and do the emulation there (they can't catch everything, so some stuff works with aoss, other stuff doesn't).

LPC: Linux audio: it's a mess

Posted Sep 21, 2008 8:27 UTC (Sun) by mlankhorst (subscriber, #52260) [Link] (2 responses)

Alsa already had oss support in the form of aoss, which hooks all ioctl's
and read/writes to /dev/dsp, so the only thing new is that this form uses
CUSE instead of hooking function calls with preloading.

LPC: Linux audio: it's a mess

Posted Sep 21, 2008 22:20 UTC (Sun) by adamgundy (subscriber, #5418) [Link]

the point is that aoss (and other variants) can't catch *everything* (mmap, etc), but I believe CUSE is intended to allow a user space process to catch all the same stuff as the kernel mode emulation can.

also, aoss is a pain for most users, because they have to start the program they want to 'emulate' under aoss, typically from a command line. CUSE just sits there as a daemon, waiting for any process to attempt to use /dev/dsp.

LPC: Linux audio: it's a mess

Posted Sep 21, 2008 23:03 UTC (Sun) by mezcalero (subscriber, #45103) [Link]

PA has "padsp" which is similar to "aoss".

However, this kind of virtualization is always imperfect, won't work for more complex applications that use mmap, or make assumptions about timing and hardware that a software sound server cannot meet.

Doing emulation with LD_PRELOAD is always hacky, incomplete, and can only be a temporary solution that only works in very specific cases.

Lennart

LPC: Linux audio: it's a mess

Posted Sep 21, 2008 23:07 UTC (Sun) by mezcalero (subscriber, #45103) [Link]

CUSE is certainly a good thing. But it won't solve our problems entirely. OSS allows clients to read the playback pointer of the hw which apps use for synchronization. Now, in sound servers (and even on stuff like USB) we have a hard time to support this, since we usually have an extra latency "behind" the playback buffer. So, either the timing the application gets will be way off what actually is true -- or we will have to minimize that aforementioned extra latency at the cost of high CPU load.

So again. Regardless which approach we use: 100% compat won't happen.

LD_PRELOAD is good for some things, CUSE for others. But in the end, 100% OSS compat that works for everyone and always will stay a dream.

OSS as and API needs to go away.

Lennart

LPC: Linux audio: it's a mess

Posted Sep 21, 2008 22:59 UTC (Sun) by mezcalero (subscriber, #45103) [Link]

We will never be able to provide 100% OSS compat in PA -- and not even 100% ALSA compat.

Also, note that the OSS compat ALSA in the kernel provides is far from perfect. Doesn't support userspace plugins -- it hence is incompatible with userspace plugins, such as dmix, and everything else.

Also, OSS as an API is broken in the timing model. The timing model is so broken that it desn't really work properly on USB audio.

Lennart

LPC: Linux audio: it's a mess

Posted Sep 21, 2008 22:35 UTC (Sun) by mezcalero (subscriber, #45103) [Link]

I want to make clear that I (as the PA guy) don't consider ALSA a "mistake". It's good stuff actually. Of course, it has issues -- as every system has. But considering all the options it's not really that bad at all.

People like to construct some kind of opposition between ALSA and PA. They fail to see the big picture. ALSA is a building block PA builds on. And that's good. The ALSA and the PA devs work together. We're not in competition. If you think we are, you don't know the details.

Lennart