| |||||||||||||
LPC: Linux audio: it's a messLPC: Linux audio: it's a messPosted Sep 18, 2008 23:36 UTC (Thu) by Richard_J_Neill (subscriber, #23093)Parent article: LPC: Linux audio: it's a mess
Why have so many distros forced PulseAudio on the end user? PA isn't a neat feature, it's a CPU-hogging(*), irrelevant bug - and it has been deployed before it is even properly working! We have Alsa with dmix now, and that should be enough to totally obsolete the concept of a "sound server".
With PA, my 1GHz Mini-itx box goes from being about able to play DVDs, to unable to work without chronic skipping. PA wastes 30% of the CPU, to achieve nothing!
I can see how network-transparent sound can sometimes be useful, as can the ability to multiplex soundcards together. But for the common case (of allowing multiple apps to be mixed in software so that all can share the soundcard, without blocking each other), plain ALSA/dmix is sufficient.
(Log in to post comments)
LPC: Linux audio: it's a mess Posted Sep 18, 2008 23:57 UTC (Thu) by nix (subscriber, #2304) [Link]
The 'PA chews CPU when doing nothing' bug (actually a feature implemented
in a CPU-chewy way) was fixed in PulseAudio 0.9.7, released nearly a year ago. Upgrade!
PulseAudio's degree of CPU-hogginess is customizable: see
alsa with dmix obsoletes the concept of a sound server iff you have only
LPC: Linux audio: it's a mess Posted Sep 19, 2008 9:37 UTC (Fri) by dgm (subscriber, #49227) [Link]
> alsa with dmix obsoletes the concept of a sound server iff you have only
> one machine or never ever want to produce sound on any other machine, and > have only one set of speakers, and don't care about per-application volume > restoration or compatibility with things like esd.
I think you just described 99.9% of desktop Linux users.
LPC: Linux audio: it's a mess Posted Sep 19, 2008 11:07 UTC (Fri) by nix (subscriber, #2304) [Link]
What? Most Linux users don't care about e.g. muting apps that make annoying sounds while music is playing, or pushing up the volume of important alerts so they're audible over whatever else is going on? Just because they can't *do* it doesn't mean they don't *care*.
LPC: Linux audio: it's a mess Posted Sep 22, 2008 21:49 UTC (Mon) by lysse (guest, #3190) [Link]
I don't care. Do I get to be a data point?
LPC: Linux audio: it's a mess Posted Sep 22, 2008 23:21 UTC (Mon) by nix (subscriber, #2304) [Link]
I'll add you to my extensive and elaborate statistical baseline (from
which data is extracted using gut feelings and rand()).
LPC: Linux audio: it's a mess Posted Dec 8, 2009 7:51 UTC (Tue) by jcm (subscriber, #18262) [Link]
Most desktop users (in my personal opinion) couldn't give a rat's ass about controlling the volume of individual apps or doing remote streaming. I can do both on this system and I have used them (on this system) precisely...never. It's just not even a big deal.
We now seem to be headed done some "let's all become Macs" road in which configuration is removed to benefit perceived needs of desktop users (mixer settings going away in rewrites when a simple "advanced mode" toggle would have sufficed) who aren't going to use the per-app. volume settings anyway.
I don't hate PA, I just find it gets in my way. Every time I upgrade my desktop or laptop, something audio breaks or changes behavior in an undesirable fashion.
Jon.
LPC: Linux audio: it's a mess Posted Sep 19, 2008 16:48 UTC (Fri) by iabervon (subscriber, #722) [Link]
I think users almost all want independent volume controls for different audio-producing applications; but I think this is something that users, in general, think is just something computers can't do. (In particular, they want to turn down the volume on applications that just "make sounds" and therefore don't bother to include a control and on applications that want to draw the user's attention unwillingly and turn their own volume up)
I also think most users would like to play their alert sounds out the laptop speakers despite having nice speakers plugged in, but assume that's impossible (and I think it is for a lot of hardware; there's only one DAC that gets switched).
LPC: Linux audio: it's a mess Posted Sep 22, 2008 8:05 UTC (Mon) by ceplm (guest, #41334) [Link]
I thought so too, but now I am switching between USB headphones and loudspeakers all the time. Thanks PA!
LPC: Linux audio: it's a mess Posted Sep 19, 2008 12:57 UTC (Fri) by zooko (subscriber, #2589) [Link]
> alsa with dmix obsoletes the concept of a sound server iff you have only
> one machine or never ever want to produce sound on any other machine, and > have only one set of speakers, and don't care about per-application volume > restoration or compatibility with things like esd.
Sounds good to me! Where do I sign up? Oh, it already works. :-)
LPC: Linux audio: it's a mess Posted Sep 19, 2008 17:38 UTC (Fri) by Richard_J_Neill (subscriber, #23093) [Link]
> The 'PA chews CPU when doing nothing' bug (actually a feature implemented
> in a CPU-chewy way) was fixed in PulseAudio 0.9.7, released nearly a year > ago.
When I said "Doing nothing", I do mean that I was playing a DVD at the time. PA was doing "nothing", in the sense of "adding no value", not in the sense of "being idle". I suspect you are right that killing off resampling would have solved the problem - but I didn't know that, and the default settings were wrong. It seems fundamentally daft to have a daemon handling sound at all.
> alsa with dmix obsoletes the concept of a sound server iff you have only
Actually, that's what drove me mad about PA. I already have a nice setup, with most sounds routed to the default onboard soundcard (/dev/dsp), which connects to the monitor speakers. One or two applications are permitted to use /dev/dsp1, which connects via a USB soundcard to a hi-fi. PA makes it extremely hard to choose specific devices at the application level. For example, I play the BBC's listen-again real-audio streams by using this shell-script:
CACHE=500
I'm sure there is a configuration GUI for this, but a few months ago, it just wasn't ready. PA may be a fine program, but it shouldn't be used by default till it has had some more testing, and polish.
BTW, if you want to play sound on a remote machine, ssh in, and use /usr/bin/play.
LPC: Linux audio: it's a mess Posted Sep 19, 2008 22:07 UTC (Fri) by nix (subscriber, #2304) [Link] It seems fundamentally daft to have a daemon handling sound at all.Then what do you suggest does mixing of stuff from multiple processes? You can't do it in the kernel, it's solid floating point at least (and more likely some flavour of SSE). You have to do it in some separate process. btw, dmix forks off a daemon. (Regarding the rest, maybe Lennart or someone can chip in: I use PA mostly for the network-transparency and volume-choice stuff and have only one sound card and set of speakers.)
LPC: Linux audio: it's a mess Posted Sep 21, 2008 21:05 UTC (Sun) by mezcalero (subscriber, #45103) [Link]
Please note that ALSA dmix doesn't actually fork a daemon off anymore. Since quite a while actually.
ALSA dmix is a pretty nifty piece of engineering. It allows multiple programs to write data to the audio device hardware buffer simultaneously in a very elegant way. However, this design nonetheless limits the possibilities of it quite a bit. For example, doing stuff such as "glitch-free" directly in dmix would be very difficult.
LPC: Linux audio: it's a mess Posted Sep 21, 2008 21:02 UTC (Sun) by mezcalero (subscriber, #45103) [Link]
In PulseAudio you can switch any playback stream on-the-fly to a differnt device. No command line interaction necessary.
Also, each sink/source in PA has a unique name. You can use it as device string from the command line if you wish.
Sure, adopting PA is a bit of a departure for a couple of old-style Unix philosophies (such as "everything is a file" -- which is a pretty stupid philosophy anyway). But complaining about that is not really a technical argument to me. If we want to have a good, modern sound system for Linux than leaving some Unix legacy behind is the right thing to do.
Lennart
LPC: Linux audio: it's a mess Posted Sep 22, 2008 0:03 UTC (Mon) by nix (subscriber, #2304) [Link]
'Everything is a file' is a really really really really killingly useful
philosophy: or, rather, 'everything you can usefully manipulate can produce an fd, and everything with a name is a file'. To see the problems when this is forgotten, consider the horror which is SysVIPC.
I'm not sure how to apply this to PA though. Maybe a FUSE module reifying
LPC: Linux audio: it's a mess Posted Sep 22, 2008 0:17 UTC (Mon) by mezcalero (subscriber, #45103) [Link]
"Everything is a file" is crack. It's an attempt of an abstraction that just doesn't work. A file has completely different semantics than sound device. Trying to cramp audio stuff into file-like semantics results in APIs such as OSS.
fds as a handle for resources are useful. But cramping everything into read()/write() style interfacing and access control via Unix permissions is just too simple, and incompatible with all the modern things we want to do with our desktop experience now.
Lennart
LPC: Linux audio: it's a mess Posted Sep 22, 2008 7:05 UTC (Mon) by nix (subscriber, #2304) [Link]
I don't seen any incompatibility. The thing behind the file need not be a
raw sound device: it can be another abstraction. OSS's interface sucks, but that was in large part because it relied on things like ioctl() and mmap() that just can't be usefully virtualized (as you know much better than me).
Just select() alone makes fds-for-everything a useful philosophy. I have
(FWIW, everything-is-a-file, the singly-rooted filesystem hierarchy, and
LPC: Linux audio: it's a mess Posted Sep 22, 2008 10:55 UTC (Mon) by mezcalero (subscriber, #45103) [Link]
So, you want to have an API that follows everything-is-a-file and then not use ioctl()s for configuration of the sound device? How else would you would like to see that happen?
ALSA internally doesn't even use read()/write() anymore. It uses ioctl()s everywhere as a generic function call multiplexer. That we have to do this is due to the everything-is-a-file philosophy and is basically just a hack: you lose type-safety and everything.
Unix access control is too simple: we want that access follows the user that is logged in on the local VT: when he logs out he needs to be removed from the access. Unix doesn't allow that, because if someone gained access he can keep things open as long as hew wants.
I know that e-i-a-f is one of the core fundamentals of Unix. But you know what? It's also one of the core weaknesses of Unix.
LPC: Linux audio: it's a mess Posted Sep 22, 2008 20:46 UTC (Mon) by nix (subscriber, #2304) [Link]
ioctl() is awful, everyone agrees. It's not virtualizable, it's not 32/64
compatible, it's not typesafe (as you said), it's thoroughly opaque...
The way to structure this is to put your controls in a directory, or a set
It's not even hard to make a system that works like this in userspace,
LPC: Linux audio: it's a mess Posted Sep 22, 2008 20:57 UTC (Mon) by nix (subscriber, #2304) [Link]
Note that I'm not saying OH NOEZ PA SUCKS COS EVERYTHING IS NOT A FILE or
even 'oh no you must rewrite PA so that everything is a file'.
I'm just wishing for an ideal world in which the Unix philosophy was still
LPC: Linux audio: it's a mess Posted Sep 23, 2008 9:09 UTC (Tue) by fergal (subscriber, #602) [Link]
Seems to me that everything is a file doesn't have to mean that everything is a single file. You don't have to represent your whole soundcard via a single file. Think of /proc or /sys.
The problem is it is quite difficult for a program to present itself as a coherent set of files. While it can easily enough produce a file-like interface, it cannot easily produce a directory-like interface.
LPC: Linux audio: it's a mess Posted Sep 19, 2008 0:25 UTC (Fri) by jwb (guest, #15467) [Link]
Er, absolutely not. PulseAudio allows me to mute my web browser while still listening to my music. dmix does not solve that problem.
LPC: Linux audio: it's a mess Posted Sep 19, 2008 10:43 UTC (Fri) by djpig (subscriber, #18768) [Link]
Which is a severe misfeature in web browsers (and/or the respective multimedia plugins) actually, and which really can and should be fixed independently from the underlying sound system.
LPC: Linux audio: it's a mess Posted Sep 19, 2008 11:38 UTC (Fri) by ewan (subscriber, #5533) [Link]
Hardly. It's (almost) always better to fix a problem once, centrally,
than have everyone re-invent their own particular wheel. Not least because it gives the user a single uniform interface for controlling things, rather than having to hunt through each individual app.
LPC: Linux audio: it's a mess Posted Sep 19, 2008 21:22 UTC (Fri) by rahvin (subscriber, #16953) [Link]
I understand your point, but as a user if I want to control a feature of an application I expect that control to be in the application, not some central sound daemon. I would think the default user behavior when looking to control the sound of an application would look first in that application not at some upper level. I agree with the poster you are responding to, the problem with browser sound is with the plugin/browser, not some central sound control. I can't tell you how often I right click on some flash application thinking there will be a volume control in the context menu. There should be a control in that context menu, that there isn't is a problem with the application.
LPC: Linux audio: it's a mess Posted Sep 20, 2008 3:41 UTC (Sat) by drag (subscriber, #31333) [Link]
Well it's confusing. I'll illustrate:
Say your using something like xmms or other application that has it's own volume control.
So you have the Gnome volume control stuff. It's the icon in your task bar and the mixer control stuff in your applications menu. This provides a 'sanatized' way to interact with volume controls. So you can have that nice little icon and the sound mixer buttons on your multimedia keyboard and whatnot.
Then you have the low-level Alsamixer interface. This reflects the actual hardware capabilities of your sound card. When your mucking around with the PCM slider your interacting with the sound card's hardware. It's confusing to use and each sound card has different capabilities so it's a UI that will change depending on what sound card you have.
Then you have your 3rd mixer interface at the application level.
Then on top of that people using desktops will have another volume control on their speakers. So that makes 4 different volume controls that interact with the sound card. Different applications will go through the Gnome stuff, interact with alsamixer directly, or have their own controls. Depending on how the application is configured it can interact with controls differently at different times. (ie, some apps can be configured to use OSS vs Alsa vs ESD vs artsd vs etc)
This is confusing.
Now say your trying to do a voice recording or interact with a VoIP application. Things get _very_ confusing.
With PA you have the master controls and the application controls in the same spot. Then that eliminates the requirements for mixing controls in your browser, file manager, your terminal's beeping, etc etc.
So this _should_ lower the mixing controls down to 2 on the software side. Alsa stuff should setup correctly, but it won't be for the significant number of people. So you still need alsamixer for getting the "baseline" set. But after that you should only need to deal with one interface.
It's still very goofy, but not as goofy.
LPC: Linux audio: it's a mess Posted Sep 22, 2008 2:11 UTC (Mon) by elanthis (guest, #6227) [Link]
Less controls is not the right solution.
Sometimes you want the same thing in multiple places to help usability.
However, PA is what makes that possible. Note that I said "the same thing"
LPC: Linux audio: it's a mess Posted Sep 22, 2008 16:55 UTC (Mon) by drag (subscriber, #31333) [Link]
> Sometimes you want the same thing in multiple places to help usability.
Not when those multiple things do very different and conflicting actions in very very non-obvious manners.
If you have:
Now you open up a youtube video. You get no audio.
Tell me, with certainty, which control, or combinations of controls, you will have to use to make the sound audible.
There is a difference between having 3-5 different places to control volume vs having 3-5 different controls you have to use.
LPC: Linux audio: it's a mess Posted Sep 20, 2008 11:27 UTC (Sat) by dirtyepic (subscriber, #30178) [Link]
Well, when I want to control the sounds coming out of my laptop, I would generally head to the place where the sound controls are, not in every application on the system that has any kind of capability of producing noise. Do you really think having dozens of apps, each with their own independent volume control, is a good idea? It's stuff like that, everyone going off and implementing their own incompatible audio systems, that helped get us into this mess in the first place.
LPC: Linux audio: it's a mess Posted Sep 21, 2008 22:10 UTC (Sun) by mezcalero (subscriber, #45103) [Link]
You're wrong.
One of the biggest problems in volume control we have right now is that we have too many volume controls in line. The app might have one, the device has a couple, the hardware might have even more. It is very confusing to the user to find his way through this jungle and figure out which one is the one that is responsible for the low volume of the output.
The fix for this is to coalesce all those volume controls at a single place which should naturally be the sound server. If applications then want to expose a volume control slider they should expose the one maintained by the sound server -- instead that everyone implements its own.
With the "flat volumes" feature of upcoming PA 0.9.13 we even will be able to coalesce per-stream and per-device volume into one.
In summary: requesting that each app should implement its own volume controls goes in the wrong direction. Bad idea. Right in contrary exporting vol control to the sound server is the right answer here.
LPC: Linux audio: it's a mess Posted Sep 21, 2008 23:23 UTC (Sun) by PaulWay (✭ supporter ✭, #45600) [Link]
I'd also add that it's trivially easy to posit an application which doesn't provide a volume control. Or an application which provides volume control, but hidden deep within labyrinthine controls - like MythTV or many games. Or an application which is normally quite acceptably loud most of the time but some times is too soft or loud - e.g. mplayer playing some video files, or in a situation where you want it playing in the background.
The real point here is that having every application (hopefully) implement a volume control (and hopefully do it well), and having it in a different location for each application, is a usability nightmare. Having one set of centralised controls smooths over a multitude of minor sins.
Have fun,
Paul
LPC: Linux audio: it's a mess Posted Sep 22, 2008 10:07 UTC (Mon) by hppnq (guest, #14462) [Link] It is very confusing to the user to find his way through this jungle and figure out which one is the one that is responsible for the low volume of the output. Considering that this argument is more or less the same as the one in favour of per-app volume controls, one would be inclined to think of a protocol as a solution for this kind of confusion. But it seems like this has already been patented. Sigh.
LPC: Linux audio: it's a mess Posted Sep 19, 2008 3:32 UTC (Fri) by elanthis (guest, #6227) [Link]
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 (subscriber, #31333) [Link]
> (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] 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]
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]
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] 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]
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]
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:
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] 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]
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]
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 (subscriber, #31333) [Link]
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]
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 (subscriber, #31333) [Link]
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 (subscriber, #2052) [Link]
> 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] 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 (subscriber, #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]
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]
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
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
It's not the only mess Posted Sep 21, 2008 10:07 UTC (Sun) by man_ls (subscriber, #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] The time was when heavily-interlinked NFS systems could do that in the Unix worldThis 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 (subscriber, #5533) [Link] 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 (subscriber, #31333) [Link]
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 (subscriber, #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]
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] 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 (guest, #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]
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:
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]
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]
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]
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
LPC: Linux audio: it's a mess Posted Sep 20, 2008 7:51 UTC (Sat) by jeremybar (subscriber, #49718) [Link]
I agree, I always disable the sound server and everything seems to start working :-)
LPC: Linux audio: it's a mess Posted Sep 21, 2008 20:55 UTC (Sun) by mezcalero (subscriber, #45103) [Link]
I think your view on what PA is is a bit too simple. It's actually a little bit more than just some code that mixes audio for you. It allows you to switch streams on-the-fly between devices, does upmixing/downmixing (stereo to surround and so on), allows you to combine multiple sound cards into one, allows you to have seperate volumes for all streams you play, and so on, and so on, and so on.
The most interesting feature in my personal opinion however is the new 'glitch-free' core as described on my blog a while back: http://0pointer.de/blog/projects/pulse-glitch-free.html -- this is of course not directly visible to the user, but nonetheless a major feature of PA that you really cannot do without on a modern operating system.
Also, please note that Takashi Iwai maintains PA in OpenSUSE. Takashi is one of the two lead figures of ALSA. I think this little fact should make clear to you that even the ALSA people themselves believe in a need for a userspace sound system that goes beyond what ALSA provides.
The misconception that PA is little more than a replacement for dmix is popular, but nonetheless a .. misconception.
If you have trouble with PA's CPU load then try a different resampler. ALSA's internal resampler is very very primitive and sounds terrible. It uses little CPU, but is one of the weaker points in ALSA. Claiming that PA is a regression over ALSA in this area is probably simply caused by setting different priorities.
Lennart
|
|||||||||||||