PulseAudio Creator Responds To Critics 815
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."
Re:Useless (Score:5, Informative)
PulseAudio is NOT unneeded.
First, Bluetooth audio _sucks_ without PulseAudio.
Second, you NEED to have a sound daemon to properly manage the sound system and other sound daemons suck.
Third, ALSA's volume controls are horrible and PulseAudio really helps here.
Fourth, PulseAudio has a ton of other nice features: streams tagging and automatic volume control, joined devices, mic boost, etc.
The uninformed must improve their deficit... (Score:2, Informative)
here: http://colin.guthr.ie/2009/08/sound-on-linux-anti-fud-calm-certainty-and-confidence/ [guthr.ie]
Re:Why is OSS no longer in the kernel? (Score:5, Informative)
OSS was deprecated because 4front pulled the rug out from under users and started demanding money for binary-only versions, and it was easier to write an entire API from scratch instead of trying to fix the crap they'd left in the kernel.
OSS4 is never going in because 4front has a dangerously wrong idea of how the GPL2 works [4front-tech.com] and think they they have the right to infect applications using this API with their licence.
Do not want!
Re:Useless (Score:4, Informative)
Ok, what? It definitely works as a daemon. But even if it didn't, what's the issue? If you have a dedicated headless MPD server, you gain nothing by using Pulse. If you have plenty of desktop applications that all want sound input/output, Pulse solves basically everything.
Distribution problem (Score:5, Informative)
I've read in several places that the main problem with PulseAudio is not its design and implementation, but its instantiation. Many distributions apparently do not properly set up PulseAudio, causing it to behave unexpectedly. I found this to be the case with Ubuntu 9.04. PulseAudio worked like crap until I followed the following directions to get it set up. It's been working like a dream ever since:
http://ubuntuforums.org/showthread.php?t=789578 [ubuntuforums.org]
LS
Or not... (Score:3, Informative)
Re:Useless (Score:5, Informative)
It definitely works as a daemon
On Gentoo:
Quoted from that link: "The maintainer's interest in making sure system mode is well supported is rather minimal."
Article is doomed to failure, but PulseAudio isn't (Score:3, Informative)
I knew as soon as I read the headline here that this article would be jumped on by numerous "alsa is fine on it's own", "Why not OSS" and "PulseAudio is buggy blah blah" type posts but I didn't think that even the general slashdot hordes were that ignorant about what the hell PA is all about. I was sorely mistaken.
PulseAudio is very little to do about "networked audio" which everyone and their dog seems to use as an example to reason "I do not need networked audio, therefore I do not need pulseaudio". It's just ignorance in the extreme.
PulseAudio as an architecture is fast becoming the defacto standard on Linux, companies such as Intel, Nokia and Palm are putting significant resources into PA just now.
OSSv4 or older flavours simply does not have the API to deal with a modern linux desktop, plain and simple. We can maybe get some of the more userspace stuff such as bluetooth or airtunes support (the support for which I added to PA myself) using some kind of CUSE support but that's only just landed in the kernel just now, and it really wouldn't be a proper solution (and guess what? it would need a daemon running anyway!!)
As a PA developer and supporter, I've written up various articles explaining what PA is all about before and posted similar comments to mailing lists etc.
You can read some of them here:
http://colin.guthr.ie/2009/08/sound-on-linux-anti-fud-calm-certainty-and-confidence/ [guthr.ie]
and
http://thread.gmane.org/gmane.comp.kde.amarok.devel/15356 [gmane.org]
I'll outline some of these things here to save you killing my poor server!
More and more audio device *are* network based. Apple Airport Express devices are pretty popular these days. I have two bluetooth headsets and my hifi system also support bluetooth connections and my Playstation 3 supports uPNP. So lots of things relating to network Audio are popping up (which is nothing to do with pulse->pulse network connections which is arguably a toy, even if I do personally use it a lot!). I don't think these should be ignored. PulseAudio supports all of these devices right now (although I've not had time to try the uPNP stuff on my PS3 specifically so don't quote me on that!)
In addition, rights access and management is a big issue. Today any modern linux desktop uses console kit to keep track of user sessions. When you switch from one user to another, console-kit ensures that the currently "active" user session is set to inactive, and it triggers udev callouts to remove the currently active users ACL on the /dev/snd/* nodes. (I seriously hope no one adds their user to the "audio" group these days!). This allows a new user to log in and get access to the sound hardware because they are now the "active" user. Switching between the two sessions triggers these ACL rewrites. Something has to manage this in applications so that they don't just bail out with EPERM errors. The sound has to go to /dev/null automatically without the application being aware of what is going on. Perhaps it can cork/uncork applications that listen for such signals so that music is paused etc. This is something that cannot be done without some kind of userspace daemon handling things.
Then on to power consumption. What most people quite often fail to realise is that Latency is Good. If you can pump 20 seconds worth of audio into a buffer and then switch off until you're woken up 19.5 seconds later then this is great for power consumption. You need to disable hardware interrupts and use kernel level timing constructs to deal with this, and automatically reduce your wakeup time on the event of an underrun to reduce the likelihood of a future underrun occurring. You also have to have accurate timing information reported such that a/v applications can handle things like lipsyncing etc. (and remember that hoping for a low latency audio output is
Ubuntu is ruining Pulseaudio's reputation (Score:5, Informative)
Re:Too many choices.... (Score:4, Informative)
A common problem, not helped by the tendency of people to reinvent the wheel (and the interfaces). Very much a linux problem, though.
Point in case? ifconfig. There's been what, two supposedly better interfaces both completely incompatible with everyone else's (read: other unices). And then you need a separate command for the low-level stuff (ethtool), or even a suite of commands to do the same (iwconfig/iwlist/...) with vague documentation and prominently featuring things already moved to a different command with no mention this is the case.
Ah, documentation. On linux, most entries in the online reference manual (`man pages') send you off to *censored* info requiring a *censored* "info viewer" that expects you to know emacs and two to one will give you the manpage again only this time you need *censored* emacs contortions to get out of dodge. Couldn't it just bail out and tell me there was no info? Nevermind, I knew that already. I'll move on to a different system. In my case, still a unix, but no linux, kthx.
Should I mention the three, no four, wifi stacks in linux? Why isn't there just one that does it all? What about bluetooth? USB cameras? Video? Similarly: The VM. The Scheduler. I'm sure there are many more examples right round the corner, for reinventing wheels for the sake of reinventing wheels is the linux way. Reinventing wheels squarely for that special corporate sauce enhanced taste is someone else's game, but rightly there isn't much difference for the end user.
Compare with FreeBSD's ifconfig: It does all that, isn't hopelessly buggy, supports modern notations, and can be extended further should the need arise. And it still is compatible with everyone else's ifconfig and no nagging it has something else that's supposedly better only nobody tells you why, or how. Also: Only one wifi stack. One sound system. Ok, so there's three packet filtering interfaces, but at least you can use them concurrently if you wish, and all of them work with all the supported hardware. My point? There are non-windows systems Out There that are well integrated, but none of them are called linux, or gnu.
As to network audio, I'm not sure I want it on that level, there. Unix has always been easily extensible even if through the virtue of a small shell script and a few judicious triggers. So I come home and drop my laptop in the network, what's to stop me from having dhclient trigger a script that sets up simple streaming to my stereo? Heck, I could stream over FTP if I wanted to. Why do I need pulse audio and its horde of bugs for that?
Re:Useless (Score:3, Informative)
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.
But not for dual-boot workstations where users' home dirs are samba shares as it leaves symlinks to /tmp in the .pulse directory of each user that, when a user logs on to a different workstation, prevent Gnome from loading unless the pulse processes are killed. We have had to dump pulse in favor of esound (I work at a University) which doesn't have these issues. Sound, thankfully, isn't that critical on our dual boot XP/Ubuntu boxes but pulse has caused us all manner of issues with these pesky symlinks. I don't think the way our institution does home dirs is especially clever but it's not uncommon.
10 years ago, sound DID work reliably in Linux (Score:5, Informative)
That was on 486 hardware and even worse!
The problems started with ESD or esound, the Enlightenment Sound Daemon. Prior to that, sound daemons were unusual. Nobody actually ran one. Enlightenment (the insane game-inspired window manager) got one, GNOME briefly used Enlightenment, and we've been stuck with sound daemons ever since.
The OSS to ALSA transition was the other botch. It used to be that an app just did open() on /dev/audio or /dev/dsp and made sound. Any competant UNIX programmer could handle that. Now we have a kernel API that is essentially unusable, so you have to use ALSA libraries to do anything. Actually, those are **barely** usable.
Really, it wasn't always like this. My 486 DX4-75 with 8 MB RAM (slackware, fvwm-1.x) could handle audio. Back then, programmers didn't fuck around adding bugs and bloat. They wrote stuff that worked, nice and solid, on the hardware that we had.
Re:who's to blame. (Score:3, Informative)
Well, if the software calls on a driver, and the driver has a bug and crashes, then it's the fault of the driver. Therefore, fix the driver. Simple! Why is this so controversial?
computers are hard (Score:5, Informative)
Sometimes mplayer will have sound, and totem will not, and other times, the opposite is true. Since the switch to pulseaudio, I have never seen a time when they both worked. Just a half hour ago there was no sound in miro. The volume slider in miro was turned up, the system volume was turned up, and my speaker volume was turned up. When I right clicked on my sound icon, went to preferences, and flipped to the "applications" tab, I found yet another volume slider labeled "miro" that was turned all the way down.
A few months ago I bought new speakers and a new sound card because my sound stopped working. The new hardware still didn't work, and a few days later, I found some random profile or device or something that was muted, but to even see that menu I had to change the default device in some gui I had never seed before, and then change it back. Starting about a month ago, whenever I play a youtube video, sound will not work for anything but flash (even after I close firefox) until I killall npviewer.bin
For some reason, when "surround" is muted on my laptop, my headphones don't work, but everything else does like normal, and if PCM gets muted, I will only get sound back if I turn the volume all the way down for a second, then turn it back up. Also, my USB headphones and USB speakers have never worked in linux.
The new surprises with every upgrade is also pretty fun. It used to be that I could just do a killall "pulseaudio" then /etc/init.d/alsasound restart, and everything would be back to the old way of working, but recently it just breaks everything even worse, requiring a reboot to fix. I'm hoping that a clean wipe of everything, and installation of ubuntu 9.10 may magically fix some of these random idiosyncrasies, but I'm not holding my breath for it.
Could you get sound from multiple sources? (Score:5, Informative)
One problem that many forget looking back on the "good old days" of sound is that you couldn't get sound from more than one thing. On single task OSes like DOS this wasn't a problem, you only ran one app. However for multi-tasking OSes it meant that whatever opened the soundcard first had control until it gave it up. This was problematic for many reasons. Meant that you couldn't even do something simple like play an alert sound from the OS if someone was playing MP3s (not such a problem in the 486 days since those were hard pressed to decode MP3s in realtime).
Well, that's where sound daemons come in. The OS mixes sounds from multiple apps and sends it to the soundcard. Thus you can have multiple programs using sound, just like video. What's more, it'll let you do things like control the volume if an app neglects a volume control. Firefox doesn't seem to have a volume control, but the Windows 7 mixer has no problem adjusting its volume, independent of the system.
There is no reason why this should be a problem. Windows and OS-X do it just fine. There is a sound layer the OS has that you write drivers for an all apps can interface with. You can extend/bypass that with your own APIs if needed (like OpenAL or ASIO). It works really well. For that matter on Windows now they have created the concept of Universal Audio Architecture which is a standard way for devices to expose their functions to Windows, and thus work without device specific drivers.
There is no reason Linux can't do this as well. You can have an audio daemon, and should. What need to happen is time send to be spent designing things in an intelligent way first, and then implement them so that they don't change all the time. Have a standard ABI that the driver writers develop for, and a standard API(s) that the software developers write for. Have standard mechanisms for people to add to or override that if needed.
It'll work fine, if designed well, implemented well, and not fucked with. You can't change the spec every other week. It needs to be laid out and stuck with.
This isn't theoretical, as I said OS-X and Windows do it, and have been doing it for some time.
Re:floating point works fine in my kernel (Score:5, Informative)
"The FPU works perfectly fine in a Linux kernel."
Uhm. No, it doesn't. The first floating point exception will ruin your whole day.
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.
Of course, I'd rather just disable FPU exceptions.
Why would you imagine the kernel includes functions to enable FPU access? You think they would exist but not actually work? Sorry, they work quite nicely.
FYI, I actually write kernel code. It pays well.
"The same goes for pretty much anything else, Bluetooth included if you actually care."
Again, no. You need support from the userspace for Bluetooth.
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.
"Even better, in the kernel I can get the ultimate in real-time performance."
Wrong. Kernel threads are not any different from the userspace threads.
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.
"I can get working fine-grained security like SE Linux instead of crap like that offered by the X server."
Wrong, as usual. PulseAudio does not depend on the X-server and you can use SELinux just fine. In fact, PulseAudio works under a non-privileged account, so a flaw somewhere in the mixer code won't give the attacker the instant system-level access.
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.
Re:Distribution problem (Score:3, Informative)
You may be interested that Ubuntu isn't the best at PA integration [0pointer.de].
Re:This is the Sound of (Score:5, Informative)
You should be using OSS4. I put up with the Pulse idiosyncracies until my virtual machines spazzed out. Started researching my options, and found that Open Sound was moving past the deprecated OSS3, which wasn't much better than Pulse.
Since I've compiled and installed Open Sound, I have no more sound problems, period. Everything works the way it's supposed to.
If Pulse and Alsa get their shit together, fine. If not, I'm a devoted OSS fan. Before anyone runs off to experiment, be warned - you will probably have to spend a few minutes purging Alsa from your system. There is no co-existence of the two, at least not on Ubuntu. If you're not a Linux guru, plan on following a how-to, and plan on spending a couple hours getting it right.
http://www.opensound.com/ [opensound.com]
https://help.ubuntu.com/community/OpenSound [ubuntu.com]
Re:Article is doomed to failure, but PulseAudio is (Score:4, Informative)
Latency is Good
No its not. Video playback with an audio lag of several seconds? Not good. Playing games with an audio lag of several seconds? Not good.
As for the networked audio stuff, you mention UPnP. All you need for UPnP to work is a dedicated UPnP server like Mediatomb to stream your audio to the client. You do NOT need an audio daemon for this.
Re:who's to blame. (Score:5, Informative)
I'll stick my neck out here. First, Pulse relies on the Alsa driver. There is no hardware issue, and the driver issue seems to be the Alsa driver. OSS4 works on my hardware, where Pulse and Alsa failed. And, of course, the Windows sound drivers work on that same hardware.
People with sound issues on Alsa and Pulse should try OSS4.
Re:Why is OSS no longer in the kernel? (Score:3, Informative)
Meanwhile FreeBSD doesn't give a crap about what zealots want or do not want, and does just fine with sound.
Re:Or yes (Score:3, Informative)
It's all about keeping the issues list organised and neat.
Some of your stuff wasn't related to PA, so he told you were to file them.
Some of your stuff was duplicates, so he told you were to discuss that, so he and other people could help you out, and in the long run get a more stable system released.
Some of your stuff was already fixed, so he told you that it would most likely get included in an update of the next major version of your distro.
Think about it, he might have a lot of issues he has to keep in organised. Having ONE "issue" with several unrelated problems will make it a hell to try and fix. The inconsistent flow of unrelated comments and discussions would only make it worse.
I don't think there is even one large open source project that excepts multiple problems as one "issue", and would most likely respond in a similar maner.
Some project take it even further and replying "File separate issues. Closed."
This is a "problem" with the open source community as whole, and not with Lennart (or any one else) ignoring your reports.
Re:Durability in the face of errors (Score:3, Informative)
DirectSound works like this - application > directsound > drivers > hardware UAA works like this - application > UAA > hardware
Re:who's to blame. (Score:5, Informative)
Same here, yesterday I spent 4 hours on a media PC I built and configured for my brother in law, up to the point that everything worked at my place using SPDIF output (which already cost me 2 hours to get working in the first place). I arrive at his place, turns out he wants to use the HDMI output instead of the SPDIF. No problem, you'd guess, just go to the sound preferences and select HDMI, right? Not on linux you don;t and not with PulseAudio apparently. After dicking around with the 4 different mixers (gnome, alsmixer, pulseaudio) and 4 layers of configuration (gnome sound settings, pulseaudio settings, alsa settings, gstreamer settings) it turned out that I had to put a file called .asoundrc with some cryptic content in my home directory, and in some tab called 'switches' in the PulseAudio advanced settings had to check 4 boxes that did something with an 'iec958' (whatever that may be) and then, finally, it worked. Not very well by the way because the Ubuntu startup sound pops and stutters like hell, but after that it's more or less 'ok'.
I've been using Linux for over 10 years now and I've been telling people over and over again how even your grandma could use it, but sadly, I have to conclude that in some ways it still sucks balls for people who don't like fiddling around with obscure settings, configuration files, 4 layers of sound settings etc. I really love linux myself but let's face it, for example sound and wireless (damn wpasupplicant and 'wlan0: link not ready) are still lightyears behind Windows and (even more so) OS X in terms of usability.
Re:who's to blame. (Score:3, Informative)
Re:Ubuntu is ruining Pulseaudio's reputation (Score:4, Informative)
If they did, they either had a lot worse latency than PulseAudio currently has (arts, esound) or they drained laptop batteries much faster than PulseAudio currently do (JACK) or couldn't mix audio coming from different user accounts (JACK). All of them had worse backwards compatibility than PulseAudio.
If they didn't, they could only have one application at a time play sound unless they had one of those relatively rare sound cards that had both hardware mixing and Linux support.
A sound server is by its nature not a normal application. It has many somewhat conflicting requirements that just about no other type of application has to deal with. It's a userspace program that has to do a lot of things traditionally done in kernel space.
As it's very sensitive to timing, realtime priority is optimal but not needed for a usable desktop setup. Ubuntu's default kernel doesn't even have full preemption enabled though. In 2009. Under those conditions you can't run something as timing critical as a low latency sound server reliably.
Re:Article is doomed to failure, but PulseAudio is (Score:2, Informative)
"next LTS (Hardy Heron) and boom... pulseaudio screwed it all up..."
Dude, Ubuntu's integration of PA in that version totally sucks. They didn't even try to get things right there and this then reflects badly on PA. Ubuntu have made a *lot* of mistakes with pulse and are continuing to do so, so please don't use this as the benchmark to judge.
We released Mandrvia around the same time with our first PA-by-default version, and it was received very well. So don't blaming the carpenter just because the stable boy left the door open while the horse bolted.
Re:This is the Sound of (Score:2, Informative)
Actually I have oss4 for hdaudio, and alsa for usb audio working together on debian. It is was a royal bitch tho. I run this script instead of oss soundon/soundoff
#!/bin/bash
set -x
if [ ! -d /lib/modules/$(uname -r)/oss ] /lib/modules/$(uname -r)/kernel/oss /lib/modules/$(uname -r)/oss
then
soundoff
soundon
mv
depmod -a
fi
rmmod oss_hdaudio /usr/sbin/ossdetect -d && /usr/lib/oss/etc/legacy_devices && /usr/sbin/ossdevlinks -v /usr/sbin/savemixer -L -v
rmmod osscore
modprobe osscore vmix_loopdevs=1 &&
sleep 1 &&
modprobe oss_hdaudio &&
sleep 1 &&
sleep 1 &&
sh
sleep 1 &&
sleep 1 &&
sleep 1 &&
modprobe snd_usb_audio
Re:Article is doomed to failure, but PulseAudio is (Score:2, Informative)
Dude, I'm not talking about lag, I'm talking about latency. Latency is the time it takes from inserting the data into the buffer for it to be heard. Lag may be bad, but high latency is certainly good.
Mediatomb is a deamon in itself and it's a totally different use case than the UPnP support in PA, so please don't compare apples to oranges.
Re:Why is OSS no longer in the kernel? (Score:3, Informative)
I have a few apps I maintain where audio is central (without audio, the apps do nothing). One is rather old and uses OSS (or the OSS compatibility driver) the other is Python and uses the ossaudiodev module. Given that OSS might be going away entirely, I looked at the alternatives.
I heartily agree that ALSA is a nightmare.If that's the only answer, I'll just retire the apps. Perhaps if there was something like documentation it wouldn't be so bad, but based on the "simple" example code out there, I'm thinking it would just be a documented nightmare. Please shoot Alsa in the head and put in a real audio API!
Given that, I can well imagine a lot of apps where sound is incidental would just forget about the audio. It's no wonder that the years depricated kernel OSS compatibility driver is still in heavy use. In the Free Software world that's a hint that the new "favored" API is a loser.
OTOH, I find that pulse works quite decently on my systems. There are some bogosities, but they can be solved. I don't see why it shouldn't run as a system wide daemon by default (it wouldn't actually have to run as root to do that). However, in spite of that, it works and it has an actual documented API that doesn't require a 4 year degree in PulseAPI to understand and doesn't require a library several times the size of my entire app. It even has an 'as advertised' simple API for apps that don't need anything fancy from the sound system. It's just fine if the objective is (as it is for many apps) just output this audio when I say so.
I was able to drop in support for pulse audio in minutes starting with nothing but the libraries and a couple pages worth of documentation. The next release of my apps will try pulseaudio and is it isn't available will fall back to the old OSS interface. If that's not available either, they'll just print an error message and exit.
Re:Could you get sound from multiple sources? (Score:4, Informative)
ALSA handles multiple sources well enough by itself, with the dmixer plugin.
I imagine sound servers may have some legitimate uses, but for the software mixing, I don't see any reason why most users would need anything beyond plain ALSA. Thus it seems like a bad idea to run a sound server by default.
I also use plain ALSA for making music, and when I play around with multiple sound cards, I want to set things up as directly as possible. The dmixer plugin is easy to bypass.
Re:Article is doomed to failure, but PulseAudio is (Score:4, Informative)
One of the nice things about PulseAudio's design [archive.org] is that it allows you to combine large buffers for some tasks with very low latency for others.
Re:This is the Sound of (Score:4, Informative)
When you overdrive a digital source, it doesn't get louder as much as it starts to lose information.
Unlike an old analog amplifier, which got "warmer" or increased the harmonic content when you went "into the red", a digital signal just starts to crap out.
If you want to make a sound coming out of your computer louder, you turn up the amplifier outside of the computer. You wouldn't want the audio software to do it.
Re:This is the Sound of (Score:3, Informative)
Clipping can kill your tweeters. It generates lots of top-end harmonics, and can send more power to them than they can handle safely.
This was particularly a problem with the original Advent loudspeakers.
Re:This is the Sound of (Score:4, Informative)
But when the amplifier clips hard, it's usually not the amplitude of the signal that kills the speaker, but the unusual frequencies that get added. No limiter will help in that case.
Re:Durability in the face of errors (Score:5, Informative)
Aureal folded
By "folded" you presumably mean "were destroyed by Creative using bogus lawsuits".
Re:who's to blame. (Score:3, Informative)
Well I know for a fact that I could do almost that using esound and artsd like 5 years ago, except for the 5.1 part (only stereo). Not that artsd or esound were fantastic, but at least both worked, both worked without requiring elaborate configuration, both worked straight on top of ALSA, neither had skipping or popping playback and also, neither of them ever broke a working configuration on any of my machines.
The whole idea behind PulseAudio sounds great, except that 99 out of 100 people simply want working sound out of the back of their computers, over any of the ports the card has available. If I have to spend 4 hours to get to that point, the thing is not ready for prime time.
Comment removed (Score:3, Informative)
Re:10 years ago, sound DID work reliably in Linux (Score:3, Informative)
Then why are so many people having so many problems with getting the most basic of these (the sound card itself) to work?
The DESIGN should cope with the situation you talk about, but the (early) IMPLEMENTATION should surely be able to handle the most simple case?
Isn't PulseAudio already on release 0.9.19 or something like that? Surely after this number of releases it can reliably handle the the simple case of dealing with a single sound card?
Use pinfo to read info pages (Score:3, Informative)
Use "pinfo" to read info pages: apt-get install pinfo
pinfo is the opposite of "info" in almost every respect:
And as a bonus, you can use it to read man pages too:
Re:Too many choices.... (Score:3, Informative)
Should I mention the three, no four, wifi stacks in linux? Why isn't there just one that does it all?
The Linux kernel has exactly two WiFi stacks: an old one which drivers are being migrated away from, and the new improved one. The old one was abandoned because it wasn't that great and Linux was effectively given a far better one for free by a generous company.
(There's also various out-of-tree WiFi stacks, like MadWifi and a whole bunch of open source drivers provided by hardware vendors. A lot of these exist because vendors typically have their own internal WiFi stack already for Windows use. These drivers have mostly been made obsolete by in-tree drivers using the normal in-tree WiFi stack.)
As to network audio, I'm not sure I want it on that level, there. Unix has always been easily extensible even if through the virtue of a small shell script and a few judicious triggers. So I come home and drop my laptop in the network, what's to stop me from having dhclient trigger a script that sets up simple streaming to my stereo?
That's fine if you just want to stream media files. Now imagine you wanted to send the sound for arbitrary applications over the network, and the applications mostly weren't designed to support this. No way to do that easily without something like PulseAudio, especially if you want to switch where already-running apps send their sound.
Re:Article is doomed to failure, but PulseAudio is (Score:3, Informative)
Re:Ubuntu is ruining Pulseaudio's reputation (Score:3, Informative)
Lennart gripes in that post about some kernel patches that Ubuntu included
Not kernel patches - PulseAudio patches. The first patch is complete and utter nonsense - it does an entirely pointless memory allocation and should have no effect whatsoever. The second one changes the default volume control behaviour in a way that's very visible to users for no particular reason.
but his fundamental complaint is that Ubuntu didn't add a different patch, to allow an application called rtkit to put other processes in real-time priority classes.
Oh, they did more than that - they chose to block the installation of rtkit, so even if users manage to install a kernel with the appropriate patch they can't install rtkit to actually make use of it.
Re:This is the Sound of (Score:3, Informative)
I'm not qualified to answer all of your questions and concerns. I DO KNOW that OSS4 handles USB speakers. I have no speakers plugged in to my sound card, all I use is the USB headset.
I also know that OSSMix can mix your multiple streams.
Since I don't switch between multiple input/output devices, I can't say.
As for analog/digital speakers, I'm lost. I THINK that you can plug in both, and even switch between them, but hell, I'm not an audio buff, so don't start me lying. ;^)
My best advice is, visit the 4Front forums, and search or post your concerns: http://www.4front-tech.com/forum/index.php?sid=dadb22fbf3e8e7037a272e7e241fa1c5 [4front-tech.com]
Re:This is the Sound of (Score:4, Informative)
Aaahh, the mystique of vacuum tubes...
But this is one of those places where they really are better. Semiconductor amplifiers tend to run right into the rails and clip hard, generating piles of harmonics. Vacuum tube amplifiers tend to clip more softly/slowly, and therefore don't generate as much higher-frequency harmonic content. That's just saying something, just like "vacuum tube amplifiers sound better", so to try and put a little technical spin behind it, I'd have to give a conjecture for softer clipping: Vacuum tubes run off of higher voltage, lower current power supplies - in other words, higher impedence. When running from a higher impedence power supply, as you approach maximum output, the local supply starts to droop, adding its own limiting action to the output. So the "clipping" is less like "abruptly clipping" and more like "gradually running out of steam."
Your dumb ol' SET tube amp has unilaterally decided to limit or prevent clipping.
Re:This is the Sound of (Score:3, Informative)
Can OSS4 handle USB sound?
Yes.
Can it mix multiple streams?
Yes (it just works).
Does it have an easy way to switch between input/output devices?
OSS is the Unix Way - audio devices are just files. An application written for OSS generally provides some way to specify the device you want to work with; this could be wrapped in a neat UI, but it really is something for UI toolkit or DE to handle, not OSS itself.
Adobe's Linux sound bitching (Score:5, Informative)
An interesting side note on audio APIs: http://blogs.adobe.com/penguin.swf/linuxaudio.png [adobe.com]
Man, not that bullshit again...
Let's break this down.
First you have platform independence layers - things like ClanLib, SDL, libao, PortAudio, Allegro, and Open AL. These would be present on any platform. That's the point of them. The diagram seems to go out of its way to mix these in with lower-level technologies, as if to make it less obvious that they're just included to pad out the diagram.
Then there's the trio of obsolete network audio servers: NAS, ESD, and aRts... I suppose if I were to fire up a quick game of xpilot then I might want NAS, but otherwise one can usually assume these days that these three servers aren't installed and don't need to be.
There's FFADO - which is relevant if you're using a firewire audio device... How many people do this? I guess it could be popular among musicians and sound techs - have audio hardware outside the computer's case, accessed via a bus that isn't USB... But this is a driver layer, not an API layer - and these days it seems FFADO provides an ALSA interface, so I think the complaint here is obsolete.
That leaves three modern sound servers (Jack, Pulse, and GStreamer) and two low-level APIs (Alsa and OSS). This is still a bit of an unfortunate mess IMO but nowhere near the rat's nest implied by the diagram.
Re:This is the Sound of (Score:2, Informative)
Amen.
There is absolutely nothing magic about 0dB, it means the signal is considered to have no more/less power than a COMPLETELY ARBITRARY REFERENCE signal. If you measure in dBv, that reference is 1V RMS, if you measure in dBu, that reference is 0.77V RMS, if you measure in dBm, that reference is 1mW power, if you measure in a digital format, it can be referenced to the maximum representable signal (in 16-bit audio this is obvious +/- 32767
As the parent pointed out, if your input file has some headroom (basically the maximum signal level is less than the maximum representable level) you can increase the volume without clipping until you run out of headroom. Most modern pop/rock recording have very little headroom throughout the entire track, so as soon as you bump up that master fader things start to sound crappy, but a lot of older recordings and many well-mastered modern recordings have quite a bit of headroom, except perhaps for a few strong peaks in the music. Putting the master volume at +6dB doesn't mean the output is trying to be 6dB higher than the maximum possible output and thus clipping, it means the output tries to be 6dB higher than the input. If the input is at -20dB, than the output will be at -14dB.
In regards to normalizing, the fact that there is no real-time normalization has nothing to do with a lack of algorithms, it's because we haven't discovered time travel yet. Normalizing a signal adjusts the level of an entire track/recording by a certain amount, generally to avoid clipping and provide some headroom for the loudest parts. Without knowing how loud the loudest parts of the track will be you can't normalize. The real-time equivalent is limiting and compression, which will selectively decrease small parts of the track when it gets loud.
Re:Ubuntu is ruining Pulseaudio's reputation (Score:3, Informative)
"If they didn't, they could only have one application at a time play sound unless they had one of those relatively rare sound cards that had both hardware mixing and Linux support."
Well, to nitpick, this isn't true. ALSA has software mixing support courtesy of dmix, on almost all cards, and most distros used it by default for some time before PA use became widespread.
Re:Useless (Score:3, Informative)
A more complete quote from your link:
Q: Is everything in OSS open sourced?
A: No. There are three drivers that have mosty been written by the hardware manufacturers. We are not permitted to release their sources unless their authors as us to do so.
Also some parts of the envy24 and envy24ht drivers contain some code written under NDA. We have not yet received the approval to open source the code from all manufacturers. So these drivers cannot be open sourced just now. If we don't get the approval in reasonable time we will distribute these drivers with the offending code stripped from the sources.
Finally there are some effects in the old softoss driver that are not included in the source packages. We will make the decision about their future later. At this moment it looks like we will remove the softoss driver from the OSS package so these effects will not be used in OSS anyway.
We reserve the right to include some "closed source" drivers only in our binary distribution if the hardware manufacturers refuse to give the programming specs without NDA. Our policy is to promote open source but not to enforce it. We will let hardware manufacturers to decide if they like to select the commercial distribution mode instead of the open source one with much wider customer base.
http://www.4front-tech.com/forum/viewtopic.php?f=19&t=2411 [4front-tech.com]
OSS now released under BSD license
Postby dev Fri Jan 04, 2008 8:36 am
We are releasing the FreeBSD version of Open Sound under a BSD license and we hope that the BSD community steps up with ports for NetBSD and OpenBSD and enhancement to FreeBSD ports.
http://www.4front-tech.com/forum/viewtopic.php?f=19&t=2139 [4front-tech.com]
Open Sound System is now open sourced!
Postby dev Thu Jun 14, 2007 4:16 am
We're releasing the source code for Linux/Solaris/FreeBSD/Unixware under CDDL/GPL licenses - get the source at http://developer.opensound.com/ [opensound.com]
We thank our paying customers for keeping us in business all these years - and we now hope that no one has a reason to not use OSS because it isn't open sourced.
Best regards
Dev Mazumdar
http://www.opensound.com/wiki/index.php/Building_OSSv4_from_source [opensound.com]
Contents
[hide]
* 1 Building the OSS sound system from source
o 1.1 Requirements to build the source code
o 1.2 Building the source
+ 1.2.1 Obtain the OSS source
+ 1.2.2 Change to the source directory
+ 1.2.3 Extract the source tarball
+ 1.2.4 Create a build directory, and make it current
+ 1.2.5 Run the configure script
# 1.2.5.1 Notable configure switches
+ 1.2.6 Run make build
+ 1.2.7 Packing Open Sound System (
Re:This is the Sound of (Score:3, Informative)
"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."
By all means file a bug. Contrary to your later assertions, we (myself, in co-ordination with Lennart and Jaroslav) have developed a process for reporting this kind of issue in a way which provides the correct information for us to efficiently adjust things so that ALSA exposes an interface to PA which allows it to properly control your volume. Cue celebrations. See https://bugzilla.redhat.com/show_bug.cgi?id=497966#c1 [redhat.com] for instructions.
Re:PulseAudio sucks!!! (Score:3, Informative)
Re:who's to blame. (Score:1, Informative)
What happened to me in ubuntu (Your mileage will probably vary) was that libsdl only supported PulseAudio. Try looking the description of the package/alternate sources...
Re:Difference with FreeBSD? (Score:3, Informative)
Hi all... FreeBSD user, not really a Linux guy. What's the difference between our sound system and Linux, anyways?
The difference between Linux and FreeBSD in terms of audio, is the same as the difference between Linux and FreeBSD in general terms.
Namely, that FreeBSD is developed by adults, who know what they're doing. As a result, things in FreeBSD generally just work, without fuss.
Re:10 years ago, sound DID work reliably in Linux (Score:3, Informative)
10 years ago, you couldn't play two sounds at the same time unless your card could handle it in hardware.
No cacophony? Sweet! Sign me up!
Unfortunately OSS version 4 (part of FreeBSD and OpenSolaris) does mix sounds. It's in the kernel too, so things JUST WORK.
Also, that's about when (IIRC) they started introducing cards (e.g. AC97) that could only two one or two rates or (in some cases) could only do stereo. The driver would simply refuse to handle mono or 8 kHz so you had to resample by yourself.
OSS 4 resamples too. FWIW, the old OSS did stereo and fast rates if you used an ioctl to request them or if you opened /dev/dsp as the device.