Weekly Edition
Return to the Announcements page
| |||||||||||||
|
| |||||||||||||
Linux audio explained (Techradar)
Techradar tries
to make sense of audio on Linux. "Linux's audio architecture is
more like the layers of the Earth's crust than the network model, with
lower levels occasionally erupting on to the surface, causing confusion and
distress, and upper layers moving to displace the underlying technology
that was originally hidden."
(Log in to post comments)
Linux audio explained (Techradar) Posted Apr 28, 2010 18:44 UTC (Wed) by tdz (guest, #58733) [Link]
Linux audio... cannot be explained.
I'd like something like an Xlib for sound. Some common API that you can program your application for. I guess that each of the major frameworks (GStreamer, PulseAudio, Jack) could serve this purpose; maybe with some little extra work.
Linux audio explained (Techradar) Posted Apr 28, 2010 19:32 UTC (Wed) by andfarm (subscriber, #61973) [Link]
Oh, there are plenty of those, at varying layers of abstraction. That's a big part of the problem!
Linux audio explained (Techradar) Posted Apr 28, 2010 19:59 UTC (Wed) by Kit (guest, #55925) [Link]
Linux's audio stack is slowly getting more and more sane and modern. GStreamer seems to be positioned rather well to become the defacto audio (multimedia) API on Linux for applications. The API is a bit on the scary side, but it seems to do what it does well, and scary APIs can always be made nicer by friendly high-level wrappers.
Sitting under GStreamer will be PulseAudio, which already does a fairly good job of doing software mixing and providing a non-crappy mixer (per-application volume control!) and software mixing.
And sitting at the bottom of the stack is still ALSA, which is fairly uninteresting these days.
The stack still requires more time for each of the layers to mature, and not all layers are completely appropriate for all use-cases (i.e. low-latency professional audio needs might not want to use PA), but hopefully with time this stack will be able to Just Work for most all users and use-cases.
Linux audio explained (Techradar) Posted Apr 29, 2010 0:00 UTC (Thu) by dmarti (subscriber, #11625) [Link] The API is not really that scary. After I wrote the "Linux audio: it's a mess" article I wrote a simple GStreamer-based application, which I do use daily. It's not that many lines of code to get GStreamer playing something for you, and once you do you can feed it anything from FLAC to C64 SID files. I've seen way worse APIs.
Linux audio explained (Techradar) Posted Apr 29, 2010 0:15 UTC (Thu) by leoc (subscriber, #39773) [Link]
Great name.
Linux audio explained (Techradar) Posted Apr 29, 2010 4:23 UTC (Thu) by drag (subscriber, #31333) [Link]
I am learning to like it more and more.
This command will take the audio output from pulseaudio and feed it into a Icecast2 server:
gst-launch pulsesrc device=alsa_output.pci-0000_01_09.0.iec958-stereo.monitor ! audioconvert ! lame vbr=4 vbr-mean-bitrate=256 ! xingmux ! shout2send password=hackme mount=pa.mp3
That way I can setup any sort of application to run on my desktop at home (rhythmbox, totem, mplayer, mpd, etc) and have it's output feed into a stream I can listen to on any computer or mobile device (like my phone) on the planet.
It's still not perfect.. I can't quite figure out how to make ogg work with it properly and the man files have examples on transcoding that don't work, but it's still not bad for the level of ignorance I have over transcoding and whatnot.
You can get 'devices' from pulseaudio by parsing 'pactl list' and looking for monitor.
You can get accurate information on each gstreamer module by using the 'gst-inspect' command.
Not too bad at all.
I even managed to get a Theora video streaming over Icecast2 by using the videotestscr test source. (still not up to the level of video transcoding yet)
Linux audio explained (Techradar) Posted Apr 29, 2010 0:48 UTC (Thu) by marcH (subscriber, #57642) [Link]
> Linux audio... cannot be explained.
But it often works eventually. Sound on Linux is seldom further than a few hours of Googling + throwing a few cryptic lines in some configuration files. Configuring X fonts on the other hand...
> I'd like something like an Xlib for sound.
Now you scared me!
Linux audio explained (Techradar) Posted Apr 29, 2010 18:38 UTC (Thu) by Spudd86 (subscriber, #51683) [Link]
Lennart Pottering (main pulseaudio developer) is (very slowly) working on libsydney which is supposed to provide a nice api for talking to audio systems, problem is pulseaudio is higher priority work so he doesn't have as much time for libsydney as he'd like and at the moment it's not really usable...
Linux audio explained (Techradar) Posted Apr 29, 2010 18:40 UTC (Thu) by Spudd86 (subscriber, #51683) [Link]
see here (also includes some info on why stuff sucks, note this is from 2007) http://0pointer.de/blog/projects/foms-lca-recap.html
Linux audio explained (Techradar) Posted Apr 30, 2010 14:56 UTC (Fri) by PO8 (guest, #41661) [Link]
Trust me. You don't want "an Xlib for" anything. Really.
Linux audio explained (Techradar) Posted Apr 28, 2010 18:56 UTC (Wed) by shalem (subscriber, #4062) [Link]
I made the mistake of reading this, this has to be one of the worst informed articles about Linux audio I've read in a long time. The author is incapable to differentiate between low level drivers like alsa, higher level audio services such as pulse and jack, and multimedia frameworks which happen to have a need to output sound such as gstreamer.
Long story short: don't bother reading this, you would be much better of reading one of Lennart Poetering's blog posts on Linux audio.
Linux audio explained (Techradar) Posted Apr 28, 2010 20:00 UTC (Wed) by branden (subscriber, #7029) [Link]
I get the feeling the writer came up with the metaphor first, and wrote the story around it.
It was a very funny turn of phrase, but good humor doesn't equal good journalism.
Linux audio explained (Techradar) Posted Apr 29, 2010 0:11 UTC (Thu) by marcH (subscriber, #57642) [Link]
> The author is incapable to differentiate between low level drivers like alsa, higher level audio services such as pulse and jack, and multimedia frameworks which happen to have a need to output sound such as gstreamer.
Yet strangely enough, this looks like a summary of the Techradar article.
Linux audio explained (Techradar) Posted Apr 28, 2010 21:03 UTC (Wed) by xorbe (subscriber, #3165) [Link]
Audio is one of those things that should "just work". The fact that there is even an article about it indicates failure.
Linux audio explained (Techradar) Posted Apr 28, 2010 21:10 UTC (Wed) by Trelane (guest, #56877) [Link]
"Audio is one of those things that should "just work"."
It does (in my experience) Just Work.
"The fact that there is even an article about it indicates failure."
Umm, that doesn't really follow (e.g. see the comments above yours)
Linux audio explained (Techradar) Posted Apr 28, 2010 21:47 UTC (Wed) by tialaramex (subscriber, #21167) [Link]
It only takes one or two broken applications for the old story about how Linux (the blame is always put on Linux, even if it also occurs on other Free Unix systems) can't get anything right because it's just a bunch of squabbling geeks all doing things their own way to re-surface.
People seem to have given up moaning about X cut and paste, presumably because they no longer have any software which gets that noticeably wrong (maybe the last GNU Emacs users finally bought Macs? Or five years after it was agreed that this bug would be fixed, someone actually wrote a patch to do it?)
But there are always audio problems, and it's always easier to shrug ones shoulders and blame some imaginary generic Linux problem than to look closely and say "Why is the right speaker cable unplugged?" or even to identify specific application bugs. For example, a whole series of mplayer builds mistakenly force the global PulseAudio volume to 100%. Would we be talking about how Apple's audio is hopelessly balkanised if the mplayer builds for OS X deafened people? No, of course Apple users would accept this was an mplayer bug.
As with all modern journalism the technique is: come up with a narrative, then collect facts and quotes to help tell the story. The "news story" has become the modern fairytale, and with just as little connection to reality as stories about talking bears and magic spells.
Linux audio explained (Techradar) Posted Apr 28, 2010 22:32 UTC (Wed) by cesarb (subscriber, #6266) [Link]
> For example, a whole series of mplayer builds mistakenly force the global PulseAudio volume to 100%.
Hint to those affected by this: put "ao = alsa,pulse," in your .mplayer/config. Yes, telling it to use alsa still makes it use pulseaudio, as long as your alsa sends output to pulseaudio by default - but for some reason mplayer does not overwrite your volume when using alsa.
Linux audio explained (Techradar) Posted Apr 29, 2010 17:48 UTC (Thu) by mezcalero (guest, #45103) [Link]
Alternatively, just update your mplayer.
Linux audio explained (Techradar) Posted Apr 28, 2010 22:42 UTC (Wed) by foom (subscriber, #14868) [Link] Once Linux audio stops completely changing every year, and there is a decent set of apps which aren't buggy, then users will automatically blame the app for a problem rather than the infrastructure.But linux audio has been such a mess for so long, it's really quite tempting to blame the infrastructure for every problem, without bothering to investigate further. And even in your mplayer example, it's still tempting to blame "Linux Audio": pulseaudio is yet another brand new thing, it's not incredibly surprising that mplayer got it wrong for a while. If they didn't have to add support for a new audio API every year, perhaps these kinds of bugs would be less likely to happen. I just hope that PulseAudio can be the last new audio API for linux. If so, everything will eventually be converted to properly use it, ALSA [as an application API], aRts, esd, jack, nas, and OSS [on linux] can all disappear (did I forget any other old sound APIs?), and all the mess will become lost in history... But then I run across things like RoarAudio and get sad.
Linux audio explained (Techradar) Posted Apr 29, 2010 6:21 UTC (Thu) by magnus (subscriber, #34778) [Link]
This was a very good comment, I agree completely. If PulseAudio keeps developing at the current pace it has a good chance of becoming the standard audio API for Linux.
It will probably take some time to get good application support, since the event-driven PA api is quite different from the ALSA/OSS ones. Took me quite some time to add support for it to mhwaveedit, even though I already supported most other API:s.
Jack will not disapper Posted Apr 29, 2010 7:47 UTC (Thu) by khim (guest, #9252) [Link]
Jack will survive for it's totally different beast (it's used on MacOS X too).
You can do amazing things with Jack but one badly written application can screw everything so it's not suitable for desktop.
Jack will not disapper Posted Apr 29, 2010 15:23 UTC (Thu) by drag (subscriber, #31333) [Link]
Yep yep.
Production Audio is VERY different from Desktop Audio.
Jack:
PulseAudio
And that sort of thing. PA would be extremely lousy if your using it for production audio work, while jack would be very hateful if your trying to use it on a laptop or your mobile phone for playing games and watching movies.
For people that want to be able to use Jack without giving up PA it's very possible to run PA on top of Jack so you can take advantage of familar desktop applications for sourcing audio while still getting the benefits of Jack. Something like this should do it as long as you have Jack started first (have not tested it myself):
# pulseaudio -L module-jack-sink -L module-jack-source
Jack will not disapper Posted Apr 29, 2010 15:57 UTC (Thu) by foom (subscriber, #14868) [Link]
Yet Apple has only one audio system that pro and desktop apps use. So it's clearly possible. Presumably since it's existed for so long, the PulseAudio and Jack developers both know about it. So I'm a bit mystified that people claim Linux absolutely truly needs two completely distinct audio stacks/APIs and just having one could never work.
The only thing you listed under "Jack:" that seems like a positive attribute is low latency. Is it impossible for PulseAudio to grow the ability to support configurable latency guarantees, so that a Pro app could request really-low-latency, and desktop apps could leave it at the default sensible-latency/glitch-free setting? (I really don't know)
Jack will not disapper Posted Apr 29, 2010 16:44 UTC (Thu) by drag (subscriber, #31333) [Link]
> Yet Apple has only one audio system that pro and desktop apps use. So it's clearly possible. Presumably since it's existed for so long, the PulseAudio and Jack developers both know about it. So I'm a bit mystified that people claim Linux absolutely truly needs two completely distinct audio stacks/APIs and just having one could never work.[/quote]
Yea.. It's certainly possible. But is it practical for Linux?
The advantage that Apple's CoreAudio had was that it threw out backwards compatibility and it took them from 10.0 to 10.2 to really get it to work out well. (a period of about 2-3 years)
With Linux you are dealing with a huge raft of different misdesigns and mistakes that have built up over the ages that were created by folks not truly understanding the issues involved. PA is designed to, at least, try to deal with all the collective problems in a positive manner. Jack just abandons all pretenses and focuses on a single goal: audio production.
It would certainly be nice to just have one system, but I think that there remains to much work to be done with desktop audio for the PA developers to start thinking about expanding to production audio.
Remember that while OS X has it's excellent 'CoreAudio' stuff Windows has far and away surpassed OS X in capabilities and popularity. Windows stuff is much more massively complex and weird then anything Linux uses... WaveRT, WavePort, WavePCI, WaveCyclic, UMDF, KMDF, WMD, WDF, VxD, DirectAudio, DirectX, Kmix, and a bunch of other stuff beyond that
> The only thing you listed under "Jack:" that seems like a positive attribute is low latency.
There are two huge big deals for Jack:
They sacrifice a LOT to get those things.
Jack will not disapper Posted Apr 29, 2010 16:48 UTC (Thu) by DOT (subscriber, #58786) [Link]
I'm no expert on JACK, but as far as I know, Apple doesn't provide a JACK-like infrastructure. To be able to use any audio app as input for another app, or synchronize sound streams between applications, you would need JACK on OSX, too. PulseAudio doesn't do these things either.
Jack will not disapper Posted Apr 29, 2010 23:33 UTC (Thu) by mezcalero (guest, #45103) [Link]
Well, CoreAudio is actually not the monolithicly well-designed block some people might think. It too has seperation between something that is more like GStreamer, and something that is more PA/ALSA, and it also has historical cruft. It is not the perfect example for a perfect API. They are marketing it better, and it is less redundant, and things come out of a single hand.
That said, they only have a single component doing the lower parts of both JACK and PA, where we have them seperate.
It is a valid opinion to say that ideally, PA and Jack would be one thing. Given the limited manpower I don't see that happening however. Also, I am not even concerned too much about this, given that pro audio and consumer audio are different on so many levels that a clear separation is not nonsensical, and also can have advantages over the unified design. (i.e. JACK on Linux can provide better latencies than CoreAudio)
So, given the manpower and that there is no really important reason to merge them I'd focus on cooperation between PA and JACK, not making one of them redundant. And in fact that's actually what we have been working on a bit. i.e. when JACK is started PA releases access to the audio device so that JACK can access it. And in a second step PA then becomes a client to jack like any other.
Finally, most people who ask for unification of both systems don't use and need JACK themselves. If you need JACK, then the use cases PA covers are mostly not relevant (you don't want event sounds intermixed with your new music recording, you don't want voip intermixed either, and rhythmbox neither). So I guess what I am saying is that having JACK and PA separate is OK. It's the least of our problems.
Jack will not disapper Posted Apr 29, 2010 17:55 UTC (Thu) by sorpigal (subscriber, #36106) [Link]
I do in fact use jack on my laptop for playing games and watching movies. I so far have seen no indication that it's "bad for desktop audio" -- I've heard this many times but until reading your post had never heard any justification. The "one bad app can crash the whole thing" part seems like a reasonable deficiency, but I still don't think it makes it unsuitable for desktop audio. There are several possible solutions to that which don't involve throwing out jack and reimplementing 90% of it in pulseaudio.
But, I have given up on agitating against reinventing this all over again. Whatever, guys! In the future I expect the standard Linux audio stack to be
PA->JACK->ALSA
And each app targets jack if it can, PA if it must and alsa if it absolutely has to.
Jack will not disapper Posted Apr 29, 2010 20:43 UTC (Thu) by Cyberax (subscriber, #52523) [Link]
Try to measure energy consumption. JACK makes it VERY noticeably worse.
Also, forcing PA through another layer is a bad idea. For example, PA automatically silences my game/audio player if I get a call through Skype.
If your game bypasses PA, then PA won't be able to do anything.
Linux audio explained (Techradar) Posted Apr 29, 2010 13:15 UTC (Thu) by nye (guest, #51576) [Link]
>Once Linux audio stops completely changing every year, and there is a decent set of apps which aren't buggy, then users will automatically blame the app for a problem rather than the infrastructure.
>But linux audio has been such a mess for so long, it's really quite tempting to blame the infrastructure for every problem, without bothering to investigate further.
Bah. Audio on Linux worked absolutely fine for me, without fail, without hassle, on every computer I tried, *for years* until PA came along like a tactical nuke and royally butt-fucked everything. There are not words to describe my hate for that PoS.
Linux audio explained (Techradar) Posted Apr 29, 2010 14:30 UTC (Thu) by waucka (subscriber, #63097) [Link]
Funny. Audio was a royal pain in the ass for me until PulseAudio came along (although I did have some minor trouble in the early days). These days, I install PulseAudio on all my machines that don't have it out of the box.
Linux audio explained (Techradar) Posted Apr 29, 2010 17:50 UTC (Thu) by Spudd86 (subscriber, #51683) [Link]
Err when was the last time you used pulse?
There is one major problem that pulseaudio can't solve, and that is old ALSA apps that try to do things that you cannot emulate with a virtual device. Thing is most of these apps are ALSO broken for a whole bunch of real hardware... and not just the stuff with userspace drivers (bluetooth), but for pretty much anything that's not hanging off a PCI bus with DMAable memory, and assume things about what ALSA tells them that is only true for some cards... and the kicker is they almost always don't need to use whatever feature it is that breaks on pulse, they're just poorly written (or use ALSA misfeatures that everybody involved now regrets adding). ALSA has a whole bunch of features that pretty much exactly two apps need, (pulseaudio and jack) and if you just want to get sound out you should avoid them since they will only cause you pain.
Go read Lennart Pottering's blog posts on this stuff, he explains quite clearly how most apps that don't work with pulseaudio are in fact broken anyway (but just happen to work for lots of people, but will still fall over for others)
All that said most apps these days work well with pulseaudio, with the exception of some older games.
Also if you have some oss using app there's a better solution than ALSA's oss emulation, ossp (http://sourceforge.net/projects/osspd/) it gives you a real kernel device via CUSE and should eventually support pretty much everything that a real oss device would, and it knows how to talk to pulseaudio directly rather than through the ALSA emulation layer.
Linux audio explained (Techradar) Posted Apr 29, 2010 19:40 UTC (Thu) by larryr (guest, #4030) [Link] Err when was the last time you used pulse? I have been using it every day with Ubuntu (8.04,8.10,9.04,9.10). There is one major problem that PulseAudio can't solve [...] I have no doubts about what problems PulseAudio can theoretically solve, but about what it actually does. [...] most apps that don't work with PulseAudio are in fact broken anyway (but just happen to work for lots of people, but will still fall over for others) [...] [...] most apps these days work well with PulseAudio, with the exception of some older games. My problems have not been with apps interfacing (directly) with PulseAudio, but with the PulseAudio implementation, especially its interfacing with ALSA, and handling multiple users, and with non-transparent non-discoverable (or just plain non-documented) configuration. It has seemed to me like eventually PulseAudio has to finally just work, but I have been thinking that for a couple years, which seems to me like an awful long time for such a critical application which does not have to do very much to at least work as a shim between the ALSA api and the ALSA drivers.
Linux audio explained (Techradar) Posted Apr 30, 2010 2:32 UTC (Fri) by Kit (guest, #55925) [Link]
>It has seemed to me like eventually PulseAudio has to finally just
>work, but I have been thinking that for a couple years, which seems >to me like an awful long time for such a critical application which >does not have to do very much to at least work as a shim between the >ALSA api and the ALSA drivers.
If PulseAudio didn't have to care about a bunch of old applications that misbehave using a deprecated API, it'd be a whole lot easier for it to Just Work, but the developers have to spend a huge amount of time trying to ensure all sorts of stupid corner cases will work fine and emulate a huge number of APIs.
Linux audio explained (Techradar) Posted Apr 29, 2010 17:53 UTC (Thu) by Spudd86 (subscriber, #51683) [Link]
also I suppose you're fine with flash opening your sound card for exclusive access all the time?
Linux audio explained (Techradar) Posted Apr 30, 2010 15:10 UTC (Fri) by PO8 (guest, #41661) [Link]
Beats Flash not being able to produce any
sound at all by a long shot. Which is one reason why I currently cannot use PulseAudio.
Linux audio explained (Techradar) Posted Apr 29, 2010 17:59 UTC (Thu) by mezcalero (guest, #45103) [Link]
Well, from my perspective things are mostly settled. The stack is ALSA+PA+GStreamer for consumer/mobile audio and ALSA+Jack for audio production. That has been that way since a year or two.
It certainly doesn't help if people keep mentioning systems almost everybody would agree are completely obsolete these days. ESD is dead. OSS is dead. arts is dead. NAS is dead.
Today, if you keep mentioning those systems, then it is clear that you want to throw fog grenades, because that's all those systems are useful for these days.
And then most other systems usually mentioned (SDL, Phonon, ...) are just APIs for the four systems pointed out above. Nothing a user should really have to deal with, if all bugs get fixed. They do not really offer anything their backends don't provide anyway, except a nicer or more suitable API for certain purposes.
I personally don't mention OSS, ESD, NAS or arts anymore. Those are battles long won. No need to keep them warm for constant repitition.
We have no problem of too many audio systems anymore (well, with the exception that having PA and JACK are still one too many, but that's something I certainly can live with). Now all that's missing is getting that into the heads of people so that the stop parroting OSS, ESD, NAS, arts, whenever somebody says "Linux Audio".
Linux audio explained (Techradar) Posted Apr 29, 2010 18:00 UTC (Thu) by mezcalero (guest, #45103) [Link]
Oh, and in case this is not clear, this is Lennart Poettering speaking, the guy who is to blame for PA. Yes, I am biased.
Linux audio explained (Techradar) Posted Apr 29, 2010 18:33 UTC (Thu) by foom (subscriber, #14868) [Link] Before PulseAudio, there absolutely was a problem of way too many sound servers/APIs/etc. Pulse is the only thing which has shown any real sign of actually taking over as the one dominant API/system, and for that, I give you hearty thanks.And I can see how from your POV you consider everything already solved, but it takes a few years for changes like this to percolate out through the whole environment. So, for many end-users like me, it's not solved yet. Not because of anything in PulseAudio itself, just time for everyone else to adapt, and those changes to actually make it into releases of the software, and the distro, and all that boring stuff.
Linux audio explained (Techradar) Posted Apr 30, 2010 13:37 UTC (Fri) by Trelane (guest, #56877) [Link]
(hey! Thanks for your hard work!)
Linux audio explained (Techradar) Posted Apr 29, 2010 21:57 UTC (Thu) by mezcalero (guest, #45103) [Link]
Well, I think the Linux audio landscape didn't change much in the least two years or so. Things have been consolidated and some of the missing parts have caught up.
PA is certainly not brand new anymore. It's so old it has been shipped on phones by three different manufacturers now.
Let me say that the future is bright. At this point in time I would not claim anymore that "Audio on Linux is a Mess". We are through the worst. I am quite positive on the how things have been going. Most battles have been fought. We now have counterparts for most subsystems the other OSes provide too. Yes, things are far from perfect, but at least GStreamer, PA and ALSA are the consumer techs everybody (well, there are always weirdos...) can agree on, and things are going in the right direction. I am happy.
And no, PA is not the last API. It's in many ways quite cumbersome (async, yadda yadda), and we will do something about that eventually. However, that will not be an abrupt change and should be irrelevant to users, and ideally unnoticable.
And JACK certainly can not disappear. People should stop mixing up pro audio and consumer audio, without really knowing what is going on. If you don't know what Jack is good for, then don't assume it is unneeded. It is needed, not for consumer audio, but for audio production. PA and Jack are not competing projects.
Linux audio explained (Techradar) Posted Apr 29, 2010 22:37 UTC (Thu) by foom (subscriber, #14868) [Link]
> PA and Jack are not competing projects.
Okay. I trust you. :)
But I hope you can see how I (and others...) might get confused, since most of the well-known media player apps have both PA and Jack (as well as ALSA and often many of the obsolete sound servers) as audio output choices in their home-grown audio-out abstraction layers.
Hopefully at least this is unnecessary?
Linux audio explained (Techradar) Posted May 5, 2010 22:29 UTC (Wed) by Cato (subscriber, #7643) [Link]
This is exactly right - stability and a single dominant API is required for Linux apps to make sound work correctly.
Linux audio explained (Techradar) Posted Apr 29, 2010 0:34 UTC (Thu) by marcH (subscriber, #57642) [Link]
> It only takes one or two broken applications for the old story about how Linux can't get anything right because it's just a bunch of squabbling geeks all doing things their own way to re-surface.
If applications did not need to constantly catch up with the framework of the day, maybe they would be broken less often.
> Would we be talking about how Apple's audio is hopelessly balkanised if the mplayer builds for OS X deafened people? No, of course Apple users would accept this was an mplayer bug.
On a Mac the demarcation line between Apple and third party software is usually obvious. I guess it's partly on purpose, for controlling reputation. And it seems to work from what you say.
(I guess most Mac users do not even know what mplayer is anyway)
Linux audio explained (Techradar) Posted Apr 29, 2010 6:25 UTC (Thu) by pabs (subscriber, #43278) [Link]
evolution gets cut & paste wrong.
Linux audio explained (Techradar) Posted Apr 29, 2010 3:40 UTC (Thu) by russell (subscriber, #10458) [Link]
Lucky you, in my experience 1 in 10 boots results in no audio at all. Requires a reboot to get it back. So where is the problem, who knows? Just too complicated to figure out.
Linux audio explained (Techradar) Posted Apr 29, 2010 14:19 UTC (Thu) by Trelane (guest, #56877) [Link]
Is this a box you bought with Linux pre-installed or supported? Or is it perhaps something like a DSDT bug?
Linux audio explained (Techradar) Posted Apr 29, 2010 9:22 UTC (Thu) by Cato (subscriber, #7643) [Link]
Sound on Linux very rarely "just works" - it frequently cuts out on my Ubuntu 8.04 box, and it took ages to get it working in the first place. It remains one of the most confusing and annoying parts of Linux for desktops and laptops.
This is partly due to the huge proliferation of sound components - if you read Linux user forums you'll see mention of Alsa, OSS, Pulseaudio, all proposed in different combinations and configurations for applications such as WINE, Skype, Flash, video playback, music players etc. This is before you even touch more advanced apps.
Linux audio explained (Techradar) Posted Apr 29, 2010 13:45 UTC (Thu) by pizza (subscriber, #46) [Link]
You do realize your "Ubuntu 8.04 box" is two years (and four releases) old, and that a lot has happened on the Linux front since then?
Linux audio explained (Techradar) Posted Apr 29, 2010 14:23 UTC (Thu) by Trelane (guest, #56877) [Link]
What, specifically, did you have to do to get it working?
Linux audio explained (Techradar) Posted Apr 29, 2010 16:56 UTC (Thu) by DOT (subscriber, #58786) [Link]
8.04 was infamous for a bad sound stack. 10.04 will be released today or tomorrow; maybe you'll have better luck this time around. From my experience with the 10.04 release candidate, I can tell you that Wine, Flash, video playback and music players work without glitches. I haven't tried Skype.
Linux audio explained (Techradar) Posted Apr 29, 2010 23:18 UTC (Thu) by jwb (guest, #15467) [Link]
So your problem with Linux audio is that three proprietary software stacks -- Windows, Skype, and Flash -- don't properly interface with the audio subsystem?
Linux audio explained (Techradar) Posted May 5, 2010 22:24 UTC (Wed) by Cato (subscriber, #7643) [Link]
WINE, Skype and Flash are just the most problematic - Amarok, Audacity, and Linux games have sound problems, too, but I genuinely need Flash video for courses and Skype for conferencing. Unfortunately, many of the best games are only on Windows, and only some of those are on WINE - the alternative is a PS3/Xbox360 console which is much more proprietary even than Windows.
Getting things like 5.1 sound working is just too painful to bother with compared to using Windows XP (9 years old) or Windows 7 - so Ubuntu 8.04 should really be able to do this on hardware that was well proven back in 2009 when I actually upgraded to 8.04... [However, Windows 7 does have major issues with recording and sound quality using the common Realtek chipsets on 2 different newly built/bought PCs, though that may be a driver issue. Also, since the Vista redesign of the sound stack, a lot of musicians are complaining about latency of 500 ms for recordings.]
I've been using Linux for over 10 years, and I have done things like compile a later version of ALSA, so I'm not using just the stock Ubuntu 8.04 stuff. ALSA itself works OK - a lot of the problem is the way the various apps use different APIs, and the sheer incomprehensibility of the items that appear in the GNOME volume control.
Generally I agree with the article - I shouldn't have to hunt down various Ubuntu HOWTOs just to get sound working. I even have an entire wiki page with 250 lines of notes on issues and workarounds, just on configuring sound...
I do have working sound on Ubuntu, and rely on it, but it's still flaky, despite building a box from scratch with supposedly supported Realtek hardware and lots of tinkering.
Linux audio explained (Techradar) Posted Apr 29, 2010 21:41 UTC (Thu) by mezcalero (guest, #45103) [Link]
Well, Audio is also one of those things that everybody uses, few understand, but nobody really makes money off. That means: lot's of complaining and little manpower.
And as long as this is the way this is, comments like yours are not helpful at all.
Linux audio explained (Techradar) Posted Apr 28, 2010 21:30 UTC (Wed) by rescbr (guest, #65719) [Link]
If Linux used OSS as any worthwhile *nix-like OS, we wouldn't have this insane audio architecture with billions of CPU-cycle and RAM eating wrappers, daemons and libraries.
Oh yes, OSS went closed source? Just do as the FreeBSD guys did: fork it.
Linux audio explained (Techradar) Posted Apr 28, 2010 22:36 UTC (Wed) by rqosa (guest, #24136) [Link] > If Linux used OSS as any worthwhile *nix-like OS Mac OS X doesn't use OSS either. > we wouldn't have this insane audio architecture with billions of CPU-cycle and RAM eating wrappers, daemons and libraries That's ridiculous. OSS can't take the place of multimedia frameworks (GStreamer, Xine, etc.). It can do software mixing of multiple streams (in more recent versions, at least, according to what I've read), so it can do that part of what PulseAudio / JACK can do; but ALSA can also do software mixing with dmix, and neither ALSA nor OSS can do everything that PulseAudio and JACK can do (and each one of JACK and PulseAudio can do some but not all of what the other one can do).
Linux audio explained (Techradar) Posted Apr 29, 2010 5:14 UTC (Thu) by drag (subscriber, #31333) [Link]
>> If Linux used OSS as any worthwhile *nix-like OS
> Mac OS X doesn't use OSS either.
Yes. The only people that use OSS are Solaris and the BSDs. Which are far far worse in terms of desktop or anything audio then Linux is.
If your aiming for portability you should not program in OSS or Alsa or anything. You program for SDL or Gstreamer or something like that that already supports Windows/OS X/FreeBSD/Solaris/Linux/etc.
>> we wouldn't have this insane audio architecture with billions of CPU-cycle and RAM eating wrappers, daemons and libraries
> That's ridiculous. OSS can't take the place of multimedia frameworks (GStreamer, Xine, etc.).
Yes. Thinking that everybody should only ever need OSS is on the same level as thinking that applications never need any sort of display management or widget software and that all application programmers should be perfectly happy to write applications that directly interact with the framebuffer on the video card.
Alsa can use DMIX, but 'Dmix' sucks. It's very poor in terms of capabilities and in sound quality.
Jackd can do a good job with software mixing, but it's developed for low-latency audio. Before anybody starts in on the Jack vs Pulse the #1 most important thing you must realize is that Desktop Audio is a completely different beast from Audio Production. Completely different. With Windows it's so different that folks from Germany had to create a entire new audio driver infrustructure and application APIs for audio production applications called ASIO. I'm of the opinion that having both Jack and PulseAudio is actually simpler then trying to make one API do both desktop audio and audio production. They are just that alien from one another. (But OS X's Core Audio stuff proves that it can be done)
As far as Pulse Audio being a 'CPU Hog'... Pulseaudio has been successfully used in both the Nokia N900 and Palm Pixie/Pre as well as probably other embedded-style devices. While these are fairly high-end ARM platforms it goes to show that when properly setup PA can exist on rather light hardware.
http://linuxplumbersconf.org/2009/slides/Jyri-Sarha-audio...
It is even possible to use PA to reduce battery usage, if everything is done right. It can buffer sound and write out to hardware in a optimized fashion that would be impossible for applications to get right.
Here are things that I do that are now routine for me that would be impossible to do in a sane manner without PA:
A few other fun stuff like that.
The transition to PA has been extremely painful, but that is only because Linux audio was such a total basket case before PA came along.
Linux audio explained (Techradar) Posted Apr 29, 2010 5:50 UTC (Thu) by trasz (guest, #45786) [Link]
Actually, when it comes to sound, FreeBSD has much better kernel infrastructure compared to Linux, and things like mixing, in-kernel resampling (useful for mixing, so all of the streams don't have to use exactly the same parameters), equalizer, independent volume control for each application, or the ability to enable bitperfect playback all "just work".
Linux audio explained (Techradar) Posted Apr 29, 2010 6:51 UTC (Thu) by drag (subscriber, #31333) [Link]
Well the 'in-kernel' stuff is a bit of a red herring, right?
My understanding is that the Linux devs are not going to allow that sort of stuff to go on inside the kernel. So for Linux that has to be done on userspace.
Dmix userspace Alsa vs Vchan kernelspace OSS, which is superior? All I know is that PA can do higher quality then Dmix and handles lots of situations were dmix and oss will fall flat on their faces.
> or the ability to enable bitperfect playback all "just work".
PA only does resampling/upmixing if it has to, I believe.
Linux audio explained (Techradar) Posted Apr 29, 2010 14:28 UTC (Thu) by trasz (guest, #45786) [Link]
The fact that it runs in the kernel is important, because it means it doesn't increase latency. As for quality - in FreeBSD, it's configurable:
hw.snd.feeder_rate_quality
0 Zero Order Hold, ZOH. Very fast, but with poor quality.
1 Linear interpolation. Fast, quality is subject to personal
2 Bandlimited SINC interpolator. Implements polyphase banking
3 Continuation of the bandlimited SINC interpolator, with 100dB
4 Continuation of the bandlimited SINC inteprolator, with 100dB
Full list of configurable stuff can be found, as usual in BSD, in the manual page (http://man.freebsd.org/sound).
As for the bitperfect switch - OSS too messes with sound only when it has to, but this switch gives you easy way to _make sure_ that it doesn't.
Linux audio explained (Techradar) Posted Apr 29, 2010 15:08 UTC (Thu) by drag (subscriber, #31333) [Link]
> The fact that it runs in the kernel is important, because it means it doesn't increase latency.
Yes it does. The difference from going from:
May mean that you avoid a extra context switch, but nothing is free. Latency matters all the way through the pipeline, not just from application to kernel drivers.
Linux audio explained (Techradar) Posted Apr 29, 2010 18:09 UTC (Thu) by Spudd86 (subscriber, #51683) [Link]
WRONG it still increases latency, because it's doing EXACTLY THE SAME THING as pulseaudio does. The only way to avoid adding latency is to NOT do software mixing, and for desktop audio that's not really an option.
pulseaudio doesn't add enough latency to matter for the purposes of desktop audio and it does a reasonable job of telling you what the latency actually is (when ALSA can tell it the internal latency added by the hardware, which it can't always do for various reasons, including hardware that actively lies about it)
If you care about latency either use ALSA directly and forget about software mixing or use jack. Same thing if you care about bit-perfect output (but because of hardware not being reliable in terms of what mixer levels correspond to 0dB good luck figuring out what to set them too)
Further all those sample rate conversion algorithms are available in pulseaudio (IIRC it uses libsamplerate from http://www.mega-nerd.com/SRC/ which has pretty much exactly the list you gave as options for rate conversion)
Linux audio explained (Techradar) Posted May 2, 2010 12:04 UTC (Sun) by tzafrir (subscriber, #11501) [Link]
libsamplerate, not libresample.
Linux audio explained (Techradar) Posted Apr 29, 2010 7:47 UTC (Thu) by rqosa (guest, #24136) [Link] It's not necessarily "better" to do mixing in the kernel instead of in userspace. The maintainers of Linux won't allow any floating-point operations in the kernel, because that would require a save/restore of FPU state on entering a system call and on returning from a system call, which has a performance cost. Incidentally, the original developer of of OSS (Hannu Savolainen) seems to have GPLed the current upstream OSS (OSSv4) now, so it's not the license that's keeping it out of Linux upstream anymore. Instead, it seems to be the issue of in-kernel mixing that's the problem (and maybe other problems too). According to Hannu's comment here (search for "OSS does this by" to find the comment), the mixing code runs with interrupts disabled and does its own save/restore of FPU state. That alone is probably sufficient to prevent it from getting merged into Linux upstream.
Linux audio explained (Techradar) Posted Apr 29, 2010 11:49 UTC (Thu) by cladisch (✭ supporter ✭, #50193) [Link]
The OSS author says on <http://4front-tech.com/hannublog/?p=36>:
> What I have been thinking about is pushing OSS back to the Linux kernel. However there are few things that need to be done before this could be possible: > > * Better integration with the Linux kernel. Currently OSS doesnt follow the design practices used by the rest of the Linux kernel. > * Power management. For the time being power management is missing from OSS. > * The audio core framework requires some rewriting. The current core is 10 years old and the recent additions like vmix dont fit properly in it. > * Some key drivers such as USB audio, HDaudio and SB X-Fi require rewriting. > > In addition the following enhancements or features have been suggested: > > * MIDI support.
Additionally, support for many other devices is missing, and there is very little compatibility with existing ALSA applications.
Linux audio explained (Techradar) Posted Apr 29, 2010 14:23 UTC (Thu) by trasz (guest, #45786) [Link]
The FreeBSD mixing and resampling doesn't use any floting-point operations at all; it's completely fixed-point.
The "running with interrupts disabled" thing seems to be Linux-specific; other systems don't have to disable interrupts to synchronise stuff (spin_lock_irqsave() et al), because they use modern approach to locking (real mutexes and interrupt threads). And the FreeBSD OSS implementation is independent from OSS from OpenSound.com, anyway.
Linux audio explained (Techradar) Posted Apr 29, 2010 15:01 UTC (Thu) by drag (subscriber, #31333) [Link]
> The FreeBSD mixing and resampling doesn't use any floting-point operations at all; it's completely fixed-point.
Yes... but floating point mixing is a desirable feature to have.
Linux audio explained (Techradar) Posted Apr 29, 2010 18:11 UTC (Thu) by Spudd86 (subscriber, #51683) [Link]
And how do they handle digital outputs that accept floating point audio?
Linux audio explained (Techradar) Posted Apr 29, 2010 18:12 UTC (Thu) by Spudd86 (subscriber, #51683) [Link]
Linux is pretty much moving away from running with interrupts disabled (aside from inside interrupt handlers).
Linux audio explained (Techradar) Posted Apr 29, 2010 22:07 UTC (Thu) by nwmcsween (subscriber, #62367) [Link]
The maintainers of Linux won't allow any floating-point operations in the kernel, because that would require a save/restore of FPU state on entering a system call and on returning from a system call...
Or you know we could drop ideas of kernel design from 1970's and have a verifiable language with vm enforced restrictions on unverified parts, thus everything running in ring0 /troll. Anyways this relates to audio and other things in Linux there are undoubtedly many things that can be improved on - it may not be great but it's somewhat good enough.
Linux audio explained (Techradar) Posted Apr 29, 2010 18:00 UTC (Thu) by Spudd86 (subscriber, #51683) [Link]
Problem with in kernel mixing is that it involves floating point math sometimes... and that's a major no no in Linux.
Also there's no real reason for mixing to be in the kernel (it would be nice to have some kernel support for emulation stuff so that pulseaudio can have better compatibility with broken ALSA apps but that's a separate issue)
Thing is once you stop viewing the buffer the app sees as some hardware DMA buffer that's going right out to the DAC there's no real advantage to putting it in the kernel (unless you don't have decent realtime support for userspace, but Linux does have that), and lots of reasons to put it in userspace (#1 userspace coding is easier than kernel coding)
Linux audio explained (Techradar) Posted Apr 29, 2010 7:55 UTC (Thu) by cannam (subscriber, #6467) [Link]
> The only people that use OSS are Solaris and the BSDs. Which are far far worse in terms of desktop or anything audio then Linux is.
OpenSolaris with OSS4 (but no PulseAudio) is pretty successful for general desktop audio.
Unfortunately, the OSS4-based subsystem was added after the last official release, and it's a concern whether at this rate we're ever going to see another one...
Chris
Linux audio explained (Techradar) Posted Apr 29, 2010 0:26 UTC (Thu) by literfizzer (guest, #31274) [Link]
Amen (to the insanity of userspace audio daemons, anyway). Audio works Just Fine on my Gentoo systems that use only ALSA. No PulseAudio (I sure don't need MORE volume sliders in my mixer), no gstreamer. (I tried to get gstreamer to play an audio file from the command line once. I couldn't believe how complicated such a simple thing was. I gave up and vowed not to waste my time with it again.)
I must be getting old. I really don't understand why people think this stuff is a good idea. (And yes, I have used PulseAudio: when it became the default in Fedora.) Simpler is better, to the point where things don't work.
Linux audio explained (Techradar) Posted Apr 29, 2010 2:48 UTC (Thu) by AndreE (subscriber, #60148) [Link]
What do the available userland tools have to do with the Gstreamer API?
It's like saying "DirectShow sucks because it's hard to play videos from the command line."
Yet another uninformed Gstreamer bashing
Linux audio explained (Techradar) Posted Apr 29, 2010 5:40 UTC (Thu) by literfizzer (guest, #31274) [Link]
> What do the available userland tools have to do with the Gstreamer API?
> > It's like saying "DirectShow sucks because it's hard to play videos from the command line."
I didn't say anything about the gstreamer API. I said it was way too hard to do a simple thing -- play an audio file from the command line.
> Yet another uninformed Gstreamer bashing
Yet another fanboy with poor reading comprehension.
Linux audio explained (Techradar) Posted Apr 29, 2010 8:13 UTC (Thu) by rqosa (guest, #24136) [Link] > I didn't say anything about the gstreamer API. No? You seemed to be criticizing GStreamer as a whole because there isn't an "mplayer-esque" command-line-driven frontend for GStreamer. The previous poster was just saying that you shouldn't blame GStreamer itself because there isn't a GStreamer-using application of the kind you want. Incidentally, did you see dmarti's post above? It links to a command-line-driven audio player program that uses GStreamer.
Linux audio explained (Techradar) Posted Apr 30, 2010 11:39 UTC (Fri) by AndreE (subscriber, #60148) [Link]
I don't want to drag this to mud-slinging level, but objectively I can say you don't really understand what GStreamer is all about. If you cannot distinguish between a framework or API and the the userland tools that utilises the API, well, there isn't much to discuss.
Now, if you were arguing about the difficulty in WRITING PROGRAMS using GStreamer, that would be something worth discussing
Linux audio explained (Techradar) Posted Apr 29, 2010 4:37 UTC (Thu) by rqosa (guest, #24136) [Link] > no gstreamer […] I really don't understand why people think this stuff is a good idea. Why? For the same reasons that Macintosh developers/users think that QuickTime is a good idea, or that Windows developers/users think that DirectShow is a good idea. Any program that can play encoded audio/video will need to read an audio/video stream from disk/network, demux it, decode the audio stream and/or video stream, send the decoded PCM audio to ALSA (or PulseAudio), and send the decoded video frames to the X server; there are lots of programs that need to play audio/video, so it makes sense to have a library which does all that stuff. That's what GStreamer is (and also what xine-lib is).
Linux audio explained (Techradar) Posted Apr 29, 2010 5:57 UTC (Thu) by literfizzer (guest, #31274) [Link]
Ok, I can see why it's a good idea to have one multimedia streaming library instead of each multimedia app reimplementing demux/decode/output. If I were going to write yet another media player, I suppose I'd give GStreamer a look. But I use mplayer and aqualung for all my video and audio needs, and neither requires GStreamer.
I could optionally build GStreamer support into OpenOffice and Pidgin, but they work just fine without it.
Linux audio explained (Techradar) Posted Apr 29, 2010 6:47 UTC (Thu) by rqosa (guest, #24136) [Link] Correct me if I'm wrong, but isn't it true that without GStreamer, Pidgin cannot use Jingle (voice/video conversations in XMPP)? And there are many more applications other than general-purpose media players which need to play media files. One example: games may store music and sounds as Vorbis audio files. Another example: HTML rendering engines that support the new "video" element in HTML5.
Linux audio explained (Techradar) Posted Apr 29, 2010 18:19 UTC (Thu) by Spudd86 (subscriber, #51683) [Link]
mozilla does their own thing for the video tag (they use libvorbis/libtheora/etc and don't support anything but ogg)
WebKitGTK (epiphany/midori/etc) uses gstreamer and will play anything that gstreamer has codecs/demuxers for
Linux audio explained (Techradar) Posted Apr 29, 2010 7:44 UTC (Thu) by nix (subscriber, #2304) [Link]
More volume sliders? PulseAudio gives you *fewer*. A total of three on my system; headphone, PCM, and front-audio. I mean, yes, there are per-app volumes as well, but you can completely ignore them except when you need them (when you want one app to play relatively louder than another).
Linux audio explained (Techradar) Posted Apr 29, 2010 9:33 UTC (Thu) by paulj (subscriber, #341) [Link]
Except when you adjust the volume in an app, thinking it'll adjust the master volume (as was the case for over a decade). You don't notice that it's adjusted an app specific volume until some /other/ app plays audio and you either can't hear it or it deafens you.
Further, pulseaudio tries to be clever and adjust the master volume *along* with per-app volume, in some clever way that varies according to the state of any other per-app volume. This means that sometimes PA gets it right, and sometimes it gets it wrong and the above happens. This makes it even harder for the user to figure out how they were *supposed* to use the volume controls. I find it way overcomplex, and I don't think PA will ever get this "apply AI to divine what the user intended" logic right. I think it will be always confusing.
I'd give anything to get back the long-standing "application volume slider controls master" behaviour I'm used to. The current behaviour is maddening.
I'm just 1 user, so my opinion counts little.
Linux audio explained (Techradar) Posted Apr 29, 2010 10:10 UTC (Thu) by iainn (guest, #64312) [Link]
I use:
echo "flat-volumes = no" >> ~/.pulse/daemon.conf
Granted, I don't think this brings the behaviour you want, but it does stop pulseaudio also changing the master volume when you change an application's volume.
Pulse's app specific volume used to be counter intuitive in another way. When I adjust Totem's volume from the pulseaudio volume control app, the volume *in* Totem, displayed by the Totem GUI, also changes. OK. But it used to be that when you did the opposite, adjust Totem's volume in Totem, the pulseaudio GUI didn't think Totem's volume had changed. Or was the problem vice versa? Anyway, that now seems fixed.
Linux audio explained (Techradar) Posted Apr 29, 2010 10:33 UTC (Thu) by paulj (subscriber, #341) [Link]
I would like to have per-app volumes controlled via the lesser-used, full-blown audio preferences thingy, to reflect the amount of times I want/need to adjust the volumes of apps /relative/ to each other.
When I've got the per-app volumes relative to each other configured just as I want them, I'm likely to want to leave them that way, nearly forever. 99.99/100 when I want to adjust volume, I want to adjust the /overall/ output volume. I can't be sure, but I suspect most users are like this too. PA volume controls as they stand are *extremely* confusing. It smacks of over-cleverness. I havn't figured out the model it's working to, through use; I couldn't explain the model to non-tech users even if they were willing to listen.
Don't get me wrong, PA is great. It makes incredibly useful auto-magic possible (see drag's post). However, the end-user volume-control model seems way over-complex (relying on AI) and/or overly twiddly.
It could of course be that applications are to blame. That they should be adjusting the PA master, rather than their own volume. But then something still went wrong in the recommendations that PA made to app writers for the transition, I suspect. (Not that I know..).
Linux audio explained (Techradar) Posted Apr 29, 2010 18:22 UTC (Thu) by Spudd86 (subscriber, #51683) [Link]
eh I think you just have a weird mental model for what the in app slider will do...
For me I've never seen it adjust the master, always the PCM... (probably has to do with your .asoundrc... but still I think the default behaviour is to adjust the PCM slider not master)
Linux audio explained (Techradar) Posted Apr 29, 2010 21:40 UTC (Thu) by paulj (subscriber, #341) [Link]
Before PA I think I was using ESD. As far as I remember it was master that generally got adjusted by GNOME apps. I could be wrong, maybe it was PCM. However that's not relevant to the point.
The point is that apps always used to adjust a *shared*, cross-app "master" volume prior to PA. (At least the GNOME apps I tend to use).
Linux audio explained (Techradar) Posted Apr 29, 2010 13:53 UTC (Thu) by Kit (guest, #55925) [Link]
>Except when you adjust the volume in an app, thinking it'll adjust
>the master volume (as was the case for over a decade). You don't >notice that it's adjusted an app specific volume until some /other/ >app plays audio and you either can't hear it or it deafens you.
IMO, this is a good thing. That is simply BAD application behavior! Random media applications should NOT be messing with the system-wide volume when a user tries to lower the volume inside the application.
If I'm watching a movie in mplayer, and the movie's audio is quite quiet (forcing me to raise mplayer's audio), I *do not* want to be deafened when I get a new message in Pidgin, all because mplayer assumes it's the only program running on the computer and raised the master volume to max, making the system notification much louder. Such behavior is quite indicative of a bygone era where it was safe to assume that only *one* sound could be played by a sound card at a time (something thats been false on every OS with a larger user base than Linux for at least 1 1/2 decades).
Linux audio explained (Techradar) Posted Apr 29, 2010 16:48 UTC (Thu) by paulj (subscriber, #341) [Link] IMO, this is a good thing. That is simply BAD application behavior! Random media applications should NOT be messing with the system-wide volume when a user tries to lower the volume inside the application.The problem is that the per-app volume also has plenty of bad cases, including "user gets deafened" scenarios. I don't know what the answer is, but for me, making the volume act on a per-app basis just *increases* the number of ways for volume to be misadjusted. E.g. in the per-app scenario, I could be deafened and *not know* which app volume I need to adjust! My only choice then is to adjust the master volume. There's probably no good answer, except AI and prescience. Till that becomes feasible, I would prefer just having one volume control to deal with (at least, in primary UI).
Linux audio explained (Techradar) Posted Apr 29, 2010 17:40 UTC (Thu) by drag (subscriber, #31333) [Link]
Ideally PulseAudio needs to be aware of the actual output volume of the device in DBs and then prevent the defaults of any application to exceed a certain limit without user intervention.
Trouble is that hardware does not provide generally reliable way to relay that information back to the operating system. Hardware will tell you volume in absolute terms, but it's frequently inaccurate.
Previously with just Alsa nothing in the system really attempted to figure out the actual output levels on the hardware and just defaulted everything to 0% or 75% volume.
The trouble with that is for each device '75% of max' can be very different actual volumes. For PCI devices it's probably only controlling the volume of a unamplified signal going out a jack... for other types of devices it may be actually controlling a amplifier.
PA is a improvement in that it tries to know what the actual output is going to be instead of just in terms of 'percentage of max'.
Probably the real solution is just to have a 'Max Volume' Slider that is able to gauge the actual power being outputted and combine that with individual application volume controls that operate within that constraint.
The only question I have is it better to have application volumes operate as percentages of the set Max Volume setting or is it better to have them be set as their own absolute 'real' output volumes?
Linux audio explained (Techradar) Posted Apr 29, 2010 18:25 UTC (Thu) by Spudd86 (subscriber, #51683) [Link]
then you still have problems with the levels that apps are actually outputting (go watch a bunch random youtube videos they will all have different levels...)
Linux audio explained (Techradar) Posted Apr 29, 2010 18:54 UTC (Thu) by drag (subscriber, #31333) [Link]
Here is a bit of sexiness I forgot about:
Dynamic Range Compression. Keep the volume at acceptable levels without blowing your eardrums out if somebody all of a sudden gets very loud and avoid clipping caused by maxing out digital amplifiers.
http://en.wikipedia.org/wiki/Dynamic_range_compression
Does PA impliment this yet? Is it a goal?
Linux audio explained (Techradar) Posted Apr 29, 2010 19:30 UTC (Thu) by johill (subscriber, #25196) [Link]
The audio chip Apple used to use long ago in powerbooks had this in _hardware_!
Linux audio explained (Techradar) Posted Apr 29, 2010 21:36 UTC (Thu) by paulj (subscriber, #341) [Link]
Applying limits in such a fashion might be useful, but it doesn't fix the problem that the /relative/ volume of different apps changes according to some complex model as and when you change the volume in various applications.
Also, dynamic compression doesn't fix the problem. Let's say I have 1 application that generates audio events (pings to indicate new mail, or whatever), and I want to have that at a relatively low-level (relative to the overall master volume I have selected), I may have other apps, like my audio, that I want at a higher relative volume. Dynamic range compression would just undo the benefits of per-app volume, if I understand your point correctly.
I'm happy with per-app volume. My problem is that at present it seems to need to continual adjustment. But I do NOT want to have be constantly be going backwards and forwards between different volume controls (i.e. between apps, or else into the detailed view of the gnome volume app) to have to re-adjust the relative volumes. However, this is what happens *today* with PA and the per-app volume controls. I can't even depend on my volume up/down hot-keys to act reliably on the master volume, cause it seems to get directed to whichever GNOME PA client app last had focus.
I'd be really really interested to hear someone explain the intended user experience of volume control, as experienced in GNOME+PA today. I just can't work it out. (Fedora 10 through to 12 today).
NB: I am not bashing PA. I am not bashing the hard work that Lennart and others (e.g. Sebastian Nocera, and others involved in GNOME media) have done. They're doing incredible work, and I'm very grateful for it. This is a small but irritating useability nit, by my perception at least, sitting on a mountain of good work.
Linux audio explained (Techradar) Posted Apr 29, 2010 22:53 UTC (Thu) by drag (subscriber, #31333) [Link]
> Also, dynamic compression doesn't fix the problem. Let's say I have 1 application that generates audio events (pings to indicate new mail, or whatever), and I want to have that at a relatively low-level (relative to the overall master volume I have selected), I may have other apps, like my audio, that I want at a higher relative volume. Dynamic range compression would just undo the benefits of per-app volume, if I understand your point correctly.
Not sure if you do or not. Dynamic Range Compression 'compresses' the volume so that you do not have it go beyond a certain point. It does not lower the volume of the output, it just smooths out the upper 'peaks' of the output so that it does not exceed a certain range.
Here is how it works in my imagination:
So on a scale from 1-10 were 10 is the loudest that your sound card can output you decide to set it at a '7' because that provides the best sound quality for your receiver/speakers. The so-called 'Best Stereo' setting you'd use to see on televisions. This is a absolute value designed to meet your comfort levels and quality of your hardware.
However most applications you want to be quieter so you typically set their relative volume settings at 75%. You only want to 'crank it up' to the full '7' output when you here a good song or something.
So lets say your listening to a VoIP conference call and a person is speaking too quietly on the phone so you turn the volume on that application to to 120% or even 150% to hear what he is saying properly. So that makes his voice louder so you can understand it properly.
Then all of a sudden somebody's annoying kid jumps on their parent and screams into the microphone because he thinks it's funny.
So that is when the DRC kicks-in.. it will prevent the volume from exceeding your set limit.. instead it 'compresses' the volume through a mixing filter so that it does not blow out your ear drums or blow your speakers or cause a lot of distortion and problems.
The loud scream would still be louder, but it will not increase to uncomfortable levels... instead it will only increase in relation to your master volume.
------------------------------------
So that is my proposed solution to the mixing problem.
That:
1. The Master Volume is for setting the maximum volume in all situations. It is unaffected by changes to application volumes.
2. The application volumes only adjust in terms of percentages relative to the master volume. And that the volume should allow a range of something like 1% to 200% to allow a high degree of adjustability.
3. DRC should be used to prevent sound clipping artifacts and ear blasting from occurring keeping the output as sharp and clear as possible.
4. There should be a 'autolevel' option (and probably slider) in the mixing utility to were PA will automatically adjust volumes for you so you can use all your different audio applications without having to micromanage your application volumes.
Of course this should only be a option, since while it would be very useful among many desktop situations it would not be good for any sort of 'artistic' expression in music or movies were quietness and loudness is important to your enjoyment of the audio track.
----------------------
> NB: I am not bashing PA. I am not bashing the hard work that Lennart and others (e.g. Sebastian Nocera, and others involved in GNOME media) have done. They're doing incredible work, and I'm very grateful for it. This is a small but irritating useability nit, by my perception at least, sitting on a mountain of good work.
I hear ya... Personally I don't like the audio mixer situation that much right now either.
It seems that if I have only one application playing then the application mixer adjusts the master mixer and visa versa... but when I have 2 applications open the behavior is very different. This is obviously wrong.
Also the other problem I have is that for some applications the volume can't get low enough. I like to listen to ambient-style music at work since it helps me concentrate... but it needs to be very quiet. If I try to set the volume to 'quiet enough I can hear it, but not be distracting' then the audio just goes mute. Instead of 'Loud', 'Medium'. 'Quiet' it only has Loud/Medium/Mute.
Linux audio explained (Techradar) Posted Apr 30, 2010 8:49 UTC (Fri) by paulj (subscriber, #341) [Link]
Well, DRC tends to imply that "quiet" passages are extended to sound louder - not that loud passages are quietened. The whole point of DRC in music was to allow quiet passages to make more full use of the range available in the media, I thought. I.e. though its called "compression" (because of what it does to deltas of peak range of different passages), it actually /extends/ the range of quiet passages. Traditionally..
However, you're arguing for a slight extension of the well-known music DRC. You're arguing that the volume be used to 'clip' the allowable range and then down-scale sounds over that? I can't tell how you intend to act on relative volumes. If you intend to preserve those, then aren't you describing normal mixing and amplification? If you don't intend to preserve relative volume, then it's not what I want.
To reiterate: I know what I want - something simple. E.g. the model that resembles the long-standing "independent sliders" that everyone is used to since at least the 60s. I want the primary visible UI control (be it in app or elsewhere) to control the master amp slider - the other sliders to be accessible via secondary controls.
But hey..
Linux audio explained (Techradar) Posted Apr 30, 2010 10:22 UTC (Fri) by paulj (subscriber, #341) [Link]
Ok.. Toying with PA very carefully, it seems one of my major volume problems - relative volumes being lost as you down/up master volume - has been fixed. PA now appears to be carefully preserving them, at least with a test with totem and banshee as clients. That works quite beautifully now (pulseaudio 0.9.21-5.fc12).
When did that get fixed? :) And was it PA or some driver reporting from the kernel? Even the GNOME volume media-key behaviour seems to be back to controlling just master volume.
Anyway, it seems my complaints were wrong or recently-ish obsoleted.
Thanks!
Linux audio explained (Techradar) Posted Apr 30, 2010 13:46 UTC (Fri) by Trelane (guest, #56877) [Link]
"So on a scale from 1-10 were 10 is the loudest that your sound card can output you decide to set it at a '7' because that provides the best sound quality for your receiver/speakers"
Why not just make a sound card that only goes to 7 if it's too quiet. Alternately, if it's too quiet, you could increase the maximum to, say, 11.
Linux audio explained (Techradar) Posted Apr 30, 2010 13:48 UTC (Fri) by Trelane (guest, #56877) [Link]
You know, in case you need that extra punch. ;)
Linux audio explained (Techradar) Posted Apr 30, 2010 8:57 UTC (Fri) by farnz (guest, #17727) [Link] Reading what you're saying, I can spot one nasty usability flaw; your volume keys should be driving master volume, not per-app volume. I would be surprised (as you seem to be) if I touched my volume keys, and a per-application level changed; it would be equivalent to me pushing the power button, and seeing just the application that has focus closing. Using PA in KDE, this is what I get - my volume keys drive master, and I have to set per-app volumes separately. Application internal volume controls (e.g. in Dragon Player) drive their own volume slider only. Even a real-world analogy doesn't work - the volume controls on my home cinema amp affect master unless I specifically go into the per-input volume control setting. Following on from that, per-application volume should be set either by using an application control, or by explicitly requesting a volume for a given app. I also dislike PA's habit of losing information (although not yet by enough to file a bug report, so this is just useless whining on my part). If it's raising master to allow for a raise in an application's volume above 100%, it should lower everything else to match; I'm struggling to work out how I'd design this to work intuitively (maybe hide the relationship between the PA sliders and the real sliders completely - so per-app volumes set the 0 dbFS level for each app, the master slider sets an adjustment applied to all the per-app volumes before you go to hardware, and PA adjusts the hardware sliders to use as much of the dynamic range as possible). DRC can also help avoid the deafness problem; the "ping" is a sudden ramp up from -infinity dB to 0dB and back down, and a good compressor will prevent it from getting anywhere near 0dB, by applying negative gain to the peak.
Linux audio explained (Techradar) Posted Apr 30, 2010 10:32 UTC (Fri) by paulj (subscriber, #341) [Link]
See my other post. It seems some recent change in F12 on my machine has made PA behave intuitively - master scales all the volumes according to their relative volume for me now. Volume hotkeys acting on master as I expect too (starting to wonder did I imagine that bug?). Yay!
Still not terribly fond of applications' volume control twiddling per-app volume. That's still causing PA to modify master, if master was set below 100% and you raise the per-app volume, so it's still losing the relative per-app settings when it does that.
That can be worked around/avoided somewhat now that volume hotkeys adjust only master again (it seems).
Linux audio explained (Techradar) Posted Apr 30, 2010 11:16 UTC (Fri) by farnz (guest, #17727) [Link] The usability flaw there is applications changing their own volume ending up tweaking master. Master should be under your control, setting a baseline "100%" volume point. As I said before, I'm struggling to design this in a way that works intuitively (which is no doubt why PA has this flaw). The more I think about it, though, the more I think master shouldn't be directly linked to hardware volume (this post is beginning to turn into the kernel of a reasonable bug report against PulseAudio). From my end-user perspective, I'm setting the relative volumes of a whole bunch of apps (effectively setting the 0 dbFS point for each app). I also set a master volume, which is my idea of what the "default" volume level should be. If an application level is set above 100%, the hardware volume needs increasing, but master should stay put; you set it so that things come out at about the right volume normally, but you've now boosted something to above normal (because it's quiet). I've now cost you useful functionality - you no longer have an obvious point to go to to see what the maximum sound level you'll hear is, as the per-app volume can now exceed master. You thus need either a "maximum" volume indicator; DRC comes in here, as you might well want a "limit" volume slider, with DRC in use to stop you exceeding the limit. The closer the combination of master and per-app volume is to the limt, the heavier the compression used.
Linux audio explained (Techradar) Posted May 2, 2010 22:20 UTC (Sun) by paulj (subscriber, #341) [Link]
Ok, PA is still losing information, such that if I lower the volume and later raise the volume again that some per-app volume is left really low and doesn't get raised as the master is raised. Then I have to go retwiddling my per-app volumes again.
It's just little niggle, but it's still annoying - particularly as I can't figure out what the problem is. :(
Linux audio explained (Techradar) Posted Apr 30, 2010 3:09 UTC (Fri) by Kit (guest, #55925) [Link]
>The problem is that the per-app volume also has plenty of
>bad cases, including "user gets deafened" scenarios.
Per-app volume has the *potential* for that (mostly from user mistake, based on misassumption), while there are many scenarios where lacking the per-app volume, deafening is the ONLY possible outcome.
Here's a real example I experienced many times in a bygone era:
How could I have prevented this situation *without* per-app volume? You can't ("disable other sounds" isn't a legitimate solution). With per-app volume control, I could have just raised the volume in my media player, leaving everything else *unchanged*.
Linux audio explained (Techradar) Posted Apr 30, 2010 6:01 UTC (Fri) by paulj (subscriber, #341) [Link]
Right.. I'm not arguing against the notion of there being per-app volumes - I *too* like being able to set different apps to different volumes (though: PA does not do persistence of volume setting for clients, afaict).
What I find bad for useability is having the primary volume *control* affect the per-app volume.
PA tries to do some kind of magic where it also adjusts the master and potentially also the per-app volume of other clients to hopefully do what you meant. My problem is that this magic does not follow any easy to understand model.
Often it doesn't do what I wanted (in particular, it does not maintain the relative volumes I've set). Further, I have no idea if I have used it incorrectly or if its magic simply is inadequate, cause the intended end-user model (if there is one) is sufficiently complex to be opaque to my understanding.
A simple UI model for me, for the *primary* volume control UI, would be either:
a) A shared master: Volume control adjustments affect all volumes equally, and do not change the per-app volumes relative to each other.
b) The per-app volume control: Volume control adjustments in an application affect the application's volume control alone. The main hot-keys and desktop master volume behaves as per a.
Basically, my mental model of volume controls is a series of independent sliders, where moving any 1 of them does not move any other. 1 of those sliders can be the master volume.
PA tries to do magic where adjusting one slider potentially can adjust other sliders. The problem is that this is *not reversible* - in particular it's losing information about the states of the per-app sliders relative to each other if I lower and then raise the volume...
Anyway. I find it baffling that I'm only the person baffled by how volume control now works in GNOME with PA! :)
Linux audio explained (Techradar) Posted Apr 29, 2010 14:54 UTC (Thu) by waucka (subscriber, #63097) [Link]
I understand the desire to stay with what you are accustomed to, but in my opinion, changing the volume in application X should *never* affect the volume in application Y. Why should it? If I want to change the system volume, I will use the volume control in my system tray. If I want to change the volume for one application, I will use the volume control in that application.
As for PulseAudio futzing with the master volume, that shouldn't cause any trouble if ALSA correctly reports amplification figures, which it unfortunately does not in many cases. It's one of those things that will improve with time, so have patience.
Linux audio explained (Techradar) Posted Apr 29, 2010 18:14 UTC (Thu) by Spudd86 (subscriber, #51683) [Link]
err how would you like to have ONE volume slider? 'cause that's what you get with pulseaudio (unless you care about the per app volumes, but they're separate and you don't have to care)
Linux audio explained (Techradar) Posted May 4, 2010 13:17 UTC (Tue) by daenzer (✭ supporter ✭, #7050) [Link]
> Amen (to the insanity of userspace audio daemons, anyway). Audio works Just Fine on my Gentoo systems that use only ALSA.
And no dmix plugin? Because that works via dedicated userspace audio mixing threads.
Linux audio explained (Techradar) Posted May 5, 2010 7:56 UTC (Wed) by cladisch (✭ supporter ✭, #50193) [Link]
> dmix [...] works via dedicated userspace audio mixing threads.
Actually, dmix works by mapping the sound card's DMA buffer into the memory space of all programs using it; the actual mixing is done by the library code called by this programs, without separate threads.
This is possibly only with a little bit of help from the kernel, which is why other userspace audio mixers have to use threads.
Linux audio explained (Techradar) Posted Apr 29, 2010 12:42 UTC (Thu) by dmaxwell (guest, #14010) [Link]
I seriously doubt that will happen as long as the OSS guys have this INSANE take on the GPL:
"OSS is gratis if you use it with GPLed applications under GPLed operating gystems. Its for a fee (you need to buy a commercial license from 4Front Technologies) if you use it in any other environment. This is all your rights. If you redistribute OSS you must give the recipient all the rights you have (recursively)."
http://4front-tech.com/hannublog/?p=8#comments
So basically he's saying that if I fire up a Loki game or a Windows app under Wine then I need to buy a commercial license from him. Even Stallman doesn't have such an expansive view of the GPL's scope. 4Front believes that a binary emitting data for their GPLed drivers to process must itself be GPL. I don't believe this would hold up in court but it is sufficient to keep me from using OSS because IMHO they're imposing additional conditions the GPL doesn't allow. So in absence of a commercial license from them, I don't believe ANYONE has a valid license to use OSS.
Linux audio explained (Techradar) Posted Apr 28, 2010 22:14 UTC (Wed) by wilreichert (subscriber, #17680) [Link]
The article made me think of this post:
http://blogs.adobe.com/penguin.swf/2007/05/welcome_to_the...
I was hoping for some conclusion at the end. Something like why having all these toolkits is hindering development or insight as to what could be done to resolve the problem. Still not sure I see the earth's crust metaphor in all of this.
Linux audio explained (Techradar) Posted Apr 29, 2010 8:00 UTC (Thu) by bni (guest, #27103) [Link]
Made me think of that article aswell.
Linux audio used to be a mess, but its fixed now. On my PC running Ubuntu everything just works. Several applications can play audio at the same time.
A couple of years ago applications would _hang_ when trying to use the audio device if it was already taken. Then all sounds would be queded up and played all at once very loud, when the audio hogging application exited.
It was pathetic.
Lennart Poettering should be knighted for pulse audio or something.
Linux audio explained (Techradar) Posted Apr 28, 2010 22:17 UTC (Wed) by armijn (subscriber, #3653) [Link]
Hm. Maybe they should visit the Linux Audio Conference, which is in a few days? http://lac.linuxaudio.org/2010/
Linux audio explained (Techradar) Posted Apr 29, 2010 0:16 UTC (Thu) by Trelane (guest, #56877) [Link]
But then that'd be *journalism*. ;)
Linux audio explained (Techradar) Posted Apr 29, 2010 0:37 UTC (Thu) by marcH (subscriber, #57642) [Link]
Like... something you have to actually pay for?
Linux audio explained (Techradar) Posted Apr 29, 2010 13:43 UTC (Thu) by bschindler (guest, #65754) [Link]
Well, sound does not really work here as it should and I can sort of feel the pain these people are complaining about...
My case: I have a logitech USB headset - I plug it in and it registers as an additional sound card.
In kde, I can select my output device and it will output to that (there are some bugs there, but it basically works)
The thing is - even though most technologies are there to make it just work, things are not yet fully developed to the point that it actually "just works"
Linux audio explained (Techradar) Posted Apr 29, 2010 14:35 UTC (Thu) by Trelane (guest, #56877) [Link]
In Ubuntu Lucid, what you want is accomplished as follows:
1) Click on the volume icon 2) Select "Sound Preferences" 3) Select the "Output" tab 4) Select your Logitech headphone "soundcard" in "Choose a device for sound output" 5) Optionally, do the same under the "Input" tab, if it has a microphone (Of course "output" in the above is now "input".
That *should* get you going.
HTH.
Linux audio explained (Techradar) Posted Apr 29, 2010 14:37 UTC (Thu) by Trelane (guest, #56877) [Link]
Also, this would be a nice situation to file a bug for. I'd expect that almost 100% of the time, if a user makes a new soundcard appear while running, it's the sound card the user wants to be using.
Also, certain types of sound cards (e.g. the one you describe above) probably should be preferentially chosen at startup.
Linux audio explained (Techradar) Posted Apr 29, 2010 14:47 UTC (Thu) by bschindler (guest, #65754) [Link]
Since I'm not running ubuntu - what exactly is the underlying effect of doing that? Does that do some management in pulseaudio, or does it directly manipulate alsa? If it does the former, it's no use as flash and mplayer directly use alsa per default...
Benjamin
Linux audio explained (Techradar) Posted Apr 29, 2010 16:11 UTC (Thu) by Trelane (guest, #56877) [Link]
I'm pretty sure it deals with pulseaudio.
"f it does the former, it's no use as flash and mplayer directly use alsa per default..."
Perhaps they should fix that then?
(Incidentally, I think more recent Flash plugins do use pulse. Indeed, 10 or later: https://wiki.ubuntu.com/PulseAudio)
Linux audio explained (Techradar) Posted Apr 29, 2010 18:29 UTC (Thu) by Spudd86 (subscriber, #51683) [Link]
It changes the pulseaudio default device, I'm not sure if it will also move any already playing streams or not... if it doesn't you can flip over to the 'Applications' tab and do it by hand
Linux audio explained (Techradar) Posted Apr 29, 2010 14:43 UTC (Thu) by rilder (guest, #59804) [Link]
Sound on linux has always been simple. I use OSSv4 works fine with respect to CPU usage (much lower than ALSA) and mixing (no problems with flash and mplayer playing at same time). Moreover, these feature work outside the box. Sound quality is also good in OSS. All applications support OSS (since it existed even before ALSA).
Other(not all) sound architectures are horrible wrt. CPU usage and mixing.
Linux audio explained (Techradar) Posted Apr 29, 2010 16:04 UTC (Thu) by jensend (guest, #1385) [Link]
To some extent it seems that things went awry when people decided that Linux should have its own low-level audio API. ALSA has some benefits, sure, but I can't help but think that if ALSA people had tried to sit down with those working on other unices and worked to bang out an API which everyone could sensibly replace OSSv3 with we'd be in a better position. Doing something cross-platform from the beginning often forces people to come up with a cleaner design, and I've certainly heard lots and lots of complaints about ALSA's design.
I still think this is part of the problem with current audio efforts- last I heard the non-Linux ports of PulseAudio were rather lacking and many of its developers couldn't care less (cf http://www.mail-archive.com/opensolaris-discuss@opensolar..., http://lwn.net/Articles/356013/).
Linux audio explained (Techradar) Posted Apr 29, 2010 17:59 UTC (Thu) by drag (subscriber, #31333) [Link]
OSS already had a improved API over what Linux offered.
OSSv3 was originally 'Free Software' and that was when Linux adopted it. However 4Front, the developers of OSS, when closed source when they updated the API and released improvements to existing drivers as closed source.
Meanwhile OSS, at the time, was not a good match for more modern sound cards. Alsa was developed originally just to provide support for the 'Gravis UltraSound Card', which had lots of features that OSS was not able to support (such as hardware MIDI support).
Alsa was introduced into the Linux kernel in 2002 and OSSv4 remained proprietary product until 2007.
Back in 2000 if you asked Solaris folks to help develop a improved API for Unix and Linux they would of just laughed at you and told you to use Mac or Windows like any sane or rational person should. And the BSD folks have no problems with having users pay for advanced features as long as the hardware has stable basic support in their particular *BSD flavor.
Linux audio explained (Techradar) Posted Apr 29, 2010 18:35 UTC (Thu) by Spudd86 (subscriber, #51683) [Link]
The reason for pulseaudio's somewhat lacking support off Linux is the Lennart is paid to make it work well on Linux and not on BSD/Windows so while he's happy to take patches to improve support for other systems he himself doesn't work on it, test it, or really care if breaks.
While pulse is probably something that would be nice to have on *BSD the only reason I can think of to use it on Windows is to provide an end point for a network stream... so a lot of the features are somewhat moot.
|
|
||||||||||||