Slashdot Mirror
PulseAudio Creator Responds To Critics
Dan Jones writes "As recently discussed here, Linux sound development has come under fire for being overly complex and, more specifically, PulseAudio has been criticized for not being a 'good idea.' In a lengthy interview, PulseAudio creator Lennart Poettering has responded to the many critics of the new-generation sound server and says such complaints and criticisms about PulseAudio in some Internet forums are not really shared by the vast majority of technical people. While Poettering admits PulseAudio itself is not bug-free, he believes the majority of issues are being triggered by misbehaving drivers or applications."
When an application can make the soundsystem stop working for all other applications, than there is a bug in the soundsystem, not just the application that caused the problem.
------ Take away the right to say fuck and you take away the right to say fuck the government.
The idea is great. PulseAudio is an excellent solution for networked audio and thin unix clients. Now the problem is the people and the distros installing it by default on a desktop where it is utterly useless. No matter how close to bug-free it is, it is an unneeded source of bugs in that case.
This is not entirely true.
Now, I don't know what the exact bugs are that are causing problems. But the API should be stable no matter what happens to the outside. There should be no way to destabilize or crash the audio layer from a usermode application. So, if by "expect more correct behavior from the apps" he means "garbage in, garbage out", then that's fine. But if by "expect more correct behavior from the apps" he means "no error checking and if any app screws up then everything melts", then that's not fine.
I don't know which he means, but I've seen instances of both.
Breaking Into the Industry - A development log about starting a game studio.
The problem is that the implementation sucks, and that bugs are being ignored.
I'll perhaps reconsider my stance when pulseaudio starts using less CPU than the JVM when playing Puzzle Pirates. Finally something more bloated than Java, I guess.
Finally! A year of moderation! Ready for 2019?
While Poettering admits PulseAudio itself is not bug-free, he believes the majority of issues are being triggered by misbehaving drivers or applications.
Well, the way I see it, I can either use alsa and have (as far as I can tell) no bugs, or I can use PulseAudio and have more features and more bugs.
That might not be PulseAudio's fault, but it still means that if I use PulseAudio I will have a buggy sound system. Why do I want that? Why do I want it even if it's only buggy until all the applications get fixed?
Also, the promise of networked sound is kinda... meh... maybe I'd be happy if all my laptop sound got moved to my desktop box (which is connected to my stereo) automatically whenever my laptop is connected to my home access point (and, conversely, my desktop's sound automatically gets routed to my laptop whenever my laptop does an ssh home and is not around my home access point). But as far as I can tell, this is a bitch to set up, and I'm really not inclined to go clicking around some unintuitive menu system to set my sound up right every time I leave home or go back.
So what's the benefit of PulseAudio again?
The largest problem with Linux audio is not really any particular driver model / sound server. OSS, ALSA, PulseAudio and Jack all work when set up properly, with supporting hardware, and supporting software. But it's never a given that a particular app will support whatever you're using, or give you the choice to select your output device if you have multiple sound cards.
I've been running Ubuntu for a long time now, and recently installed Windows as a dual boot for making music. Why? I can spend X hours on setting stuff up, or I can spend X hours on making music. I can simply count on any app that matters supporting ASIO or DirectSound on Windows.
While I actively try to convert people to Ubuntu for regular desktop apps I still tell people who plan to do audio/video stuff to go for Windows/OS X. While it's totally doable to set up a working environment in Linux if you know what you want and which apps you want, I like to play with stuff for fun. I'd rather invest my time in having fun creating content than trying to get stuff to work.
(And yes, I've tried Ubuntu Studio. Nice, but not there yet for me.)
.: Max Romantschuk
If you disagree with this guy, you're OBVIOSULY not "technical" and CERTAINLY not part of this mythical "vast majority".
Look, if you have a nice idea and it involves stacks and stacks of layers and drivers and the whole introduces a nice fat latency by design, and that nice idea pertains to something potentially very latency sensitive such as the audio to VoIP, then perhaps the nice idea wasn't so nice after all. And then there's the rest of the complaints.
I think "vast majority of technical people" is poetteringspeak for "yes men". Either that or he can show us wrong by patching all those drivers that he's pointing to. No, merely pointing elsewhere is not enough. Show us the code.
The 4Front interpretation of GPLv2 is irrelevant - the source code is triple-licensed under GPLv2, CDDL and BSD licenses. ALSA is an excellent example of Linux throwing away a solid API and implementation that could have evolved to support the few critical features it lacked (which is exactly what happened in FreeBSD for example) in favour of a half-baked alternative. The original ALSA API is poorly designed by people who clearly have very limited knowledge of OO principles, but wanted to apply them all the same. This piss poor API was never well documented, and the actual audio drivers are not of the same quality as the ones in OSSv4. The ALSA developers answer to the poor API? Slap another, equally poor, equally undocumented API on top of it. What a fucking mess.
Even if he may be 100% right about that: way not to get the point!
I don't care whether problems are caused by the kernel, a driver, an application, the phase of the moon, or whatever. The thing is, if some "trivial" piece of hardware which has been part of mostly every computer since about 1990, still *does not fucking work* correctly today, I don't give a rat's ass whose fault that is. Especially if it appears the same "problems" have been solved satisfactorily at least 10 years ago on every other OS in mainstream use.
In the meantime, Linux has changed both the audio driver model (ALSA, OSS, who knows what else), and in addition to that, the "application interfaces" (arts, esd, PulseAudio, etc.) so frequently, that it is hardly any wonder that application developers are taking the piss and not updating their software to match the bugs/workarounds to whatever the current "flavor of the week" API for audio interfacing is.
Perhaps PulseAudio is just getting most of the "blame" because it is the most recently changed part of the audio subsystem, so if things used to work before, and now they don't, of course you're going to blame PulseAudio. Even if it is not by itself the "real" culprit.
Every expression is true, for a given value of 'true'
the *true* way-to-go is to use a real-time kernel... that's the only way which will free us of those irritating hick-ups in the sound pipeline. perhaps even audiophiles will be able to use it then.
Do more than .0001% of linux users need autoforwarding, or network transparency at all? Or should we focus on what the other 99.9999% want, which is high performance, low latency, non-crashing sound like the other two major OSs have.
I never thought I'd see a Linux advocate use the Vista Defense! It's the drivers, it's the software, it's something, but it's not my code!
At least with Vista the problems with video drivers, and various other hardware devices was sorted out within a couple of months. In Linux the way audio is handled is an absolute mess.
The sound on my =bare metal= install of Fedora 10 didn't work.
After much forum-searching, config tweaking, and pounding-of-keyboard, I eliminated PulseAudio.
The sound worked.
Tell me again about PA's awesomeness.
It's not just for Windows anymore!
Comment removed based on user account deletion
The funny part is that if you have what the 99.9..% want, accessed through a reasonably thin shared library, it becomes pretty easy to forward it over a network. You end up with higher latency, but PA certainly seems to be putting the cart before the horse.
I'm an OSSv4 converted too - being being unable to get vmix or Pulse to work right, Alsa could turn the volume as high as Windows. Now in OSSv4 everything works fine, except being unable to detect the jack, which is annoying.
Dilbert RSS feed
"The kernel has exception handling tables. This is used for a variety of things, primarily access to user space memory. My day is not ruined."
The current treatment of FPU exceptions is 'panic'. Go on, try to persuade kernel people to change it.
"No. Look, I could eliminate userspace entirely if I wanted to. (it's just a trivial change to not exec init) I can throw pretty much anything into the kernel. The kernel rules all."
Go on. Try to read config files from the kernel space, for example. Let's see how far you'll fly when Linus Torvalds kicks you.
"Um??? They sure are, and I'm not limited to threads. I can use tasklets, softirqs, regular old interrupt handlers, or my own evil invention. I can even disable interrupts if I please."
And I can set realtime priority for a thread, which in practice is more than enough.
"I didn't suggest it required the X server. I said it was the same sort of thing. It's a userspace program that is unable to create hooks for SE Linux policy or get capability bit allocations. Sure, I can use SE Linux as a big hammer, but I can't ask SE Linux to control the internals of non-kernel code."
Uhm. But it can. You can't use capability bits, but nobody uses them anyway. Besides, PulseAudio can use _userspace_ authorization system (DBUS + rtkit) which is right now much more usable than anything SELinux people can come up with.
A lot of devices stream data over a network and play it locally as audio. That does not necessarily make any of them a "network based" audio device in the sense that they can be driven by PA.
Audio is not unique in needing device ACLs adjusted; it should not need a unique solution for doing that. In fact, having an audio server handle ACL adjustments when something else does that is a violation of the Unix philosophy of chaining together simple tools that focus on one thing.
Application-controlled latency is good. Library-enforced latency is bad. Sending audio from one user-space process to another is a case of the latter.
After reading your post made "as a PA developer", I'm even more down on it than before.
PulseAudio isn't written for the hardware of 10 years ago. It is written for 2009 where a typical user has multiple independent pieces of hardware each capable of sound input and/or output that may or may not be present all the time (webcams, headsets, bluetooth, etc.)
There was some article on /. only a couple of weeks back about how communication is important in the real world and the general tone of many replies was "No it isn't".
The fun bit is (and I'm sure it was unintentional), you've just proven the point beautifully. For example:
The GNOME developers in particular have been told on numerous occasions what an abomination their baby is, yet they continue to insist on defending it,
If the criticism is being levelled in those terms (and my own experience suggests it probably is), I'm not surprised. How many times in the whole of history has criticism in those sort of terms ever resulted in the person you're criticising looking back over their work and saying "You know what? You're right."? This is basic animal instinct - the natural response to an attack is defence. It sure as hell isn't a natural response to consider the attackers' perspective and think maybe they have a point.
Mark Shuttleworth shaped Ubuntu up to be the ONLY decent desktop linux distro
Flamewar starting in 3....2....1....
SSC
I believe the solution to any *PROFESSIONAL* Linux Audio Production issue is to just go buy a Mac.
Technology -- No Place For Wimps! Grateful Dead and Jerry Garcia Chatroom -- http://www.wemissjerry.org
latency sucks... If I play a note on my guitar or keyboard, then I do not want to hear the sound more than a couple of milliseconds late... this is precisely why I still do my music recording on a windows box... I still can't get rid of it much as I really want to... I did have a perfectly good Ubuntu Studio setup going back on the LTS (Dapper Drake) before the current one, but certain issues pushed me into upgrading to the next LTS (Hardy Heron) and boom... pulseaudio screwed it all up... I was completely dumbfounded when I discovered it was an experimental sound system just dumped into the LTS without any attempt to get the default settings correct. I expect the LTS version of Ubuntu to actually work out of the box. So as a result, I got my XP box out of mothballs and went back to using XP for recording.
Donald 'Duck' Dunn: We had a band powerful enough to turn goat piss into gasoline.
You're confusing synchronization and latency. There's no particular reason you can't buffer up a few seconds of audio, yet make sure that audio is played exactly when the video calls for it.
I'm afraid you haven't yet distinguished between OSS3 and OSS4. Have you TRIED IT? If not - stop your belly aching. If you have tried it, then put some comments on the OSS4 contributor's site. Since I'm not a developer, telling me how bad it is accomplishes nothing.
Once again, OSS4 solves all of my problems. Sound just works for me, without a hitch.
"Windows is like the faint smell of piss in a subway: it's there, and there's nothing you can do about it." - Charlie Br
The point of my first sentence is that it's stupid to point at the PS3 or Airport Express and say "that's like PA's network support!" because they work quite differently. They send almost arbitrary audio files over the network; PA sends audio bit streams.
The point about ACLs is precisely that it should be centrally managed. If PulseAudio is applying its own policies independent of the other ACLs that get adjusted when I start a session, it's wrong.
So you have a buzzword compliant core. Are there any copies from application buffers to device buffers, or vice versa? How does it select output block sizes, for the kind of low-latency things that advocate_one is talking about? How does PA handle output stream mixing between applications? (Maybe it doesn't -- MPlayer on my machine is unable to open the audio device if I have a browser open that ever looked at a YouTube video. If it worked, that's a feature I would use a lot more than dynamically switching an audio stream between devices. It worked fine under ALSA.)
I've had three systems with audio problems. Two Ubuntu-based (8.04, 9.04), a third OpenSuSE-based. All with PulseAudio. All had oddities- ranging from the sound working only during X session startup/shutdown (and not in-between), through to the audio skipping, repeatedly, when changing the current desktop. These were on reasonably decent machines, by the way. Machines that should gobble up and spit this data so fast that it barely dents CPU usage.
In each case, disabling PulseAudio and using, well, anything else, caused the problem to go away. OSS, ALSA, didn't matter, they both worked. Sometimes it was easy to remove PulseAudio, and sometimes it took a bit of work. Ubuntu 9.04 was a challenge. No, scratch that, it was a fight.
I look around, I see horror stories and widespread problems with PulseAudio.
I see claims that it works, if you configure it "properly". You know, I heard the same vague defence regarding Windows' instability. I didn't believe it for Windows either.
I've heard that PulseAudio has a great set of features. However, I have no interest in digging into what these features might be. The core feature that I want above all else isn't supported by PulseAudio. That feature?
Playing seamless audio.
PulseAudio can't even get that right. Stutters and skips are the norm, audio systems that worked previously no longer do, and the backers of this abomination are in abject denial about it. There are widespread complaints about it across multiple applications and multiple operating systems, and still it "isn't configured properly". You can't be serious. Complaints about PulseAudio are not really shared by the majority of technical people? Oh, yes they are.
If you want to provide a reasonable sound system, a *core* focus has to be on providing a working sound system. Get the core functionality right, then move onto features. Stability, correctness. Get the basics right. Also understand that API users may stuff things up, and falling over and dying is not the correct thing to do. The infrastructure needs to be resilient, not fragile.
PulseAudio did *not* do this. Any of this.
The order of the day seems to be to blame everything *but* PulseAudio. The apps are broken, the drivers are broken, the operating system maintainers didn't integrate it properly, it's not configured properly for the user's machine, the people complaining wouldn't be complaining if they were more technical, a lot of distros have adopted it so it must be good. Did I miss anything here? This has been the argument thus far.
I'm going to be different. I'm not going to blame the developers, the applications, the users, the knowledge of the users, the operating system developers, or anyone else. I'm going to blame the one at fault, the *cause* of these problems. The one thing in common with this incredible list of problems.
PulseAudio is completely and utterly broken- in design, in implementation, and in application. It is horrendous, shameful, and embarrassing.
Yes there is: you don't want to be playing a game, and only seeing responses to your inputs seconds after you do things. Any noticeable input lag in a game ruins the experience. Ideally, you want no more than one frame of latency between reading inputs, running an iteration of your engine and getting it out to the display/speakers/haptics. Not all content is pre-recorded.
I had Ubuntu running on our main home computer for more than a year. There were definitely some annoyances, but things were tolerable. Until I upgraded Ubuntu (I forget which version) and sound was broken hard - I spent hours fixing it, but got calls from home every few days asking me to "help fix the sound. it's broken again". Finally, I gave up and switched back to Windows.
You have somewhat of a point but it's mired in bullshit.
It's interesting you claim that, as most of the god awful code I've seen seems to come from self-trainees. I also laugh at your jab at C++, since you talk about bloat I can only assume that you are asserting that the devs should be using the holy C89 language which only proves you know jackshit since C++ is no higher from the hardware than C and can even be smaller and faster (by making it easier to eliminate duplication) under some circumstances. Remote Procedure Call is another 'WTF?' claim — you know Unix is very big on these things called Pipes, right? What the hell do you think those are? The tech may be being used wrongly (using a hammer to nail in a screw) but a blanket assertion of uselessness is horsecrap.
Wow, the dev shouldn't care about the end user, huh? The end user should be happy with a 50 page menu and a screen full of unlabelled buttons, any of which could crash their system? Nice to know that you don't actually work in the industry since you'd be unemployable with that attitude.
News flash genius, software exists for the purpose of providing an interface between the user and the hardware, to enable the user to command the hardware to do something useful for them. I think you need to reevaluate your world view since you seem to be a mile off the ground.
That said, PulseAudio is just the latest version of ALSA and ESD, it sucks just as hard because the morons who keep coming up with this crap don't realise that you have to simplify the system as you add new layers, not expose even more bullshit complexity on top of the existing bullshit complexity, hell, it doesn't even eliminate the necessity of competing framework things like JACK [Now what? PulseAudio + JACK on ALSA with OpenAL with ...]. (Phonon is a good example of doing it right by simplifying the crap that is Xine and Gstreamer instead of making it yet more complicated [different area though]).
Are you serious? Faddishness, I agree with. Popularity - popularity is something worth considering. Popularity implies community, and with a large community chances are most elements of a given problem have already been coded by someone else. Consider Perl and CPAN - a good reason to use Perl. But popularity is not enough to make me choose MySQL over PostgreSQL for instance.
Lastly - the end user as a priority needs to die? That really depends on who you are writing the software for. If it's an operating system and you want it to compete with a Windows or OSX on some level, considering the end user is unavoidable. A vastly larger feature set and complexity than say, OpenBSD, is also unavoidable. Lack of time to audit the code and remove bugs to the degree that OpenBSD has done is also unavoidable. Maybe this goes some way to explaining the quality of the code and the size of the user base of both operating systems.
If I have seen further it is by stealing the Intellectual Property of giants.
That's the biggest load of crap I've seen. So it uses system timers and its own buffer management? That's sure looks to me like an overly complicated way of trying to get around poor primary interrupt latency in the OS kernel.
(That's one thing Apple got horribly wrong with MacOS, but fixed properly with OSX. MacOS didn't have predictable interrupt latency, and running any real-time applications was asking for trouble. How Avid, DigiDesign and Opcode succeeded is beyond me. However, OSX has the best primary interrupt latency of any OS right now, and the best audio stack. I really wish someone would leap-frog them to give them some incentive to make it better.)
All these informed-sounding folks, living in some perfect netherworld that doesn't really exist. *sigh*
If I have a recording that is too quiet (for whatever reason), it is reasonable to be able to turn it up so that it's not too quiet anymore.
Not every recording is stuffed all the way up to the max at 0dB. Some are far quieter, whether on purpose or on accident. If I have a recording which peaks at -20dB, then I ought to be able to apply at LEAST 20dB of gain to it without jumping through hoops.
This is not an uncommon problem, and the best (simplest) solution is just to turn it up -- however that's done. It's been awhile since I've done any serious audio in Linux, but if PulseAudio or ALSA or whatever combination thereof requires me to buy extra hardware (WTF?) to achieve this very simple and obvious function, then it is very broken[1] indeed.
And before anyone replies and says "Oh noes! If we give the users gain, they might makes teh Distortions!!!!" This is broken in the "I'm sorry, Dave, I can't do that" sense. It's REALLY fucking stupid that the same operating system which allows you to do "dd if=/dev/urandom of=/dev/sda" without prompting WILL NOT PROVIDE MEANINGFUL AUDIO GAIN.
Kid-proof tablet..
It's [PA] structured the same way the audio systems on Windows and OS X are.
Like hell it is, and I say that as someone who has programmed audio and MIDI apps for OS X, Linux and NetBSD.
There should be no such distinction. Any "lower level" API should be an implementation detail of the application-level audio system, just as the PCI configuration space is an implementation detail as far as X clients are concerned. As for the traditional distinction between the audio deamon interface and the "lower level" one: it's an accident of history that we lived with that split so long. PA is a better world.
Last time I checked, PCI configuration was not time critical. As for the "accident of history", fact is you've got too much functionality in userspace.
As for POSIX real time scheduling? Just because the API exists doesn't mean it's implemented or configured on any of the major distributions, as it requires patches to the regular Linux kernel that would be detrimental to most peoples requirements. And my comment on switching users is no more anecdotal than Poettering's unsupported assertion that PA does what most users want.
Then on to power consumption.
Why is this being done by PA not by ALSA? It really seams this should be implemented in ALSA not in a userspace tool
OSSv4 or older flavours simply does not have the API to deal with a modern linux desktop
Instead of getting into flamewars over APIs, could you explain why OSSv4's API can't handle the modren linux desktop.
...it really wouldn't be a proper solution (and guess what? it would need a daemon running anyway!!)
Audio APP->kernel-> seams like a nice solution, then IF something needs to be pushed back out into userspace, do it
Audio->userspace->kernel just adds more problems for 90% of users, it makes sense to me to have audio->kernel->userspace->kernel when required, the 10% that regularly use stuff that needs userspace action configure it themselves (much like people install jack if they need it).
One final point regarding APIs. Why should the standard API cover stuff like position dependent events when this could be handled by a wrapper/app?
More and more audio device *are* network based.
Then there is the whole concept of thin-clients.
Most users don't care, we've simply gone from something that worked to something that doesn't, but generally speaking most desktop audio is coming out of the speakers, this path should be a priority and if that means stuff gets a bit uglier for these devices/setups so be it. If the only way to handle them while keeping desktop audio sane is too ugly then the people that use these devices should configure PA when needed (or hal should), so that 90% of the time desktop audio (usually single app(+random event sounds)->speakers) is as simple as possible.
Then of course there is the mixer.
This is partly inherited from alsa but dear god do audio devs not understand that 0 = mute? If you must have an infinite scale then don't tell me my audio is at 0!
PulseAudio as an architecture is fast becoming the defacto standard
Terrible argument as soo many de facto standards suck. (not that it matters but de facto is two words, much like de jure)
In addition, rights access and management is a big issue.
I think this is a major strength of PA, however I am the only person that uses my desktop and when I switch to a root TTY I still want to listen to my audio alerts, is there an easy way to disable this feature. (e,g the bug that existed in alsa was a feature not a bug)
You've probably being using a distro that doesn't care to integrate PA properly
Funny i use Fedora, which AFAIK has it's PA maintained by Lennart, yet it still has many problems.
p.s thank you for the informative posts, while I disagree with parts of PA i do appreciate it and can't stand the level of FUD around it.
IranAir Flight 655 never forget!
In terms of playback, the digital side of things should be limited such that it can never clip out. Digital clipping sounds extremely bad, and can damage speakers if it happens at high playback levels. Your computer should function such that 100% on the volume slider is equivalent to 0dBFS, no attenuation. All volume should be attenuation only in the digital domain.
So how do you make things louder? Turn up the volume on your amp. Computer speakers have a volume dial, receivers have a volume dial, etc. Use that, control the volume on the amp, not the digital levels. People shouldn't have to worry about setting their controls such that it results in digital clipping.
Probably because such a think would be expensive, and hurt sound quality. You want as few components in between your amp and the speaker as you can get. This is especially true since it is hard to make large scale passive components super precise.
I'm not sure precisely what you'd need to put in to limit power in this way, but I don't think it'd be very workable. You'd also have the problem in that if you directly measured power, you might limit the speakers in a way you don't want. After all they can handle momentary transients higher than a sustained level.
The real problem is voice coil heat. Lots of power causes the voice coil to heat up and melt, as it is a bunch of very fine copper or aluminium wire. While a temperature sensor connected to a relay would do the trick, there's no way you could get the sense where it needed to be and besides, the weight would screw things up, tweeters are very light.
All in all there's just no practical way to do it, and really there's no need. Not over driving your speakers isn't hard. Most systems (like CD and DVD players) don't allow for clipping in the digital domain, so no problems there. Pushing an amplifier in to clipping is still a problem but less of one. A good amp will have clipping prevention, and things like receivers generally can check all their gain stages and thus regulate the final output so as to not go over what the amp can handle.
Over all it isn't a big problem. If you can figure out a way to cheaply do limiting without adversely affecting audio, I'm sure that it'd be implemented. Remember it needs to be effectively passive, as the only power coming in to a speakers is the signal to drive the cones. However the fact that it isn't done, even on fairly pricey speakers, leads me to believe it isn't possible at a reasonable price point, if at all.
I'm really curious - I haven't tried OSS4 yet, but the one thing I haven't ever gotten working on linux is the following setup:
Analog/Digital speakers, with a USB headset.
Can OSS4 handle USB sound? Can it mix multiple streams? Does it have an easy way to switch between input/output devices?
Pulse gave me hope for the above. Then fell flat on its face. I've never been able to get dmix to handle this setup, and ALSA doesn't seem to do it.
I hate to say it as a linux fanboy, but I want audio like Windows. Right-click on my audio button, and in two clicks I can choose my input and output devices, and all sounds are seamlessly mixed to make that happen. I don't really care about network audio, or any of the other fancy-ass shit that pulseaudio is supposed to do.
Really, I use a desktop, and I have multiple audio sources and devices. Mix them automatically, and give me a quick gui control for which piece of hardware should be handling each. That's all I really want.
Velociraptor = Distiraptor / Timeraptor
but I do have to say that Pulse Audio... well I have nothing good to say about it. OSS worked for me back in the day and I rarely had any issues. ALSA worked for me after some fidgeting but things got stable quite fast. Pulse Audio.... nothing but trouble since Fedora 9 and onward. Is it getting better? Possibly it is, but on all machines that I have used it on it always becomes excruciatingly painful with its odd volumes and.... ok I feel a rant coming along here and I don't want to really diss anything that I didn't actually pay for. But daym... I do have to say that if the rest of GNU/Linux was done this way we would not be here today PERIOD.
Gosh, I never thought of that: I can just take the source audio and adjust it up with mp3gain or sox or something! How short-sighted of me. Thank you for showing me the error of my ways. [/sarcasm]
Of COURSE it's broken, but that doesn't mean it's the application's fault. Sometimes, the mic audio on (say) the camcorder is just too low, and the person running the thing doesn't have the knowledge, skill, or time to fix it. Am I really supposed to figure out how to adjust the gain on some H.264 multiplexed audio/video just so I can show a video to a friend on my laptop, with audio at a reasonable level?
Seriously?
Cuz, I mean: I don't have time to supervise every production that ever happens in every corner of the world, and accordingly things are very simply too quiet from time to time.
Really, folks. I want to live in your happyplace where all audio levels are always sane, everyone has a clue, and all volume controls are simple attenuators. I honestly do. But my reality doesn't work that way.
Kid-proof tablet..
If JACK can handle low latency and it works, what is the point of PA?
The only case where latency does not matter is media player ... and then only when the media is audio, and even then there are limits (~200-300ms max). Video must be pausable and seekable - without delay. VoIP is killed with 50ms delay as the codec will create additional delay.
Recording at -20dB isn't 100% FAIL. Suppose you're recording outdoors and it's windy. The difference between the ambient noise floor of the wind (say 40dB) and the spoken voice (say 90dB) gives you 50dB of dynamic range. Setting it to peak at -20dB puts the wind noise at -70dB, compared to the digital noise floor of -90dB (16bit) or -120dB (24bit). That's a perfectly sensible optimisation which gives a huge safety margin on clipping the signal whilst having the digital noise floor so low it doesn't matter. Remember when setting up you have a much better estimate of the minimum background noise level than the maximum peak - e.g. should your interviewee suddenly shout and you're recording with peaks a 0dB in normal speaking you're going to look very stupid.
In general a professionally mastered recording should peak at 0dB to use the full dynamic range, but sometimes computers are used with original content before it's been mastered.
Only two things are infinite, the universe and human stupidity, and I'm not sure about the former. (Einstein)
I like the idea of a checkbox. Except, as an audiophile, I don't like one bit of what you say it should do.
I'm not always looking for perfect, pristine audio -- some of the stuff that I play on a computer is very low-fi indeed. But one thing that I'm almost never looking for is any sort of compression or automatic gain control: Just because I want to increase the level of a given work, does not mean that I want it ramped up and down automatically.
I mean: If PulseAudio would, as you propose, allow me choose between either having audio that is sometimes too quiet, or audio that is always compressed, then I'll just use Windows, thanks.
A better idea, I think, would be to have a checkbox, and have it soft-clip or limit signals at or near 0dB when activated -- this will keep the nannies happy about their "OMG! Digital clipping!" concerns. Have it do none of these things when deactivated, for the audiophiles of the world. And then, just give everyone the ability to control gain themselves, including adding (gasp!) positive gain.
Kid-proof tablet..
Look, I understand that getting this stuff right is a hard problem and takes some effort to get resolved, and that' s not necessarily the fault of the developer. But it's not my fault either. I don't have time for this kind of thing - while there was a day when I really enjoyed spending a bunch of time fiddling around with my computer to get it to work right, those days are mostly over for me now. I need sound to "just work", and if Pulseaudio doesn't, then I'm not using it.
> Each time Linux redesigns some subsystem there are problems, and we see
> the same people bitching about how we should use $ALTERNATIVE instead...
No, the situation with Pulse is different in several ways.
1. With previous changes there was pain in the transition but even those suffering most could see that the change was going to be a good thing. Not so with Pulse. Pulseaudio is a system that would be, at best, a minor improvement in a perfect world and a never ending nightmare in the real one. Harsh charge? Read on.
2. Pulse blameshifts all it's problems to apps and drivers. Ok, apps (open source ones anyway) will eventually get fixed. Drivers won't. Motherboards do not ship with sound drivers for Linux. Linux ships generic drivers for the sound chips on popular systems. There is a big difference. Board makers connect those generic chips in a myriad of ways, poorly documented if at all outside the Windows driver. Manual intervention and exploration is usually required to figure out what is connected to what and how best to configure things. Pulse's design is to remove all controls except one big volume slider.
Examples: My desktop system requires careful balancing of the VIA DXS, PCM and Master sliders to get enough output to drive my speakers and avoid clipping in the digital side of the system. My Thinkpad needs an easy way to mute the master output to silence the internal speaker while leaving the external output alone to get good results while docked. Feel free to add your story, if enough of us provide use cases where ONE slider won't work.... they will ignore all of us. :(
3. It still isn't even clear exactly what problem Pulse is supposed to be a solution to. Every major application had finally achieved stable ALSA support, and ALSA works. Being able to move sound streams between devices while they play is gee whiz and all, but it isn't a problem most of us are needing enough to endure a lot of pain to get. It might be worth the pain if we were being promised this would be THE audio solution but the Pulse devs themselves admit it isn't, Pulse can't touch JACKs realtime features.
4. But the biggest problem with Pulse is the devs. There are real problems but this time, unlike past transitions, this isn't a case of they haven't fixed all the bugs yet, it isn't even a case where they tell ya to submit a damned patch if ya want your problem fixed NOW. Both of those cases are normal examples of Free Software development. No, what is new is bugs being closed with "That problem can't exist within our philosophy and thus can't be fixed, buy new hardware and hope it works." In other words, that problem can't be fixed without exposing complexity we don't believe should exist. They have forgotten the second half of "Make things as simple as possible, but no more."
Democrat delenda est
The problem with PA's low latency set up is that it consumes and inordinate amount of CPU. Lennart has admitted that. The problem with sound servers doing too much is that they will inevitably add latency. Paradox.
PulseAudio isn't perfect, but the basic ideas behind it are sound, which is why the whole Linux world is adopting it.
I call BS, here.
Things don't get adopted by Linux distributions because they're technically sound; they get adopted if, for whatever other reason, they become the fad flavour of the month.
I tried for nearly two months to use Ubuntu Intrepid Ibex; audio was dying constantly, and I was having kernel panics randomly from the video card drivers as well. Then there was the nightmare when I made the mistake of trying to use another window manager beside GNOME.
Linux in technical terms is crap, currently, and I'm fed up with the denial. I'm using FreeBSD, and have been since January; I wanted to use Linux, but aside from maybe Slack, Arch, and LFS, none of the major distributions are usable without giving me endless problems. It's either package management, or hardware drivers, or the DE is fused with everything else and can't be removed, etc...it's hell.
Stop claiming things are fine when they're not. Stop writing propogandist garbage like this, where you're basically just trying to force people to hold their noses and drink the Kool Aid, when they're telling you in droves that real problems exist.
The denial needs to stop, and the problems need to be acknowledged and fixed.
* We need a sound daemon that doesn't try and have a heap of other features which hardly anyone ever needs, but that just plays audio. THAT'S ALL IT NEEDS TO DO. No client/server crap. No being able to play files while changing the sound card. None of that shit. All it needs to do is play audio files.
* GNOME needs to be scrapped entirely, and replaced with something that isn't committed to simply reproducing all of Windows' design mistakes. We need a window manager that is genuinely designed according to the UNIX philosophy. That means dotfiles for configuration, not a centralised registry which just bogs everything down. It also means use of the pre-existing sockets system for IPC; NOT abominations like XML-RPC. It also means something which is genuinely modular, not where if you install any one single piece, you then HAVE to install all of the rest.
* Init/Upstart both need to be scrapped, and replaced with FreeBSD's init system. It is simple, clear, sane, and WORKS.
* Ubuntu's insane mess for kernel module loading also needs to be annihilated as well, and the standard module loading programs need to be used.
* This is something which I know will never happen, because Canonical are too stupid and delusional, but if they truly were intelligent, they would drop Debian as a base. They need to use something cleaner, like Slack, Arch, or LFS, and they could then save a lot more work for themselves by adopting pkgsrc (which is being maintained by NetBSD) as their package management system. Ports systems are a lot more robust than dkpg/apt, and I don't want to hear the contrary from the usual Debian fanboys, either. YOU ARE WRONG, and Ubuntu's upgrade routine trashing systems is the proof. For ONCE, sit down, shut the hell up, and accept it.
If you really mean any of the talk that you keep endlessly engaging in about wanting to be competitive, Linux community, then fucking lift your game.
The first step to doing that is ending the denial, once and for all. The second is to cease mindlessly aping Windows, and establish your own identity; ideally one based on the very UNIX design principles that you've been so enthusiastically throwing away.
Let's see how many of the Generation Y, amateur, snot nosed brats I get making a response to this post; people like the idiot who wrote the post that I'm replying to, here. People who think that everything with Linux is just fine, and who continue churning out bloated, inefficient, unstable crap, because they don't know how to do everything else, yet still see themselves as an avatar of Neo inside their own heads.
Mod me down, instead of refuting me, as well. Use every lame Slashdot trick in the book for posts you don't agree with.
This is the truth, Linux developers. You might not like it, but you need to fucking hear it.
I see two possibilities here. Either you are just trolling, in which case shame on you for wasting our time; or else you really believe all this ranting stuff you wrote, in which case you need to gain some technical maturity.
Except you're not going to be any more specific here, are you? You'll call me immature, but you don't define what maturity means in that context.
I'm by no means the only person who has had problems with Ubuntu; if you think that, you might want to hang out on their support forums sometime.
And you don't offer any facts or even reasoned debate about any of this.
FFS; I keep hearing this over and over again, too. Go and look at my comment history. Read the comment I made there, only about two posts ago, about exactly what is wrong with GNOME. No, I'm not going to write all of that out again.
You asking for more and more and more "facts," is also BS. The only thing you're really asking for is ammunition that you can use to refute me, because on a completely emotive, subjective basis, you don't want to listen to me at all.
You don't understand why PulseAudio is designed the way it is, therefore it must be the work of an idiot, and anyone who defends it must be an idiot.
I understand that Pulse has a lot of features in it which it doesn't need, for the purpose of playing audio files. The other stuff might be nice, but there's a difference between something being nice, and something being necessary, especially if it doesn't work.
Regardless, this is yet more denial. There are so many people using and writing for Linux who think that the way things are done with it, is the only way things can or should be done, and what that usually translates to fairly directly is imitation of Microsoft, as closely as possible. Hence, when excessively, needlessly complex, bad software is written, you keep defending it, because you don't know any better, and you also falsely associate Microsoft's own history of writing bad code, with their popularity. Which, of course, leads us back to the real heart of the problem.
Attempting to achieve mainstream popularity at virtually any cost, is the only thing that Linux developers really care about at this point. Technical integrity or correctness don't enter into the discussion at all; or when they do, it's even worse. You've redefined what technical integrity means in your own heads, such that said definition always leads back to what will simply make Linux more popular. Not what is conducive to actual stability or efficiency with the system.
"So where is Sound on Linux? In my opinion it's in a pretty good state"
If you call crackling system sounds on every computer I've ever tried Pulse Audio on as a "good state". It definitely wasn't ready to be the default.
Promote true freedom - support standards and interoperability.