Guest post by PulseAudio 0.9.15 has been released with many new features. Phoronix covers the changes: “PulseAudio 0.9.15 introduces native support of Bluetooth audio devices using BlueZ, Apple Airport Express support, flat volume support (similar to Vista’s audio controls), on-the-fly reconfiguration of audio devices, and native support for 24-bit samples. The on-the-fly reconfiguration of audio devices is great and as a result there is now proper S/PDIF support. With the release of PulseAudio 0.9.15 also comes an update to the PulseAudio Volume Control program. The PulseAudio Volume Control 0.9.8 update brings support for configuring sound card profiles and various other updates.”
The big question is: Does it finally work? Or are there still sound errors with this version? Crackling sounds every now and then, problems with games or anything that does not natively support PA and even xine WITH PA support. Sound under Linux worked so much better before there was PA. To bad that every major distribution force PA onto us. In Fedora 10 sound is unusable when you uninstall PA (only one app at a time can use the soundcard).
erm… that is PRECISELY the problem that pulseaudio is trying to fix.
It may not be perfect, but it allows for more than one app to use the sound card.
If you uninstall Pulseaudio, you revert to the system that was before pulse which was each app having exclusive access to the sound card.
If you uninstall Pulseaudio, you revert to the system that was before pulse which was each app having exclusive access to the sound card.
Incorrect. Many soundcards actually do support hardware mixing and work just perfectly, and many distros shipped with ALSA dmix-plugin enabled so the cards which didn’t support hw mixing were still useable by many apps simultaneously.
ONLY when dmix was not enable AND the card didn’t do hw mixing you had trouble.
So, the simplest solution would just have been to enable dmix by default or, even better, improve ALSA drivers to know whether or not they should handle mixing and dump the whole dmix plugin to the trash.
But no, people decided to copycat Vista; as soon as it was announced that Vista has per-application volume settings PA became mandatory for Linux-users, too.
Personally, I don’t understand such mentality. ALSA was working and it would have been much simpler to modify that than to create yet another layer (f.ex. application->Gstreamer->PulseAudio->ALSA). As for PulseAudio itself; I have absolutely no use for it.
For some applications such as a jukebox, this is exactly the way you’d want it. Why oh why oh why do you want some stupid flash ad to jump into the middle of your music and screw it up? I would expect 99% of users do not want sound mixing! Real sound pros will know what to install in order to receive sound mixing capabilities.
what about disabling flash or closing the browser beforehand, when one wants to listen to music then?
you cannot realistically force the rest of the world to choose between EITHER a system limited to 20 years old functionality, OR a more modern but half working system just because you don’t care for that functionality…
i would expect 99% of users would take for granted that, given more than one application at a time, able to emit sounds, sounds would come out mixed , and consider a system that limits audio playback to one application at a time, obsolete at best, or broken at worst
real sound pros are FAR beyond basic sound mixing …
[/q]if you come to think of it, giving one app at a time exclusive access to a device, is quite an old fashioned model – windows got away from that since win 95 osr2, should we assume linux is architecturally older than a 13 yo OS?
(actually it is at least partly – the posix api and unix itself – formalizing in the 80’s a heritage dating back to the 70’s – hardly is new and innovative technology… )
Edited 2009-04-15 20:06 UTC
If I disable flash, then the next thing that happens is the MessageBeep() or whatever they call it jumps into your music. This is why Windows jukeboxen always suck. You say close the browser, why not just say do not multitask (20 year old tech eh). If you need to hear other apps at the same time, you need a second sound device (ideally with the volume turned down or headset). Does my wonderful Marantz theater system allow mixing of different inputs? NO. The real audio people know the hazards of shared access audio.
While that’s one example of a way that audio mixing can be negative, there are plenty of other examples of ways that it can be useful. E.g., I usually have music playing in the background while working, but I still want to hear the audio notification when I get new EMail, or when a new response is sent in an IM window that might hidden, etc.
IME serious sound pros have external, hardware-based mixer panels.
In what strange parallel universe are you living? Before PA it was no problem for multiple apps using the sound card at the same time using ALSA! The OSS implementation for Linux could not handle that case (however, as I understand OSS4 would be able to), but ALSA never had a problem with that (as long as I used it).
Well Fedora integrate it in KDE4 and this causes issues. I’ll stick with Phonon and it all works fine, when I use Fedora KDE version, I uninstall PA but just leave the libpulse in.
ibex was plagued by pulseaudio bugs, with reports of it randomly freezing on a variety of soundcards (including mine). its inclusion in ubuntu so early was a bad idea..
also, why? didn’t we have already alsa/dmix? other unixes use 4front OSS, which already does (much much better) in-driver multiple stream mixing…
PulseAudio only serves to fix a problem which was never there and break everything in the process.
PulseAudio introduces extra latency and how anyone in their right mind would want to do that just to get no additional functionality whatsoever (except maybe separate volume controls for applications, which OSS4 already has) is beyond me.
In science it is called Paradigmenwechsel (Kuhn, Feyerabend), which means a potential far better Ansatz in his first stage is far less usable.
Like Kde4 – Pulseaudio climbs to the next stage now ?
Edited 2009-04-15 13:26 UTC
A problem that was never there? Do you not use USB audio devices, or do all your cards to perfect hardware sample conversions?
ALSA, imho, was a bad idea but we’re stuck with all it’s crap and now we have yet another layer to cover up the crap ALSA is. PA is required for any of my USB audio devices to work, precisely because it does these things in software–sample rate conversions, channel conversions, and so on. Windows and OS X do these in software as well… which is one of the reasons their audio works properly with most external audio devices. Linux, on the other hand… well, I suspect audio will always be a big fail. Rather than using OSS like all other UNIX platforms do, we had to reinvent the wheel yet again. ALSA are decent *drivers* but nothing more, Dmix is garbage if you need any type of quality out of it on anything but perfect hardware, and the alsa devs do not want it fixed. Hense the need for a software layer to cover up the garbage that is ALSA’s mixing.
No, I don’t use USB audio devices, and that’s because USB audio devices are useless. You see, the whole USB audio thing is flaky and won’t ever give you the performance of a firewire audio device.
If you don’t need that performance, why would you invest in an expensive soundcard?
Thank you for proving you have no idea what you’re talking about. My USB sound card cost a huge $20 USD. Wow, really expensive. I got it for the simple reason that I needed something better than the onboard card in my laptop, which picks up noise from the internal hd. The USB audio card doesn’t, and that’s why I got it. If I were going for high performance, I’d have gone with firewire… but I wasn’t. And just because you don’t use something doesn’t mean the rest of us won’t use it. The “oh, you don’t need that” argument tossed around from time to time is a thinly-veiled admission that you have nothing really to say about the issue.
I used a USB sound card on my old laptop as it had no S/PDIF output on the onboard adapter, and I use one on my HTPC because it’s run out of PCI slots (and again, no S/PDIF on the onboard).
There’s two good excuses…
I’ve had a pair of USB speakers that worked reliably before PulseAudio was even a glint in someone’s eye.
You know, I keep hearing the ‘ALSA is crap’ argument from people in order to justify PulseAudio but I don’t see any justification for sticking another layer on top of it that makes basic things (sound coming out of your speakers for instance) far less reliable than what went before. PulseAudio was a knee-jerk response to what Vista was doing and nothing more.
> PulseAudio only serves to fix a problem which was never there and break everything in the process.
Precisely!
Just install OSS4.1 and no more problems! And it sounds better to boot!
Is it FLOSS yet?
Never mind .. http://4front-tech.com/hannublog/?p=9
Why does Linux not use OSS4? I don’t understand why they went the ALSA route. What are the advantages of the current Linux design (in theory at least) when compared to the OSS4 sound server used by the other *nixs?
As audio developer, i couldn’t more than agree. ALSA is a painful, extremely over-complex api and library in comparison and it really is unnecesary. It handles multiple stream mixing in userland (as opposed to kernel in OSS4), which generates all sort of exclusive access problems when you want to mix low latency and normal latency apps, and makes configuration through asound.conf _HELL_. OSS4 is a much better, simpler, solution and design and since it’s opensource now, i can only wish linux distros would start shipping with it and deprecating ALSA. The only good side of ALSA is that it has better support for professional sound cards, although most are, of course, still half implemented anyway.
i’ve asked myself this same question and seen it on discussions asked by others, the reply they get is invariably: “OSS has been deprecated, development happens on ALSA now”
never mind OSS v4 is a very different thing from the old oss-linux implementation;
never mind OSS4 is a compact implementation of a streamlined, *nix – aligned (open, close, read,write, ioctl, period) and well documented API, while ALSA is complex and overengineered both API AND implementation – wise, and scarcely documented in parts (even pulse audio’s author recommends to use a subset of ALSA’s features!)
never mind ALSA is actually designed for the lowest common denominator HW and then actually less capable for the beast it is – since it cannot natively do inter application stream mixing even if the HW itself coud perform it (actually, penalizing those who have a decent sound card to settle with those with onboard audio)
never mind OSS(4) is actually more in line with the duties of a kernel like linux generally speaking ( like dealing with more applications accessing a resource at once, letting the resource appear to each one as available – and doing so in a transparent and orthogonal fashion) than something that forces the presence of a user level daemon to a very basic task (by today’s standard) like that
lennart poettering has said, that:
“cards capable of HW based mixing are a thing of the past” (of course, creative SB Live, Audigy’s and Xfi’s dont exist to this day)
“god forbid floating point in the kernel” (now why must the kernel avoid FP ops at all costs is beyond me.. saving and restoring FP registers isnt a big deal IIRC)
and, most important, “an api like that of OSS cannot be virtualized”
(apart from the fact that everybody obviously needs to vityualize the sound card… but read() write() open() close () and ioctl() cannot be virtualized? since when? )
so, as a logical conclusion, “OSS is crap” …
he’s the author of pulse audio, so he apparently is the new guru and director of audio stack development as far as linux is concerned, and his word shall be taken for law… sadness
“lennart poettering has said, that:
“cards capable of HW based mixing are a thing of the past” (of course, creative SB Live, Audigy’s and Xfi’s dont exist to this day)”
Lives and Audigys are, indeed, things of the past (you can’t buy ’em new any more), and the X-Fi still has no practical open source driver.
http://www.newegg.com/Product/ProductList.aspx?Submit=ENE&N=2000290…
Really?
And do any of those cards use that fancy hardware in Vista or Windows 7? Nope. Might as well be basic intel sound chips on those cards for all the good that hardware is going to do you.
Yes -really-!
You can either buy a 10 year old technology that’s limited to analog 5.1 output (SB Live 5.1), or buy the crappy Audigy 4 SE which has a crappy hardware and lousy support. (It’s not even based around the emu10k family)
If you want a good SB card with solid support you’ll have to hunt down a used SBLive Audigy 2ZS in on Ebay.
– Gilboa
I want to cry.
By the way, you don’t need floating point to mix audio, you just add samples together. You also don’t need floating point to resample audio, fixed point works better (and you can even do cubic interpolation almost for free in fixed point by making a delta resampling table). In any case, i still believe alsa should be declared dead. Most of it usage in proaudio was for sequencers and synthesizers, as a (working like crap) midi layer over low latency jack. However, jack api now includes frame-accurate midi, making alsa api obsolete.
Please, deprecate ALSA!!
I couldn’t agree more, anyone who’s programmed using ALSA, I suspect would agree that OSS is and has always been a much better design.
Right now, the one thing holding back OSS 4 is its drivers. They just don’t support quite as many cards and have some quirks where ALSA’s drivers do not. In contrast, the drivers themselves are the only good thing about the garbage heap that is ALSA, as the API and Dmix are just total crap.
At the time ALSA was conceived, supposedly it was all due to a licensing problem with OSS/Free. That may be true, but I never understood why we didn’t just re-use the API and some of the OSS design. They were good, they worked, and they were simple. Now we have an overcomplicated, multi-layered junk pile that will collapse if you push it just a little bit the wrong way.
Pathetic.
Linux can’t include or rely on OSS4 because it isn’t even remotely Free Software and is definitely not GPL-compatible, so quit whining about wanting it, because it isn’t ever going to happen unless 4Front decides to roll over.
http://www.4front-tech.com/license.html
The 99.9999% of us who do not spend extra cash on add-on cards don’t really care if they exist or not. We want audio mixing (without having to restart half our desktop because we just plugged in our USB or Bluetooth headset) using the ac97 and hda-intel drivers that all but a handful of people are using to work perfectly.
You can use PulseAudio because it’ll work on top of those higher-end of cards just fine too, albeit without taking advantage of some of its features. Then again, the dmix solution people tout didn’t use those hardware features either, and relying on the hardware features means that the second you hit the hardware limits things start to break, because neither ALSA nor OSS can gracefully use both hardware and software mixing based on the hardware profile and actual application sound usage.
You can even use PulseAudio over JACK so your high-end sound apps that actually use those high-end soundcard features work fine and your plain little desktop apps that just want to play an MP3 or a notification sound can also work perfectly.
Strawmen arguments only make it obvious you don’t know what you’re talking about. You seem to think that the entire software stack is made up of the “driver half” and the “application half.” If that’s the extent of your knowledge then I guess it’s easy to start using “flawed logic” to support claims like yours.
Truth is, software comes in _multiple_ layers, and some things belong in the middle layers. Things like sound buffering so that applications all using the same toolkit with the same Click sound don’t need to independently load the sound, decode it, keep it buffered in memory at all times, and stream it to the hardware at the proper rate and with proper buffering (which is hard) every time they play it.
That’s just like how X.org includes a Glyph cache shared between apps so text rendering is faster and uses less resources. PA lets applications share a common notification cache so simple toolkit sounds can be played more efficiently and with use less resources.
You are confused. Again.
One and only one thing has been moved into the kernel, and that’s the mode setting stuff, for which the soundcard equivalent has always been in kernel and certainly still is when using PulseAisio. The video memory manager work hasn’t “moved into” the kernel as that’s brand new and has never been a part of userspace either.
Nothing else is moving into the kernel. It’s just being shuffled around between the different userspace projects (from X to Mesa to Gallium3D, mostly).
Using someone’s innocent and non-serious joke as a personal attack is, unfortunately, not funny at all. Just makes you an ass.
Err… it’s GPLed for Linux, BSD-ed for BSD, and CDDLed for Solaris – isn’t this open source?
It’s not, really. There’s rather a lot of bits of it which, when you look at the headers, aren’t actually under any of those licenses.
This is also explained on 4front’s own licensing page: http://developer.opensound.com/opensource_oss/licensing.html
“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.”
This quotes sound like some drivers are not free software but the sound system is. Well we know that there aren’t as much drivers for OSS4 as for ALSA, just add those closed source drivers to the missing ones. One should port the ALSA drivers to OSS4 (I know, this might be a lot of work but maybe worth the effort, I dunno).
as others have pointed out, 4 front has released OSS4 under the GPL and CDDL licenses, dating june 2007
it’s true that some drivers could not be open sourced, though
it doesnt matter
if i was asked to design a system that can work in 100% cases, while eploiting HW features whenever present, and i’m only able to come out with something that works in 99.99% of cases without leveraging HW support for some features, i’d be fired
sometimes i think people in the FOSS world are lucky…
from a wider point of view, implementing HW mixing (or environmental audio for that matter) if supported by HW and hot plugging audio devices if they’re SB ones are orthogonal problems you know
this just adds to the argument that ALSA guys have not neen able to design something robust and flexible enough to accomodate ALL cases apart from common, lowest denominator ones…
problem is, if i believe a functional stack is broken by design, i may try to fix it – or more likely i’ll avoid touching it with a finger
surely the coupling of a sound daemon with yet another sound daemon is possible, but it’s more an abominable mating than an elegant solution
(making them coexist side by side accessing the same low level api’s is a bit more elegant, removing the need for sound daemons altogether would be best )
not that it’s so unfeasible given current SW technology : shared memory exists, LRPC / fastRPC too…
given shared memory, audio mixing could be done immediately before entering the kernel for IO, using the currently accumulated samples from the various active applications sharing the buffer (or bypassed to be left to the card, if the driver reports the capability)
the sample format could be negotiated once, then converted to the negotiated format before being mixed
then the kernel driver may keep track of whether control commands from some app have completed before switching to another app’s (via some sort of fencing)
you’ve said it right, i may have seemed to think that way
and since english is not my native language, i surely have failed at making myself clear
but trust me, after a decade and some (i’m 32) in SW design i know a bit better than what previously transpired
believe it or not, i perfectly know that…
BUT, if some (say, application) code wants to interact with a SW system providing some service; and can only do so via an API that that hides the system’s functionality away and cannot by bypassed; then from the point of view of the application code, it doesnt matter however layered, and inspired by what design concepts, the system beyond that API is – unless its implementation details transpire through the API, of course
this is a tenet of SW design, thus i think it’ s out of the question
then, what i meant for “driver layer” is whatever code lies in the path from the application to the target device besides the device layer’s driver proper (i’ve written these same words before, i was hoping to be clear…) because it’s intuitive that every element contributes to the behaviour of the stack beyond the audio API, as a whole
now, i really believe having a(nother) daemon mixing audio in userspace is a mistake, since it does something that even alsa alone IIRC was designed to do, introducing a round trip (and an additional serialization over sockets) for every transfer of audio samples, and further decoupling applications from the resource they share
moreover (although maybe i’m a little too obsessed with “optimizing with the local case”, as i’d gradly see the demise of Xorg also) network transparency is rarely to hardly needed in a single user desktop use case…
sound buffering is useful, but:
– imho possible events (and notifications) should be evaluated one by one to see which of them would likely be reused fo all applications, then to cache globally, vs which are used by only a subset of applications (e.g “incoming mail”) vs which are used for system events; then, caching “categorized” event sounds could be done at the application level, in a library instead of the server (more importantly, not the same server that handles the direct path), sharing across applications could be done and kept in a cross application shared buffer, but it’s just a possibility
– ANYWAY, i didn’t mention caching;
i despised the rationale for pulse audio to play notification sounds in stead of application events compete to, since IMO reacting to events would be the responsibility of another service belonging to another layer (the desktop shell, or an ad hoc notifier)
can you explain me how X.org glyph cache can help userland SW implementing text rendering internally ?
now that libraries toolkits are following the OGL compositing trend and gradually move away from server based font and primitive rendering, i think that kind of caching will have to be implemented at another level (as fragment shaders, maybe?)
more than moving i actually referred to the streamlining and consolidation process going on on the graphics stack ( that was an example anyway), as opposed to the layering and complication going on on the audio one…
i perfectly know about the state of mesa/gallium3d/DRI2/Xorg (and wayland + eagle btw), since i follow their development closely, thanks
guess i’m too depressed and have too low a sarcasm threshold these days to take innocent jokes for what they are… sorry about that
> it doesnt matter
> if i was asked to design a system that can work in
> 100% cases, while eploiting HW features whenever
> present, and i’m only able to come out with
> something that works in 99.99% of cases without
> leveraging HW support for some features, i’d be fired
> sometimes i think people in the FOSS world are
> lucky…
I guess you don’t work for Microsoft of Apple, numbnuts.
Because neither of those companies produce drivers or driver infrastructure that come remotely close to taking advantage of 99.99% of the hardware capabilities of modern audio cards.
In the case of Vista they completely dropped support for hardware acceleration of audio cards, and predictibly Creative flipped out on them and is currently trying to get people to use a different set of APIs called OpenAL in order to take advantage of their hardware.
In the case of OS X they only support a fraction of the hardware that is supported by either Windows or Linux.
And in both cases, in OS X and in Vista or XP you are forced to use a third party driver solution called ASIO if your trying to get professional results and want to do more then just record yourself and fart around with garageband. ASIO was originally created by a german professional audio company because the sound and driver model provided by default by XP and Windows 2000 sucked huge donkey balls and couldn’t come close to matching the performance requirements and mutlichannel recording features that many customers required.
Way to try hold ‘FLOSS’ programmers up to impossible, ignorant standards that nobody else comes close to matching.
> surely the coupling of a sound daemon with yet
> another sound daemon is possible, but it’s more an
> abominable mating than an elegant solution
> (making them coexist side by side accessing the same
> low level api’s is a bit more elegant, removing the
> need for sound daemons altogether would be
> best
I guess that is why nobody does that.
The needs and requirements for professional audio is so dramatically different from the needs for desktop use or home audio that it boggles the mind that a person could imagine that every person’s need would be solved by a single solution.
Ya. Come back to me when you design a system that can handle 16 input and output channels simultaniously while routing PCM audio from one application to another, be able to do all this dynamically, in real time, with low latency, configurable by the user on the fly.
Oh, and then add the ability to manage a half dozen Midi connections over USB, midi hardware, virual midi streams.. routing from audio markup programs to sofware syths, to hardware syths, routing notes and back from external controllers and between multiple digital audio workstations.
Then make that very easy for a normal person to understand and use, while getting acceptable performance on low-end machines as well as high-end, support dobly passthrough, and network audio for X terminal applications.
Oh and throw in network auto discovery of IP-based audio devices.
OMG UNLESS YOU CAN DO 100.0000000% OF THAT YOUR GOING TO GET FIRED!!!!!
To bad in Linux we need to have both PulseAudio and Jack avialable to end users to be able to do every single f-ng thing I just described…. and OSS can only do a fraction of it on it’s own.
OH the horror teh FLOSS Peoplez don’t know jack shit!!! Alsa SUXOR!!! They need two different solutions to two completely different audio-related problems!!!
—————————————–
Typically, in my experience, programmers don’t know jack shit about anything outside their selected, specific, expertise.
Which is usually going to be just the one part of the program they are tasked to work on.
That is to say programmers typically are ‘1 mile deep’ and ‘2 foot wide’. Very smart and very sharp, but unable to do simple things like, say, program a Apache server with 4 dozen virtual domains in under 20 minutes.. or know how make a Midi controller work with a software sythn in Linux. Just because it’s outside their specific field.
Edited 2009-04-17 08:09 UTC
you’re actually right on this, i don’t work for them, but i wish
i don’t think i have personally attacked you or anyone else here, by the way …
because apple and MS had other goals than targeting 100% of hardware, and the design resulted from this..
but i thought the linux community takes pride in not following apple and MS in their mistakes, if any, and moreover, that they want to take users away from apple and MS, proving they’re are able to build a superior product…
thus, design matters for foss also…
with Vista, they completely rewrote the audio stack to standardize the hardware and class driver architecture for audio devices under the UAA – the requirement there was to make the system more streamlined and then robust (so something had to be left out, and that has been the case with DirectSound3D acceleration as DS3D is now emulated), not to natively support everything under the sun
Apple sell hardware, they develop OSX not as a standalone product but as a complement for their hardware – of course they support a fraction of thr hardware that linux runs on…
what i had written is that, generally speaking, an individual paid developer cannot do whatever he wants and trick his employer into buying an incomplete solution for the task he’s been given – either he delivers code that fulfills all requirements within the task deadline, or he gets somehow penalized, or at worst, actually, fired
i knew about ASIO and steinberg, thank you 😉
besides being vague and using profanity, specifying that ASIO was born to maintain audio stream fidelity from sample to output, and achieve lower (and more importantly, less variant) latencies, than what was possible with the normal windows wave i/o or even directsound, wasnt much of an effort, was it?
ASIO predates windows 2000, btw…
what “ignorant standards” are you referring to?
those of good and pragmatic sw design?
i’m one of those who actualy believe that, as far as APIs OSs and drivers are concerned, this distrinction between desktop audio and professional audio is somwhat a fictitious one, and the result of current systems being developed to be “good enough”, but not better…
tackling a problem holistically and breaking it down to subproblems, solutions can be developed that are unified, comprehensive and scaleable
without kernel access it wouldnt be easy unless one actually introduces an audio server…
but with the ability to also design the kernel part of the stack (a privilege ALSA Deveelopers had), it’s not that hard
the important thing is to clearly identify the requirements of the whole system, and distinguish what’s to go from local processes or threads to local PCM devices (ac97, pci, usb ones connected to the local machine) from what sound shall go the other way around, or to a device on a different machine
having made this distinction beforehand, the rest comes forth, if we for example virtualize the local sound device at the channel level, connect applications to the audio channel via some “virtual mixer”, and envision a low level api to change the settings for each existing vmixer
on the fly rebinding would be possible, audio from applications connected to one channel would be mixed in the “descent” code path avoiding round trips
applications connected to an input channel would be woken up serially or (on multicores) in parallel to read the samples …
then someone may come scream “but i want networked sound too!”…
that is possible too, and will require a networked sound daemon indeed
but the important thing is understanding that local and remote sound are two entirely different things, and in the local case introducin a daemon is avoidable
MIDI is a different matter altogether from PCM samples, thus midi data shall go a different path
the midi synth (or in older terminology a midi expander) is an entity that converts commands to audio samples – for our purpose it is another user of the local audio API
maybe in the form of another process reading the midi in port in one thread and servicing local applications’ midi commands via RPC (possibly optimized for the local case without using sockets – there exist ways to do so)
if midi is enclosed in its own service it may become as flexible as it can be..
X graphics is generated remotely, then viewed locally (ie where the machine’s user is), and its usefulness is about controlling a remote machine;
network audio is along the lines of “generate locally, play thru remote speakers”, which is quite the opposite…
how useful would it be in a X remote session?
(playing a remote sound file on the local machine is another thing, and does not involve the sound server at all, btw)
sarcasm aside, if that actually was my job, actually maybe – so i’d do my best to produce a complete solution
but it isnt, so i don’t have to
OSS may not be perfect, but something like OSS4 would manage local devices, which for local desktop applications is more than enough, and does not require an auxiliary sound daemon
a daemon is then an option to achieve more flexibility, or for those application using the daemon’s native api, or for networked applications
it’s normal for people to behave that way, since developing code for different fields of applications requires different expertise, different knowledge, even different design approaches – and the human brain hasn’t got an unlimited information store capability
if you have to make a midi synthesizer you’ll have to know the basics of midi, the midi frame, the midi port, then maybe how to handle soundfonts – you cannot treat it as if it were a web server, you’ll most likely not even have to use sockets at all …
Nobody’s used ASIO on Macs since OS X 10.2 with the unbuggered Core Audio came out in August 2002. Until The Switch when they started using the same shit everyone else does Apple laptops wiped the floor with PC laptops for audio. Sub-2ms latencies and hardly a hint of noise.
There is such a thing as a unified audio API that can be used across the board, from system events to media playing to the low-latency, high-reliability needed for media creation. Apple has it. I’ve no idea why we don’t.
Ideology… as always…
When I used ubuntu Hardy and Ibex, I kept pulseaudio and it worked, but it never seemed ‘right’. Not sure if this sounds right, but it almost seemed like its own ‘program’ instead of being integrated into the OS. I had to do a bit of editing of the config files myself to get it to work.
I liked it when it worked
But I think more work should have been to integrate it properly. In a sense, it should be be treated more like a driver, and less of this separate entity.
For all those out there that have said they don’t know why PulseAudio exists, take a look at this page:
http://swik.net/GNOME/Planet+GNOME/Lennart+Poettering:+PulseAudio+F…
While it doesn’t answer all questions, I still found it an interesting read, even if he may be taking things a bit too personally.
from the linked page:
exactly what i was referring in my previous post,
he’s pretending X fi’s and other cards whose capabilities go far beyond stream mixing, don’t actually exist to date …
but the best part is in the “why pulse audio” paragraph:
now, anyone with a decent knowledge in OS design will immediately recognize things belonging to different logical layers, some to the appplication layer, some to lower ones
putting all that functionality in one place will create a flwaed design, and a modularization nightmare for future generation of programmers (like the current generation has has to take on the modularization the monolith previously known as Xfree86) – especially if one considers that:
a) from the point of view of an application that tries to play sounds through an audio device, the driver is not just the driver proper residing in the kernel, but whatever lies in the path from the application to the device
for all intents and purposes of audio I/O, pulse audio is part of the sound driver – now, why shall a component belonging the logical “lower half” of the critical path, implement a frivolous feature belonging to a user space application or service like playing notification sounds, is quite a flawed logic…
b) on the graphics stack, more and more functionality is moved and consolidated into the kernel, rather than the opposite (and graphic devices are hardly less complex than audio ones) – this is quite a lack of coherence
but the real gem is this:
normally, that would be hilarious
unfortunately, it comes from someone with the responsibility of pulseaudio’s author, thus is not funny at all…
I’m certainly not saying that PulseAudio is the end-all, be-all solution for audio on Linux, but at the same time, do you see anyone else making a serious effort to fix the problems that are in place or advance the Linux sound system in general? The kernel folk obviously have no interest in reintegrating OSS, and the small team working on ALSA obviously are not making the situation better… Is PulseAudio going to cause more problems in the long run? It’s possible, but at least someone is trying to move things forward with audio on Linux. What other solutions can you propose for moving Linux audio forward that will provide the kinds of features that PulseAudio is attempting to provide. Does OSS 4 provide these kinds of features? (really, I’m not being sarcastic, I don’t know)
All that is totally awesome, and I wish them the best of luck. The problem really isn’t with the Pulse Audio developers. I just wish the distros would have waited until PulseAudio actually worked before they tried shipping it.
Ah, but that’s desktop Linux for you… the users are the perpetual beta testers.
Much of the problems are found and fixed as more distributions adopt it. Waiting for software to get mature before including it doesn’t really work in that case.
If you want a really conservative distribution, you have your choices but asking for the latest software at the same time is problematic.
This is the problem with Linux development in general… instead of fixing the underlying architecture, let’s just pile another layer on top to hide the ugliness.
If there’s a problem with ALSA … then fix ALSA. Throwing more and more crap on top of a shaky foundation isn’t going to work, long-term.
Mixing is just out+=in*volume with an optative saturation control which is not needed in most cases, as volume goes 0.0 -> 1.0.
only 2 channels at once if stereo. SIMD is a little overkill for this task, specially if mixing is performed in kernel mode. Read also what i wrote, fixed point is still much faster doing cubic interpolation.
Who says so?
Applications that need to have their own volume (ie media players) ALREADY manage their own volume with a volume slider thatis presented to you and don’t need pulseaudio.
wtf? why is this even necessary? more of all.. why do you even want to listen to a sound when clicking?
what good does this do? besides driver providing this already, you need to adjust volume, you adjust it.
why? really.. why?
,
This is a non issue. most resampling ratios are not so big that you need a high quality resampler such as sinc, and if they are something is wrong with whathever you are doing. Also high quality resampling takes a lot of CPU. Usually it’s just something like mp3 in 44100hz being resampled to 48000hz.
network transparency is a good point, but that’s as much as a sound daemon should try to achieve.
yeah let’s reverb the whole desktop, funny!
no thank you
Most completely unnecesary. Desktop sound is not broken, no one complained, it doesn’t need “fixing” It is probably the only thing not broken right now. Pro audio in linux is completely broken, try opening sound in low latency to make music.. and pulseaudio makes this worse! I don’t mean really low latency like 5ms (for which you have to kill pulseaudio anyway and connect jackd directly to the audio device, so you see how broken it is), I mean 25ms latency which used to work fine with alsa, is now jerky with pulseaudio.. way to go!
Why again is all this necesary! if you are going to do VoIP you will pause the music anyway, it’s all BLOAT BLOAT BLOAT BLOAT. Pulseaudio has sold everyone BLOAT instead of fixing the real problems of linux audio. The Pulseaudio site makes it sound like you want to use our desktop like one of those 60’s holywood bat-computers that go bling beep blop to every action you do, when in reality as much you just want to listen to some music. They have a very twisted reality of what sound represents in an OS.
People can argue the technical merits of one sound system over another but all I know for sure is that ALSA always works for me and PulseAudio always gives me problems. I simply stick with what works. Right now, that’s not PulseAudio. Perhaps this update is better but I doubt it.
ALSA is a dead technology. While it was great in idea, and I loved the fact that many of my sound cards were supported, its a dead end. The ALSA devs will tell you that many of the sound card makers do not willingly give out the specs on their cards. Creative is the biggest culprit probably. So getting drivers for any of them is problematic. But thats not the catch.
Windows and OS X both use software to do much of the sound card work that used to be hardware based. And from Vista forward, hardware access from programs isnt even permitted. What that means in the long run is that most sound card makers will stop putting the hardware on their cards. Why? It makes the card cheaper and increases their profits while decreasing design and manufacturing costs.
So if Linux stays with ALSA or OSS4, pretty soon we will be up the creek. Pulseaudio really is the only way forward. Yes it sucks that it has issues. But don’t you think that if ALSA or OSS4 had a future, that at least one major distro would be behind them? The writing is clearly on the wall, and it is pulseaudio.
Actually, if some major Linux os were to adopt it, OSS 4 would have a future, unlike ALSA. OSS 4 has most of the needed software sound features that ALSA does not. Further, has anyone noticed that just about all of the commercial software for Linux that deals with audio in any way primarily uses OSS? Example: VMware. Even the latest version of VMware Workstation uses OSS for its output… and ALSA has been around how long now? Sadly though, I don’t see much of a future for OSS 4 as things stand now given that most of the community is dead set against it for ideological rather than technical reasons.
The only purpose ALSA is likely to serve several years from now is to be the very lowest interface to the audio hardware which, given how bad it is at the software features, is as it should be. Pulseaudio won’t drive the audio device directly, at least it doesn’t currently, so a minimal driver is needed even for the most minimal of cards. Of course, by then, they might all use the hda-intel or usbaudio drivers anyway.
.. are there attempt to reach feature with ALSA and/or OSS4.1 .. instead of just thinking that its all good, is there some sort of ACID3 type test for sound/audio devices? I mean the developer of OSS is looking for a job[1], why not bring him on board one of those companies like Canonical or Nokia .. if those companies were really to take a look at the Linux landscape and be honest .. there are just too many incompatibilities in the Audio Visual realm.
[1]http://4front-tech.com/hannublog/?p=23
There seems to be rather a lot of confusion going on in the second page, here.
One: Pulse doesn’t replace ALSA. Pulse is a sound server. That’s all it is and all it’s ever going to be. It’s doing stuff that ALSA doesn’t do, ALSA shouldn’t do, and ALSA has never intended or planned to do. ALSA provides a set of sound drivers and an output API. Pulse provides an output API, yes, so they overlap there, but that’s about all. In future fewer and fewer things will likely use the ALSA output API, but that doesn’t make ALSA obsolete, or anything. The main point of ALSA is that it provides the actual drivers that get sound through the card and out to your speakers. PulseAudio doesn’t do that and never is going to. There will always have to be a driver layer underneath Pulse, and it’s probably going to be ALSA.
Yep, though I think the name needs changed. ALSA (Advanced Linux Sound Architecture) is far from advanced at all. MLSA perhaps (minimal Linux Sound Architecture)… doesn’t quite have the same ring to it though, does it? It’s not advanced, it’s just hardware drivers and a low-level API to access them (ridiculously complex, but anyway…). You want an advanced audio system, have a look at OS X’s CoreAudio, or even parts of OSS 4. Heck, even Pulseaudio itself, though obviously without the driver layer.
It’s 2009, and I can’t believe that sound is still a problem in Linux.
It seemed fine to me for 2-3 years, then Ubuntu, and other Gnome distros, introduced Pulse Audio. After that, I’ve had lots of problems – like no sound upon installation (had to add my account and root account to Pulse group). After login sound, no Gnome sound after that. Sound freeze ups. Etc.
Prior to Pulse Audio, Ubuntu used the esound server, which always worked flawlessly for me. And prior to 8.10, I could uninstall Pulse, and install esound, and be happy. But now an attempt to uninstall Pulse causes Synaptic/apt to want to uninstall the entire Ubuntu desktop.
What a f&%$ing mess.
As a long time Linux user, I’ve become disillusioned. It seems distros take 1 step forward, then 2 steps back. Lately I’ve liked PCLinuxOS 2009.1 (even though it’s sound is a bit flakey) – everything works. But that distro has had an internal implosion after Texstar took time off, then came back, and other devs got pissed. So now it’s future is in question.
I guess it’s all natural byproducts of open source software.
The issue was that many distros shipped PulseAudio too early and some, like Ubuntu, completely messed up the implementation