LPC: Linux audio: it's a mess
Audio is a fitting topic for the first day of the Linux Plumbers Conference. Users want sound to Just Work, and there's lots of working code in individual projects. But so far, it seems like nobody has everything quite plumbed together in an annoyance-free way.
Lennart
Poettering, a lead
developer of PulseAudio and Red Hat employee,
moderated the miniconference and started with a
summary of the state of Linux audio: "it's a mess
".
The audio miniconference came up with two steps
toward cleaning up the mess, though. First, come up
with a coherent story for application developers on
what sound API to use, and how. Second, clean up the
often-confusing array of user-visible audio level controls.
PulseAudio first appeared to regular users
in
Fedora, starting with version 8, and now,
as Lennart puts it, is for up-to-date users,
"the software that currently breaks your audio
".
PulseAudio is a sound server that mixes audio from
multiple applications and passes it along to the
sound hardware. It offers advanced features such
as network transparency: an application can play a
sound on a remote system, and PulseAudio makes it
come out the speakers on the remote machine where
the user is working. Supporting it shouldn't
be a big change for most application developers
to handle. It will handle applications written
to the kernel's maintained audio API, ALSA, using the
PulseAudio backend for alsa-lib. So the
PulseAudio transition has been relatively painless
for the distributions.
An earlier sound server project, the Enlightened
Sound Daemon (ESD) sound
server, is falling out of favor and Media
Application Server (MAS) has never really caught
on. However, one of the competing sound servers looks likely
to remain. On the pro audio side, the low-latency
sound server JACK
is the recommended option. JACK, the "Jack Audio
Connection Kit," as Dave Phillips writes, "holds
the keys to the kingdom" for connecting
studio applications such as the Ardour
digital audio workstation and the Rosegarden
MIDI sequencer. "If you want all of the features,
no one audio system supports all of them,
" Lennart
said.
Apple and Microsoft each have a single sound server that does both desktop and pro audio, but nobody at the session seemed to have much interest in that direction for Linux. PulseAudio is optimized for general desktop use and power savings, and supports scheduling features that should minimize wakeups but still allow for reasonably low-latency playback of streaming audio. It's also network-transparent and supports features such as placing desktop sound events based on mouse position. Network audio and desktop effects don't tempt pro audio users. JACK's uncompromising approach toward latency means it's likely to hog too much power to be acceptable to battery-life-watching desktop users, but fine for a studio with a rack full of gear. So two sound servers, one for pro and one for the masses, seems to be fine with both sets of users.
Abusing ALSA
PulseAudio, however, can't give applications direct
access to the hardware, and currently only about 70%
of ALSA applications use the API in a PulseAudio-safe
way, Lennart said. Some high-profile applications
are among those doing audio wrong. "Flash and
Skype are really really broken applications,
especially Flash
", he said. Adobe split out the
parts of its code that talk to the audio subsystem,
and certain other plumbing, into an open-source
library, libflashsupport. But Flash remains broken.
The proprietary Flash library talks to libflashsupport
from multiple threads, and one thread calls a
destructor while another continues to send data.
"
It works until you close the browser window and then
you get a race
", Lennart said.
Developers who want to play audio have a sometimes-confusing choice of tools, including PortAudio and GStreamer. (PortAudio is cross-platform, which is likely why the popular cross-platform audio editing application Audacity uses it.) GStreamer is relatively feature-intense and heavyweight, also handling video and transcoding. (Write a player with Gstreamer and you get the ability to play your collection of C64 SID files for free.)
[PULL QUOTE: If someone comes and says, 'I want to write an audio application. Which API should I use?' I don't have a good answer END QUOTE]"If someone comes and says, 'I want to
write an audio application. Which API should
I use?' I don't have a good answer
", Lennart
said. The current best answer seems to be to
write to the PulseAudio-safe subset of ALSA.
Jeff Licquia
of the Linux Standard Base (LSB), in the audience,
mentioned that ALSA is on track for inclusion
in LSB 4.0, and is a trial use module for 3.2.
LSB aims to define a compatibility standard for
Linux applications, and aims to do the kind of
application developer education that Linux audio
developers seem to need. Applications seeking LSB
certification must run all of the LSB tests, but can
fail anything tagged as trial use. "
We're only keeping
the stuff that we hope will be around for the long
term
", he said. If the LSB-safe subset of ALSA fits
into the PulseAudio-safe subset of ALSA, application
developers could write to ALSA and test with LSB.
"I would like to be able to tell people to use libsydney
",
Lennart said. Libsydney, in
progress, is intended to be a networking-friendly
general-purpose audio API.
ALSA and the HD-Audio widget problem
In ALSA, the hardware/software interface is in
good shape, but software to user interface needs some work. Takashi
Iwai, a core ALSA developer and Novell
employee, pointed out in a talk that the line
count for /sound code in the kernel is actually
shrinking, except for ASoC (system on a chip)
and HD-audio. "There will be no more sound cards,
especially PCI
", he said. The one exception is the
SoundBlaster X-FI for gamers, which is currently
not supported well in ALSA. Creative announced proprietary
drivers in 2006, but one ALSA developer recently
did get access to a data sheet under NDA.
The new audio standard, HD-Audio, is commonly found on new systems, and it's well-supported at the kernel level. However, it's based on "widgets" with vendor-configurable I/O pins. A driver can't tell how the HD-Audio part is connected, so some Linux plumbing work is required to identify which of the many exposed level controls is the right one to show the user. An audience member pointed out the need to tweak multiple level settings on his hardware, to get the right level without distortion. Linux will need more information on how each machine has its HD-Audio hardware hooked up in order to reliably give the user a useful volume control.
| Index entries for this article | |
|---|---|
| GuestArticles | Marti, Don |
| Conference | Linux Plumbers Conference/2008 |
Posted Sep 18, 2008 23:36 UTC (Thu)
by Richard_J_Neill (subscriber, #23093)
[Link] (76 responses)
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.
Posted Sep 18, 2008 23:57 UTC (Thu)
by nix (subscriber, #2304)
[Link] (19 responses)
PulseAudio's degree of CPU-hogginess is customizable: see
alsa with dmix obsoletes the concept of a sound server iff you have only
Posted Sep 19, 2008 9:37 UTC (Fri)
by dgm (subscriber, #49227)
[Link] (6 responses)
I think you just described 99.9% of desktop Linux users.
Posted Sep 19, 2008 11:07 UTC (Fri)
by nix (subscriber, #2304)
[Link] (3 responses)
Posted Sep 22, 2008 21:49 UTC (Mon)
by lysse (guest, #3190)
[Link] (1 responses)
Posted Sep 22, 2008 23:21 UTC (Mon)
by nix (subscriber, #2304)
[Link]
Posted Dec 8, 2009 7:51 UTC (Tue)
by jcm (subscriber, #18262)
[Link]
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.
Posted Sep 19, 2008 16:48 UTC (Fri)
by iabervon (subscriber, #722)
[Link]
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).
Posted Sep 22, 2008 8:05 UTC (Mon)
by ceplm (subscriber, #41334)
[Link]
Posted Sep 19, 2008 12:57 UTC (Fri)
by zooko (guest, #2589)
[Link]
Sounds good to me! Where do I sign up? Oh, it already works. :-)
Posted Sep 19, 2008 17:38 UTC (Fri)
by Richard_J_Neill (subscriber, #23093)
[Link] (10 responses)
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.
Posted Sep 19, 2008 22:07 UTC (Fri)
by nix (subscriber, #2304)
[Link] (1 responses)
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.)
Posted Sep 21, 2008 21:05 UTC (Sun)
by mezcalero (subscriber, #45103)
[Link]
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.
Posted Sep 21, 2008 21:02 UTC (Sun)
by mezcalero (subscriber, #45103)
[Link] (7 responses)
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
Posted Sep 22, 2008 0:03 UTC (Mon)
by nix (subscriber, #2304)
[Link] (6 responses)
I'm not sure how to apply this to PA though. Maybe a FUSE module reifying
Posted Sep 22, 2008 0:17 UTC (Mon)
by mezcalero (subscriber, #45103)
[Link] (5 responses)
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
Posted Sep 22, 2008 7:05 UTC (Mon)
by nix (subscriber, #2304)
[Link] (4 responses)
Just select() alone makes fds-for-everything a useful philosophy. I have
(FWIW, everything-is-a-file, the singly-rooted filesystem hierarchy, and
Posted Sep 22, 2008 10:55 UTC (Mon)
by mezcalero (subscriber, #45103)
[Link] (3 responses)
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.
Posted Sep 22, 2008 20:46 UTC (Mon)
by nix (subscriber, #2304)
[Link] (1 responses)
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,
Posted Sep 22, 2008 20:57 UTC (Mon)
by nix (subscriber, #2304)
[Link]
I'm just wishing for an ideal world in which the Unix philosophy was still
Posted Sep 23, 2008 9:09 UTC (Tue)
by fergal (guest, #602)
[Link]
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.
Posted Sep 19, 2008 0:25 UTC (Fri)
by jwb (guest, #15467)
[Link] (10 responses)
Posted Sep 19, 2008 10:43 UTC (Fri)
by djpig (guest, #18768)
[Link] (9 responses)
Posted Sep 19, 2008 11:38 UTC (Fri)
by ewan (guest, #5533)
[Link] (5 responses)
Posted Sep 19, 2008 21:22 UTC (Fri)
by rahvin (guest, #16953)
[Link] (4 responses)
Posted Sep 20, 2008 3:41 UTC (Sat)
by drag (guest, #31333)
[Link] (2 responses)
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.
Posted Sep 22, 2008 2:11 UTC (Mon)
by elanthis (guest, #6227)
[Link] (1 responses)
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"
Posted Sep 22, 2008 16:55 UTC (Mon)
by drag (guest, #31333)
[Link]
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.
Posted Sep 20, 2008 11:27 UTC (Sat)
by dirtyepic (guest, #30178)
[Link]
Posted Sep 21, 2008 22:10 UTC (Sun)
by mezcalero (subscriber, #45103)
[Link] (2 responses)
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.
Posted Sep 21, 2008 23:23 UTC (Sun)
by PaulWay (subscriber, #45600)
[Link]
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
Posted Sep 22, 2008 10:07 UTC (Mon)
by hppnq (guest, #14462)
[Link]
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.
Posted Sep 19, 2008 3:32 UTC (Fri)
by elanthis (guest, #6227)
[Link] (42 responses)
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.)
Posted Sep 19, 2008 4:16 UTC (Fri)
by drag (guest, #31333)
[Link] (9 responses)
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.
Posted Sep 19, 2008 18:51 UTC (Fri)
by dmarti (subscriber, #11625)
[Link] (7 responses)
Posted Sep 20, 2008 13:12 UTC (Sat)
by cortana (subscriber, #24596)
[Link] (6 responses)
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...
Posted Sep 21, 2008 3:43 UTC (Sun)
by dmarti (subscriber, #11625)
[Link]
Posted Sep 21, 2008 22:39 UTC (Sun)
by mezcalero (subscriber, #45103)
[Link] (4 responses)
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
Posted Sep 21, 2008 23:29 UTC (Sun)
by dmarti (subscriber, #11625)
[Link] (3 responses)
Posted Sep 22, 2008 0:21 UTC (Mon)
by mezcalero (subscriber, #45103)
[Link] (2 responses)
Lennart
Posted Sep 23, 2008 8:57 UTC (Tue)
by sdalley (subscriber, #18550)
[Link] (1 responses)
Posted Jun 29, 2009 16:23 UTC (Mon)
by pharm (guest, #22305)
[Link]
ALSA safe subset documentation, amongst other things:
http://0pointer.de/blog/projects/guide-to-sound-apis
Posted Sep 21, 2008 22:42 UTC (Sun)
by mezcalero (subscriber, #45103)
[Link]
ALSA is great. It's API is complex, has issues, but still far better than OS. *far* better.
Lennart
Posted Sep 19, 2008 9:51 UTC (Fri)
by NAR (subscriber, #1313)
[Link] (22 responses)
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.
Posted Sep 19, 2008 12:35 UTC (Fri)
by shalem (subscriber, #4062)
[Link] (20 responses)
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.
Posted Sep 19, 2008 13:04 UTC (Fri)
by NAR (subscriber, #1313)
[Link] (16 responses)
Posted Sep 19, 2008 14:12 UTC (Fri)
by drag (guest, #31333)
[Link] (15 responses)
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. :)
Posted Sep 19, 2008 14:24 UTC (Fri)
by NAR (subscriber, #1313)
[Link] (11 responses)
Actually the browser window problem didn't affect me, because I use tabbed browsing, just one window which I don't close.
Posted Sep 19, 2008 14:47 UTC (Fri)
by drag (guest, #31333)
[Link] (9 responses)
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.
Posted Sep 19, 2008 18:06 UTC (Fri)
by einstein (guest, #2052)
[Link] (8 responses)
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.
Posted Sep 19, 2008 18:40 UTC (Fri)
by dmarti (subscriber, #11625)
[Link] (3 responses)
Posted Sep 20, 2008 10:08 UTC (Sat)
by DonDiego (guest, #24141)
[Link]
Posted Sep 20, 2008 19:04 UTC (Sat)
by jlokier (guest, #52227)
[Link] (1 responses)
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.)
Posted Sep 25, 2008 13:12 UTC (Thu)
by alex (subscriber, #1355)
[Link]
Posted Sep 19, 2008 22:11 UTC (Fri)
by nix (subscriber, #2304)
[Link] (3 responses)
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
Posted Sep 21, 2008 10:07 UTC (Sun)
by man_ls (guest, #15091)
[Link]
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.
Posted Sep 21, 2008 20:29 UTC (Sun)
by NAR (subscriber, #1313)
[Link] (1 responses)
This is very much present tense at my workplace...
Posted Sep 21, 2008 23:57 UTC (Sun)
by nix (subscriber, #2304)
[Link]
Posted Sep 21, 2008 22:55 UTC (Sun)
by mezcalero (subscriber, #45103)
[Link]
Posted Sep 19, 2008 14:56 UTC (Fri)
by ewan (guest, #5533)
[Link] (2 responses)
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.
Posted Sep 19, 2008 15:02 UTC (Fri)
by drag (guest, #31333)
[Link] (1 responses)
Also the problem crops up in other applications that can support Mozilla plugins, like Liferea.
I will take a look at nspluginwrapper, though.
Posted Sep 20, 2008 6:35 UTC (Sat)
by drag (guest, #31333)
[Link]
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.
Posted Sep 21, 2008 22:53 UTC (Sun)
by mezcalero (subscriber, #45103)
[Link] (2 responses)
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
Posted Sep 22, 2008 7:41 UTC (Mon)
by NAR (subscriber, #1313)
[Link] (1 responses)
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.
Posted Sep 22, 2008 8:16 UTC (Mon)
by ceplm (subscriber, #41334)
[Link]
Posted Sep 21, 2008 22:46 UTC (Sun)
by mezcalero (subscriber, #45103)
[Link]
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
Posted Sep 19, 2008 15:03 UTC (Fri)
by smorovic (guest, #52892)
[Link] (7 responses)
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.
Posted Sep 20, 2008 13:16 UTC (Sat)
by cortana (subscriber, #24596)
[Link] (5 responses)
Posted Sep 20, 2008 20:43 UTC (Sat)
by adamgundy (subscriber, #5418)
[Link] (4 responses)
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).
Posted Sep 21, 2008 8:27 UTC (Sun)
by mlankhorst (subscriber, #52260)
[Link] (2 responses)
Posted Sep 21, 2008 22:20 UTC (Sun)
by adamgundy (subscriber, #5418)
[Link]
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.
Posted Sep 21, 2008 23:03 UTC (Sun)
by mezcalero (subscriber, #45103)
[Link]
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
Posted Sep 21, 2008 23:07 UTC (Sun)
by mezcalero (subscriber, #45103)
[Link]
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
Posted Sep 21, 2008 22:59 UTC (Sun)
by mezcalero (subscriber, #45103)
[Link]
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
Posted Sep 21, 2008 22:35 UTC (Sun)
by mezcalero (subscriber, #45103)
[Link]
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
Posted Sep 20, 2008 7:51 UTC (Sat)
by jeremybar (guest, #49718)
[Link]
Posted Sep 21, 2008 20:55 UTC (Sun)
by mezcalero (subscriber, #45103)
[Link]
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
Posted Sep 19, 2008 1:47 UTC (Fri)
by jmorris42 (guest, #2203)
[Link] (6 responses)
Wherein I joked about the next shiny thing attracting their attention. It was called FUD. Note how it isn't a year later and we read an announcement about yet another audio API for everyone to port to is the works. This is insane. Is it any wonder every application that uses audio does it through an abstraction layer?
Posted Sep 19, 2008 3:37 UTC (Fri)
by jmspeex (subscriber, #51639)
[Link] (5 responses)
Posted Sep 19, 2008 5:16 UTC (Fri)
by bronson (subscriber, #4806)
[Link] (4 responses)
Trying to find an answer, at the bottom of the libsydney link above triton asks, "As for the lib, wouldn't it be easier to fix PortAudio? Why reinvent yet another audio lib? NIH syndrome?"
Overall I'm really happy with Pulse but I'm very skeptical about libsydney... Does this world need yet another audio API for developers to choose from?
Posted Sep 20, 2008 0:14 UTC (Sat)
by jmspeex (subscriber, #51639)
[Link] (2 responses)
Posted Sep 20, 2008 20:42 UTC (Sat)
by salimma (subscriber, #34460)
[Link]
Posted Sep 21, 2008 23:20 UTC (Sun)
by mezcalero (subscriber, #45103)
[Link]
That is one of the more fundamental issues I don't think that PortAudio is the way to go. There are more. And it's a feeling shared by a couple of other audio related people.
Fixing the fact that we have to many competing audio APIs on Linux by adding another one is of course paradox. But still, after discussing this forth and back I believe this is the right way.
Lennart
Posted Sep 19, 2008 6:00 UTC (Fri)
by error27 (subscriber, #8346)
[Link] (1 responses)
Potentially doing OSS emulation in userspace will fix that?
http://lkml.org/lkml/2008/8/28/270
Also the article talks about all the volume knobs being a problem but did anyone come up with a solution? Probably Linux sound is way way too buggy to fix in a one hour session... :/
Posted Sep 23, 2008 6:09 UTC (Tue)
by angelortega (guest, #1306)
[Link]
Also, regarding libsydney, creating yet another wrapper library is not the
Posted Sep 19, 2008 6:50 UTC (Fri)
by aleXXX (subscriber, #2742)
[Link] (3 responses)
Alex
Posted Sep 19, 2008 7:04 UTC (Fri)
by Tuxie (guest, #47191)
[Link] (2 responses)
What I miss most with PulseAudio is AC3/DTS/AAC passthrough. I hope that will be implemented soon. It's not too uncommon to have the computer connected to a receiver via SPDIF nowadays, and having it go through the AC3 -> decode -> PA -> ALSA AC3-encoder -> receiver is a lot worse CPU wise than just AC3 -> receiver when the system is already struggling with being able to decode the 1080p video stream in realtime.
Posted Sep 19, 2008 9:50 UTC (Fri)
by Frej (guest, #4165)
[Link]
Posted Sep 21, 2008 23:23 UTC (Sun)
by mezcalero (subscriber, #45103)
[Link]
Lennart
Posted Sep 19, 2008 8:15 UTC (Fri)
by tialaramex (subscriber, #21167)
[Link] (3 responses)
Lennart should have concentrated on the part of the problem where he has relevant expertise, which is the network layer. If he'd built a fast and reliable framework for seamless network audio then people might entertain the idea that it's worth some disruption to get it onto everyone's desktops. But instead the argument seemed to be that Lennart would "fix" local audio (which was just coming together nicely with better ALSA drivers and dmix). He has comprehensively failed to do that.
Indeed Lennart has spent a LOT of time moaning at ALSA developers, often based on entirely false premises about how audio actually works on hardware people own, and he did not need to build yet another audio API to do that. If Red Hat had paid him to spend some time herding cats over at ALSA I'd be overjoyed, but instead this seems to have been merely a fortuitous side effect of the otherwise less than successful PulseAudio.
Posted Sep 21, 2008 23:40 UTC (Sun)
by mezcalero (subscriber, #45103)
[Link] (2 responses)
Also, what brings you to the conlusion that "Lennart has spent a LOT of time moaning at ALSA developers"? Sure, I have my issues with some parts in ALSA, and from time to time I let people know about them. But hey, nothing is perfect. Not ALSA. Not PA. In fact, I regularly defend ALSA -- far more often then criticising it. And I think I am pretty vocal about my support of ALSA. Just check the other comments I wrote to this article. ALSA is good stuff -- with some issues. More or less exactly like PA. Nothing is perfect -- and certainly software isn't either.
You are believing that ALSA and PA is in competition in some way. It is not. The ALSA devs and I work together. They already fixed quite a few of the issues I had with ALSA. That's collaboration. This is great, and I am happy. In fact at the conference this article was about Takashi and I met once again and we had very fruitful discussions.
You seam to be more of an ALSA fanatic that the ALSA guys themselves. Don't forget that Takashi even packages PA for OpenSUSE!
There is just no competition between ALSA and PA, since PA builds on ALSA. Everyone who thinks there was a competition is wrong, and doesn't get the big picture. Please get your facts right.
Lennart
Posted Sep 22, 2008 18:19 UTC (Mon)
by tialaramex (subscriber, #21167)
[Link] (1 responses)
ALSA isn't perfect, that's true, I have several enhancement bugs open and I've had discussions with ALSA people about various aspects -- notably I wanted a way to determine which ALSA level ("volume") control, if any, is the most appropriate to tweak for a PCM stream I have open, thus making it possible to make good use of a hardware PCM stream mixer as provided in say an SBLive. The kernel drivers are also not perfect, the driver for my Intel chipset can't properly handle a running audio output during suspend for example. But PulseAudio doesn't (and shouldn't try to) fix that problem.
I am a JACK user, so I am not, as you seem to assume, wedded to ALSA as the solution to all problems. I do think that you underestimated how mature PulseAudio needed to be before it was a better option than the default dmix configuration present in e.g. Fedora prior to PulseAudio. Not so long ago I encountered an old friend who happens to be a Google engineer (I say this only to establish that he's a smart get-things-done guy) who'd basically given up using audio on his laptop because he upgraded Fedora and that installed PulseAudio and broke the sound. PulseAudio's promise is good, but as of the last version I tried (was forced to try) it doesn't deliver that promise for a lot of people yet.
I remain to be convinced about PulseAudio. But don't imagine that I can't be convinced. I wasn't very impressed with early versions of NetworkManager either, but it got better. Probably I'd be less soured on PulseAudio if it had been in Fedora as an optional extra, to get feedback from people who know what they're getting into and perhaps have good use cases (e.g. hotplugging audio devices).
Posted Sep 23, 2008 13:42 UTC (Tue)
by mezcalero (subscriber, #45103)
[Link]
http://pulseaudio.org/wiki/AlsaIssues
Lennart
Posted Sep 19, 2008 8:28 UTC (Fri)
by jwoithe (subscriber, #10521)
[Link] (9 responses)
This is not strictly true for windoze as I pointed out during the discussion at LPC. While "desktop" audio applications make do with the standard windoze audio system, professional audio interfaces all ship with ASIO/ASIO2 drivers for a variety of reasons - not the least of which was the inability of the standard windoze audio system to provide low latency performance (in fact, over the years there have been other APIs besides ASIO). Vista may be different in this respect but it has other audio-related problems.
MacOSX has CoreAudio which, on the face of it, does integrate the consumer and pro requirements under one API. However, digging deeper one realises that it is probably closer to the pro side of the equation, with added features allowing seemingly easy access for consumers. At least at first glance CoreAudio is closer to JACK than ALSA/PulseAudio.
"... but nobody at the session seemed to have much interest in that direction for Linux"
It's not that we're not interested - the ideal solution is to have one sound system to rule them all. The problem is that the requirements of desktop users and pro audio users are much more divergent than many people realise. Getting a single audio system to satisfy all usage constraints while still performing efficiently is very difficult. As an example, desktop/laptop users are primarily interested in lowering power consumption, but doing this while maintaining a low latency audio system
The other issue is that JACK is much more than just a route to audio hardware. It implements extensive and flexible inter-application audio and midi routing - something PulseAudio doesn't do simply because it's not a feature required by desktop users. JACK also gives synchronous operation of all connected applications and provides sample-accurate synchronisation, but again these features are not required by the average desktop users. Oh yes, network audio *does* matter to pro audio users - and for that we have netjack.
What this boils down to is that JACK and PulseAudio are working in different problem spaces. They are optimised for different situations, and trying to make one also provide the functionality of the other will only result in a system with suboptimal performance.
Posted Sep 19, 2008 18:43 UTC (Fri)
by dmarti (subscriber, #11625)
[Link] (8 responses)
Posted Sep 19, 2008 21:43 UTC (Fri)
by jebba (guest, #4439)
[Link] (7 responses)
Yes. You can also do things like have a remote machine just do the LADSPA filtering to distribute the load, for example. It works and is solid. I've done similar things with pulseaudio and it felt like I had just duct taped a boat together. Jack rules.
Also, netjack2 is under development with the next generation of jack, which is based on jackdmp.
I wish the netgods would all settle on jackd and figure out how to solve its power consumption issues, if at all possible. Use the best! If some of the features are overkill for the desktop, just don't expose them in the simpler GUIs...
-Jeff
Posted Sep 20, 2008 7:24 UTC (Sat)
by jwoithe (subscriber, #10521)
[Link] (4 responses)
Although completely untested, I wonder if simply specifying a very large period size for JACK would go some way to addressing this. At least some of the reason for the high resource usage of JACK is that currently most of its users require low latency and so run with very small buffers. Desktop users don't require low latency, so running large buffers wouldn't matter there. Larger buffers mean fewer wakeups and thus lower power consumption.
JACK is certainly not a replacement for anything else at present, but I do wonder whether with some work it could be used as the basic building block for a universal audio system.
The other thing worth reiterating here is that JACK does much more than just provide access to audio hardware. It is also a signal router allowing audio to be routed arbitarily between applications as well as to/from a physical soundcard. This, along with its low latency performance, is what makes it extremely useful to pro audio and music production users.
Posted Sep 20, 2008 7:52 UTC (Sat)
by jebba (guest, #4439)
[Link] (2 responses)
As an example, I use it the base of http://freeeee.org a distro for eee pc.
Posted Sep 21, 2008 23:55 UTC (Sun)
by mezcalero (subscriber, #45103)
[Link] (1 responses)
Lennart
Posted Sep 23, 2008 0:46 UTC (Tue)
by jebba (guest, #4439)
[Link]
There are two FREEEEE modes[1]: full-on media and low power ebook.
With jack, multiple mplayers, freej, firefox, chat, xournal, an offline copy of wikipedia, an image viewer, wifi, camera, etc all running it runs hot, yes. :) But it also runs all that fine without dropouts or crashing. jack performs reliably *now* and is never the weak link. Occasionally I have used pulseaudio as a jack client, which is convenient, but it is no where near as reliable as jack.
jack is clean, "feels" like a nice unix utility (it does its "one thing" extremely well), and has a committed upstream community.
-Jeff
[1]Second mode yet to be completed :)
Posted Sep 21, 2008 23:54 UTC (Sun)
by mezcalero (subscriber, #45103)
[Link]
Allowing rewrite of audio buffers is what JACK doesn't do. And adding this makes things very complicated. I did it for PA, but I simply see no reason for JACK to do it as well. Also, since JACK allows much more complex routing than PA, the rewriting buffer issue becomes equally more complex. i.e. every part that becomes part of a JACK pipeline would need to be able to "rewind" its state. That means every JACK client application would have to be patched non-trivially.
Lennart
Posted Sep 21, 2008 23:48 UTC (Sun)
by mezcalero (subscriber, #45103)
[Link] (1 responses)
JACK is optimized for lowest latencies, CPU load comes second, and dynamic interruption-free changing of these parameters is not required. For PA however, we want dynamic latencies, generally low CPU load and the parameters need to be flexible.
But even if you would add "glitch-free" to JACK (which makes no real sense), it still is not designed for desktop use. PA carefully makes sure not to convert (or not even touch) audio data if not necessary. OTOH JACK only knows FLOAT samples, and thus audio type conversion is necessary usually at output and often enough on input too. That makes a lot sense for them. It's a very good choice, but it's not the right choice for the desktop.
The requirements of desktop/embedded use, and pro audio use are different. This results in different products. Trying to marry them is a great idea, but also very difficult to achieve. Of course, we should be trying to do this, but we have much bigger problems to fix before we start with that.
Lennart
Posted Sep 22, 2008 7:24 UTC (Mon)
by alankila (guest, #47141)
[Link]
The buffers passed between applications were still void * pointers and the only clue for their contents was a simple string describing what kind of format you had requested from JACK, a #define which expanded to a string such as "32-bit pcm floating point audio"...
Posted Sep 19, 2008 11:57 UTC (Fri)
by jengelh (guest, #33263)
[Link] (6 responses)
Posted Sep 21, 2008 23:58 UTC (Sun)
by mezcalero (subscriber, #45103)
[Link] (5 responses)
Lennart
Posted Sep 22, 2008 0:26 UTC (Mon)
by jengelh (guest, #33263)
[Link] (4 responses)
Posted Sep 22, 2008 1:03 UTC (Mon)
by mezcalero (subscriber, #45103)
[Link] (3 responses)
That's what libsydney is supposed to fix.
Posted Sep 22, 2008 2:26 UTC (Mon)
by elanthis (guest, #6227)
[Link] (1 responses)
Posted Sep 22, 2008 11:03 UTC (Mon)
by mezcalero (subscriber, #45103)
[Link]
The devil lies in the details. It's a lot of small issues that make compat difficult. In addition, some fundamental parts, like the reliance on the classic period-based playback model is a weakness that libsydney does not expose. Not exposing periods will greatly increase compat with glitch-free and with network setups. Finally, libsydney allows clients to set all kinds of properties for a stream that make it especially useful for desktop sound servers. (i.e. setting icons for a stream, and so on...)
But there are more things.
Lennart
Posted Sep 22, 2008 22:06 UTC (Mon)
by lysse (guest, #3190)
[Link]
Posted Sep 19, 2008 14:11 UTC (Fri)
by wingo (guest, #26929)
[Link]
It's not like Alsa is the bee's knees after all, it's fine as a hardware abstraction layer, but as an audio API it is unsatisfying. Better to write to a simpler API, like that offered by Jack or PA.
I also disagree with the suggestion that PA or GStreamer are equivalent choices for "[d]evelopers who want to play audio", as the otherwise-excellent author asserts. They are completely different and complimentary problem spaces, as anyone who has worked with either would realize.
Posted Sep 19, 2008 15:00 UTC (Fri)
by nim-nim (subscriber, #34454)
[Link] (8 responses)
Please don't conflate desktop with laptop like PA's authors like to do. There is a large proportion of desktop users that do not use laptops (and use wired audio peripherals you absolutely do not want to mute at every possible occasion like PA likes to do).
PA is laptop-oriented. Laptop does not equal desktop.
Posted Sep 19, 2008 18:33 UTC (Fri)
by dmarti (subscriber, #11625)
[Link] (6 responses)
Jim Gettys mentioned this project: AudioFile : a network-transparent system for distributed audio applications. It look as if PulseAudio is picking up on AF's buffering model.
Posted Sep 20, 2008 13:41 UTC (Sat)
by nim-nim (subscriber, #34454)
[Link] (5 responses)
Sure, and so are non-desktops. However making power and device hot-plugging core priorities, while at the same time dismissing multichannel sound and the ecosystem built around jack, show the "desktop" PA authors like to talk of is a laptop with simple stereo usb devices, with everything else retrofitted as an afterthought.
Posted Sep 22, 2008 0:01 UTC (Mon)
by mezcalero (subscriber, #45103)
[Link] (4 responses)
Also, I don't "dismiss" JACK and the community around it. It's great stuff. But solves a different problem as PA. That's all.
Posted Sep 23, 2008 5:04 UTC (Tue)
by foom (subscriber, #14868)
[Link] (3 responses)
Sure, but doesn't transparently support the most common source/sink of surround sound: AC3
If PA automatically supported AC3 encoding of surround sound to my SPDIF output, without
If PA could allow routing of AC3 audio through to the SPDIF port without the decoding/encoding
But, if it could do that, *and* transparently fall-over to doing a decode/mix/encode when it
Also, volume control is an interesting trick when not decoding the ac3 stream locally; I dunno
One can always dream...
Posted Sep 23, 2008 13:45 UTC (Tue)
by mezcalero (subscriber, #45103)
[Link] (2 responses)
However, please note that we will probably never support on-the-fly AC3 decoding or encoding due to patents.
Lennart
Posted Sep 23, 2008 14:52 UTC (Tue)
by foom (subscriber, #14868)
[Link] (1 responses)
Posted Sep 23, 2008 20:07 UTC (Tue)
by mezcalero (subscriber, #45103)
[Link]
Posted Sep 22, 2008 0:04 UTC (Mon)
by mezcalero (subscriber, #45103)
[Link]
Sure power saving is not as important for desktops as it is for laptops, but power saving is not all what PA is about. And power saving is good for desktops too .. and the environment. (and also for your power bill)
Lennart
Posted Sep 19, 2008 23:54 UTC (Fri)
by literfizzer (subscriber, #31274)
[Link] (9 responses)
All I want out of the sound system on my Linux box is to be able to reliably play sound with a minimum of overhead and fuss, without delays, skips, or sync problems. i don't want one or more competing userspace daemons making my life unnecessarily complicated. If some web page starts playing crud while I'm listening to music, I'll mute, pause or close it.
Posted Sep 20, 2008 10:20 UTC (Sat)
by DonDiego (guest, #24141)
[Link]
Posted Sep 20, 2008 12:49 UTC (Sat)
by nix (subscriber, #2304)
[Link]
Thankfully pulseaudio isn't a pile of crap like arts or esd and so doesn't
(Among other things PA runs at realtime priority so that it won't skip
Posted Sep 22, 2008 0:08 UTC (Mon)
by mezcalero (subscriber, #45103)
[Link]
You learned to accept that X11 runs in userspace. PA does for audio was X does for displays. So why is it so difficult to accept PA for audio too?
Also, MS is proud of Vista's userspace sound system. And Apple about CoreAudio. So, we now do something similar on Linux, for similar reasons. That's all.
Lennart
Posted Sep 22, 2008 2:47 UTC (Mon)
by elanthis (guest, #6227)
[Link] (2 responses)
You act as if audio on Linux was all peachy and perfect until PA came
It's a hell of a lot closer to being realized that acceptable graphics
You don't and won't get that without a solid mixing daemon. Keep in
Let me break this down for you. The software has bugs (that software being
Maybe PA got pushed into Fedora a little too early. I won't disagree with
Do NOT be stupid and think that "Fedora pushed it too early" is the same as
Posted Sep 22, 2008 5:29 UTC (Mon)
by bronson (subscriber, #4806)
[Link]
It's been said that both Fedora and Ubuntu pushed PA too early. I admit, given how bad Hardy has been, this is a compelling point of view. However, if the distros had not pushed early, the great number of audio bugs that have been fixed in the past six months would probably still exist. I bet the distros could wait 3 more years before pushing and it would still be a horrible experience. Software integration sucks, the only way to shake out the bugs is to integrate and see what breaks.
So, between Phonon and PulseAudio, hopefully audio will work decently in FC10 and Intrepid.
Posted Sep 22, 2008 7:10 UTC (Mon)
by nix (subscriber, #2304)
[Link]
I really must diagnose this, but trying to find bugs in ALSA's kernel
Posted Sep 22, 2008 22:12 UTC (Mon)
by lysse (guest, #3190)
[Link] (2 responses)
Posted Sep 22, 2008 23:22 UTC (Mon)
by nix (subscriber, #2304)
[Link] (1 responses)
Posted Sep 23, 2008 6:35 UTC (Tue)
by lysse (guest, #3190)
[Link]
Posted Sep 20, 2008 6:44 UTC (Sat)
by zlynx (guest, #2285)
[Link] (3 responses)
Posted Sep 20, 2008 11:29 UTC (Sat)
by Tuxie (guest, #47191)
[Link]
There could be a simple "audio calibration" program in the system settings though. Play a few pure sine waves of various frequences and let the user raise the volume until it starts to distort. Then for line-in/microphone they could experiment with different input volume levels. The values chosen would then be used as "100% volume" in the rest of the system.
Posted Sep 22, 2008 0:10 UTC (Mon)
by mezcalero (subscriber, #45103)
[Link] (1 responses)
Posted Sep 22, 2008 4:10 UTC (Mon)
by zlynx (guest, #2285)
[Link]
If you can get that then of course its a better idea.
Posted Sep 20, 2008 9:47 UTC (Sat)
by magnus (subscriber, #34778)
[Link] (3 responses)
The only way a standard application audio API could ever be created is if someone writes an abstraction layer that can talk to Alsa, OSS, Jack, PulseAudio, ESD, aRts, MAS, etc, with autodetection of which one to use and dlopen:ing all relevant libraries to avoid broken dependencies. This code should then be included in source form in every program that uses it, because making a shared library out of it would just make it just another API that needs to be supported.
Posted Sep 22, 2008 0:12 UTC (Mon)
by mezcalero (subscriber, #45103)
[Link] (2 responses)
Please note however that the audio/mm stack we are heading too is far less complex than you suggest. And the depth of the stack is not more than 3 (i.e. Gst on PA on ALSA at most)
Lennart
Posted Sep 22, 2008 13:23 UTC (Mon)
by nhippi (subscriber, #34640)
[Link] (1 responses)
Still, a good start would be a aggressive purge of legacy solutions - arts, esd, mas, various parts of libalsa.
Posted Sep 22, 2008 17:09 UTC (Mon)
by drag (guest, #31333)
[Link]
Plus it's possible to play regular applications through PA and into Jack, if you want to use a familiar application or media source.
> Still, a good start would be a aggressive purge of legacy solutions - arts, esd, mas, various parts of libalsa.
Ya. Unfortunately that requires rewriting applications that depend heavily on those API.
For very modern-style applications that use things like Phonon or Gstreamer, this shouldn't be a big problem since those things are designed to be modular. Arts is being taken care of through the KDE folks, who are forced to rewrite their applications to work with QT4 anyways. Mas isn't popular. PA is compatible with Esd.
Then there is OpenAL, SDL, and numerous other much more minor sound APIs.
Posted Sep 22, 2008 1:09 UTC (Mon)
by mezcalero (subscriber, #45103)
[Link]
Anyway, very informative article!
BTW: Adobe fixed the issues we pointed out to them in Flash 10. Flash 10 works fine with PA. Though it still sucks that Flash 10 is closed source and it takes so long to get things fixed due to that -- they do listen to us.
Lennart
Posted Sep 22, 2008 10:26 UTC (Mon)
by alankila (guest, #47141)
[Link]
With ALSA, you write this 100+ lines long method with about a dozen calls, each which can fail, some which are necessary before other calls in the sequence will work. It is strangely low level, maddeningly flexible, and poorly documented, so it's very difficult to know what you should do.
At least these questions may arise: What is the sufficient condition to get the output mode that is exact to the spec that you requested? Are there format conversions or resampling in the output path? If resampling, where do I set a reasonable algorithm, as pick-nearest or linear interpolation is not acceptable for audio work? What is the minimal program that produces output and yet has some specified latency? How do you write a working full duplex program?
Posted Sep 24, 2008 20:56 UTC (Wed)
by mezcalero (subscriber, #45103)
[Link]
http://0pointer.de/blog/projects/guide-to-sound-apis.html
Posted Sep 25, 2008 5:04 UTC (Thu)
by graydon (guest, #5009)
[Link]
For as long as I can remember, linux has over-engineered and under-delivered audio. It'd be a pleasant surprise to change that habit. But I'm not holding my breath.
Posted Oct 5, 2008 14:57 UTC (Sun)
by Joes (guest, #54524)
[Link] (1 responses)
A network capable sound daemon does not belong in the mass of machines that have sound cards. This just introduces bugs and eats memory and cpu.
A configured audio stations with Jack and ALSA outperform pulse in every instance.
Plus Low latency!
Every now and then a bad idea like this gets more marketing than engineering.
Now I understand why it was written.
And if you take offense that I'm bashing pulse programmers, well I now have to spend a half hour or more every time I install Fedora, SUSE, Mandriva or Ubuntu to get decent sound working. That wasn't the case before pulse got shoved into the distros prematurely.
Posted Oct 5, 2008 17:29 UTC (Sun)
by nix (subscriber, #2304)
[Link]
I don't even know what your criteria for measuring 'performance' are,
Personally I use Pulseaudio for one reason: *API compatibility*.
The rest of your post is sub-Slashdot ad hominems that aren't worth
LPC: Linux audio: it's a mess
LPC: Linux audio: it's a mess
in a CPU-chewy way) was fixed in PulseAudio 0.9.7, released nearly a year
ago. Upgrade!
`resample-method' in daemon.conf. This is prominently marked in the
documentation.
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. Some of us care about
that.
LPC: Linux audio: it's a mess
> 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.
LPC: Linux audio: it's a mess
LPC: Linux audio: it's a mess
LPC: Linux audio: it's a mess
which data is extracted using gut feelings and rand()).
LPC: Linux audio: it's a mess
LPC: Linux audio: it's a mess
LPC: Linux audio: it's a mess
LPC: Linux audio: it's a mess
> 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.
LPC: Linux audio: it's a mess
> in a CPU-chewy way) was fixed in PulseAudio 0.9.7, released nearly a year
> ago.
> 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. Some of us
> care about that.
DEVICE=/dev/dsp1
LOCATION=$(wget -O- $1 | tr -d '"') #An rtsp:// URL
mplayer -cache $CACHE -ao oss:$DEVICE "$LOCATION"
LPC: Linux audio: it's a mess
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.
LPC: Linux audio: it's a mess
LPC: Linux audio: it's a mess
LPC: Linux audio: it's a mess
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.
the sources and sinks...
LPC: Linux audio: it's a mess
LPC: Linux audio: it's a mess
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).
no *clue* why you imagine that 'modern things' require splintering a
single consistent interfaces into a mass of incompatible and
non-interoperable interfaces.
pipes were *the* key abstractions that Unix was designed around. Discard
them and you just don't have Unix anymore.)
LPC: Linux audio: it's a mess
LPC: Linux audio: it's a mess
compatible, it's not typesafe (as you said), it's thoroughly opaque...
of directories, one file per control, rather than using ioctl() on a
single file with different requests. The way you solve the 'remove this
user' is to create these directories on the fly, and zap their contents
when the user logs out: even if the user retains a handle to the
directory, it's empty now so they can do nothing with it. (You might need
a simple non-device revoke() to do this properly, such that all I/O to an
ex-session fd returns -EIO, but this has already been written: it just
hasn't been applied because it's difficult to make it work with things
like PTYs. For this application, we don't care about that at all). Plan 9
did all this two *decades* ago and got it right: why can't Linux do it
now?
thanks to FUSE.
LPC: Linux audio: it's a mess
even 'oh no you must rewrite PA so that everything is a file'.
as universally followed as it was in its early days, and musing about ways
to make that happen. I think a working revoke() is the biggest missing
piece (and libraries to make exposing one's configuration state as a FUSE
filesystem painless).
LPC: Linux audio: it's a mess
LPC: Linux audio: it's a mess
LPC: Linux audio: it's a mess
LPC: Linux audio: it's a mess
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
LPC: Linux audio: it's a mess
LPC: Linux audio: it's a mess
Where you might think to look first isn't where someone else might look
first. It's pretty clear that some people are going to try to adjust the
sound volume on the thing making the sound (the individual app) and not the
mixer control on the panel.
in multiple places. The volume widget in the app should modify the volume
of the PA stream, and be reflected in the desktop mixer utility, and vice
versa. Without things like PA, this becomes much harder. It's not even
possible without a lot of crap being shoved into the drivers.
LPC: Linux audio: it's a mess
1. Mozilla Browser volume control and mute.
2. Gnome Volume Control and mute (that ties into your volume icon and multimedia buttons)
4. Low-level Alsa volume control and mute.
5. Speaker volume control and power.
LPC: Linux audio: it's a mess
LPC: Linux audio: it's a mess
LPC: Linux audio: it's a mess
LPC: Linux audio: it's a mess
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.
LPC: Linux audio: it's a mess
LPC: Linux audio: it's a mess
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
LPC: Linux audio: it's a mess
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.
Yes
LPC: Linux audio: it's a mess
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
LSB
ALSA safe subset
ALSA safe subset
LPC: Linux audio: it's a mess
I prefer having modern conveniences like USB hot-plugged audio hardware and Bluetooth headsets just working [...] PulseAudio just works (except for Flash).
LPC: Linux audio: it's a mess
LPC: Linux audio: it's a mess
LPC: Linux audio: it's a mess
LPC: Linux audio: it's a mess
LPC: Linux audio: it's a mess
LPC: Linux audio: it's a mess
LPC: Linux audio: it's a mess
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
Alternative for Adobe Flash users
Alternative for Adobe Flash users
Disable Flash in the Browser
LPC: Linux audio: it's a mess
still deadlock-prone, especially if it loses network connections.
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.
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.
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.
It's not the only mess
The time was when heavily-interlinked NFS systems could do that in the
Unix world
LPC: Linux audio: it's a mess
LPC: Linux audio: it's a mess
LPC: Linux audio: it's a mess
And Adobe Flash does crash out my browser quite often.
LPC: Linux audio: it's a mess
LPC: Linux audio: it's a mess
LPC: Linux audio: it's a mess
LPC: Linux audio: it's a mess
But the people to blame for that are not us, it's Adobe. Please point your fingers in the right direction when you complain!
LPC: Linux audio: it's a mess
LPC: Linux audio: it's a mess
LPC: Linux audio: it's a mess
LPC: Linux audio: it's a mess
http://lwn.net/Articles/296389/
LPC: Linux audio: it's a mess
LPC: Linux audio: it's a mess
LPC: Linux audio: it's a mess
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
LPC: Linux audio: it's a mess
LPC: Linux audio: it's a mess
LPC: Linux audio: it's a mess
LPC: Linux audio: it's a mess
LPC: Linux audio: it's a mess
LPC: Linux audio: it's a mess
Last year when Pulse Audio went into Fedora 8 I posted this: http://lwn.net/Articles/256647/
Gotta say "I told ya so!"
Gotta say "I told ya so!"
Gotta say "I told ya so!"
Gotta say "I told ya so!"
Gotta say "I told ya so!"
Gotta say "I told ya so!"
LPC: Linux audio: it's a mess
LPC: Linux audio: it's a mess
use than the ALSA library mess.
solution. If you try to fix the problem of having 3 competing parts by
adding another one, you end up with 4 competing parts and no solution.
That's why we have Phonon in Qt/KDE
multimedia wrapper layer for Qt4/KDE4 apps, Phonon.
There is OSS, ALSA, GStreamer, libxine, MAS, NMM, JACK, now also
PulseAudio, and what is libsydney and portaudio ?
So instead to decide for any one of these now and then have to support it
for the years to come (no matter whether the actual developers are still
maintaining it or not), we created Phonon, which is *THE* portable
multimedia API (*NIX, OSX, Win) if you are writing a Qt4/KDE4
application.
That's why we have Phonon in Qt/KDE
That's why we have Phonon in Qt/KDE
That's why we have Phonon in Qt/KDE
LPC: Linux audio: it's a mess
LPC: Linux audio: it's a mess
LPC: Linux audio: it's a mess
LPC: Linux audio: it's a mess
LPC: Linux audio: it's a mess
is problematic.
Thanks for the corrections -- does netjack have a low enough latency to work for recording?
Thank you
Thank you
http://trac.jackaudio.org/wiki/WalkThrough/User/NetJack2
Thank you
Thank you
Thank you
Thank you
Thank you
Thank you
Thank you
LPC: Linux audio: it's a mess
LPC: Linux audio: it's a mess
LPC: Linux audio: it's a mess
`mplayer -ao help` gives an initial list: arts, esd, pulse, jack, openal. And ogg123 depends on libao. That already makes six!
LPC: Linux audio: it's a mess
LPC: Linux audio: it's a mess
doesn't? Is it just the portability issue, or is there something more?
LPC: Linux audio: it's a mess
LPC: Linux audio: it's a mess
pa is fine?
LPC: Linux audio: it's a mess
Non-laptop desktop machines are getting more power-aware, though, in order to get the "Energy Star" sticker needed to sell to government and big companies. So the nifty buffer-management features are going to be relevant to people who aren't on battery.
laptop and desktop
laptop and desktop
laptop and desktop
laptop and desktop
> from/to stereo for you.
DVD audio to AC3 over SPDIF output.
having to manually configure an external encoder program, that'd be good.
overhead and resultant quality degredation, that'd be great.
needs to mix another stream into the output (e.g. an alert sound or what have you), it would be
an absolutely amazing achievement: that's something that you just can't do today. And I'd really
like to be able to do that.
much about it, but I'm led to understand there's some metadata in the frames which can be set to
affect the volume on the decoder. Maybe (hand-wave) that could be modified in-flight without
re-encoding the stream. :) If PA could do that, that'd be even another advantage over the
existing ALSA solution.
laptop and desktop
Sad to hear that about the patents...but is there really any issue with using an AC3 encoder/decoder
library if the user happens to have one installed already? (maybe they've already paid the licensing
fee to Dolby, e.g. through buying a Dell with Ubuntu
preinstalled).
laptop and desktop
laptop and desktop
LPC: Linux audio: it's a mess
+1 for no userspace daemon
+1 for no userspace daemon
+1 for no userspace daemon
encountered with those. It was more 'no sound at all because it
spontaneously crashed' for arts, and 'no sound at all because of a
ludicrous and dysfunctional nonauthentication system' for esd.
have any of those problems that I can see. :)
just because of CPU load: if you're swapping so hard that its being
swapped out is problematic, I doubt that whatever was playing the music is
going to be in memory much longer either.)
+1 for no userspace daemon
clue, meet literfizzer
priority and want glitch-free playback... so you want to go back to a bunch
of applications doing piss-poor direct access to ALSA and/or using the
crappy low-quality dmix mixer that can pretty easily introduce stuttering
and glitches under even remotely heavy load.
along. That's bullshit. It's been horrendous and barely usable all along.
It worked in some situations with moderate quality if you were lucky and
had the right drivers and only used the right applications. PA glitch-free
playback combined with quality mixing offers to finally make audio bearable
for the first time for _everyone_. Once the bugs are worked out of the
audio drivers, applications, and PA itself.
driver or wireless behavior on Linux, I'll tell you that much. In 10 years
of using Linux on mainstream hardware I've yet to have a video card that
works worth a crap without binary blobs, and this laptop here is the first
one I've ever been able to get wireless to work... and it requires hoops to
be jumped through (Broadcom). The problems people are having with audio
are _nothing_ in comparison, but I don't see you bitching about the
constant work being put into X/DRI or the wireless drivers and telling the
devs that they should switch back to the old way (what, plain VESA?
nothing?) because the new stuff is still buggy and incomplete (I don't even
want to get into how much time I spend trying to get video to work on both
old and new video cards -- and sometimes monitors -- compared to audio).
mind that kernel-space can't do floating point math and that reality is not
so great for the quality and performance of sound remixing and resampling.
PA, the ALSA drivers, and your user-space applications -- all of them, not
just PA), you have hit the bugs, and you're just short-fused enough to
think that said bugs invalidate the entire model. Wise people instead just
think that the bugs need to be fixed so we can solve the problems that the
old model has already proven incapable of solving.
that. I had a lot of pain with Fedora 8, too.
"the whole model is broken."
+1 for that rant
clue, meet literfizzer
ALSA (*waves*) or refuses to use the high-def timers that definitely exist
(*waves*).
component is like trying to shovel sewage with a toothbrush. Its
kernel/user interfaces are horrible (and most of both components is
entirely undocumented as far as I can tell: I still have no clue what the
Lisp interpreter is doing in there, for instance. Maybe the docs are just
hiding. Maybe they appeared since the last time I looked at this a couple
of months ago. But, y'know, life's too short: PA mostly works for me now,
and hardly ever glitches even with glitch-free mostly turned off by the
enforced usage of the OSS compatibility layer.)
+1 for no userspace daemon
+1 for no userspace daemon
which is a source of data and one a sink, or as a single file which you
can read() responses from as you write() stuff to it. Anything you can do
with a TCP/IP socket you can do with a suitably backed file, and we know
very well that you can define protocols over network sockets :)
+1 for no userspace daemon
LPC: Linux audio: it's a mess
LPC: Linux audio: it's a mess
LPC: Linux audio: it's a mess
LPC: Linux audio: it's a mess
LPC: Linux audio: it's a mess
LPC: Linux audio: it's a mess
LPC: Linux audio: it's a mess
LPC: Linux audio: it's a mess
LPC: Linux audio: it's a mess
LPC: Linux audio: it's a mess
LPC: Linux audio: it's a mess
LPC: Linux audio: it's a mess
LPC: Linux audio: it's a mess
Separate volume controls
No glitches in sound
Multiple apps recording and playing simultaneously
Just look at mono. hmmm...
Mono gets you a job with microsoft.
Pulse gets you a job with redhat.
Pulse programmers may be skilled but there's been many a skilled programmer that has written "great" code that causes more problems that it solves and like mono, encourages others to go down a bad path.
LPC: Linux audio: it's a mess
bashing on content-free innuendo. *Why* doesn't network-capability belong
in 'the mass of machines'? Why does the pulseaudio native network protocol
*plugin* 'introduce[] bugs and eat[] memory and cpu'? Got any evidence? I
doubt it, because there is none. (I mean, yes, obviously deserializing
data flowing over the network costs a bit of CPU time, but it's utterly
insignificant, and you don't even pay that cost unless you're doing
network streaming.)
given that your examples are matched by pulseaudio (given hardware that
supports hi-res timers, at least).
Pulseaudio can emulate virtually everything (other than Jack) so I don't
need to run a mass of battling incompatible sound daemons anymore: I can
just run one. (And yes, it *can* mix stuff from multiple sources and sinks
freely.)
responding to.