LWN: Comments on "Linux audio explained (Techradar)"

Linux audio explained (Techradar)

Cato — Wed, 05 May 2010 22:29:40 +0000

This is exactly right - stability and a single dominant API is required for Linux apps to make sound work correctly.

Linux audio explained (Techradar)

Cato — Wed, 05 May 2010 22:24:45 +0000

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)

cladisch — Wed, 05 May 2010 07:56:25 +0000

> 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.
Older versions of the ALSA library used threads to clean up after the last user has closed the device, but recent versions manage this without 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)

daenzer — Tue, 04 May 2010 13:17:47 +0000

> 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)

paulj — Sun, 02 May 2010 22:20:28 +0000

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)

tzafrir — Sun, 02 May 2010 12:04:19 +0000

libsamplerate, not libresample.

Linux audio explained (Techradar)

PO8 — Fri, 30 Apr 2010 15:10:00 +0000

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)

PO8 — Fri, 30 Apr 2010 14:56:14 +0000

Trust me. You don't want "an Xlib for" anything. Really.

Linux audio explained (Techradar)

Trelane — Fri, 30 Apr 2010 13:48:08 +0000

You know, in case you need that extra punch. ;)

Linux audio explained (Techradar)

Trelane — Fri, 30 Apr 2010 13:46:56 +0000

"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)

Trelane — Fri, 30 Apr 2010 13:37:05 +0000

(hey! Thanks for your hard work!)

Linux audio explained (Techradar)

AndreE — Fri, 30 Apr 2010 11:39:24 +0000

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)

farnz — Fri, 30 Apr 2010 11:16:55 +0000

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)

paulj — Fri, 30 Apr 2010 10:32:46 +0000

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)

paulj — Fri, 30 Apr 2010 10:22:41 +0000

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)

farnz — Fri, 30 Apr 2010 08:57:07 +0000

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)

paulj — Fri, 30 Apr 2010 08:49:30 +0000

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)

paulj — Fri, 30 Apr 2010 06:01:41 +0000

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)

Kit — Fri, 30 Apr 2010 03:09:52 +0000

>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:
I'm watching a movie in KMPlayer (which uses mplayer), and the volume in the movie is fairly soft... so I raise the volume so I can actually hear it. Then I get an Instant Message and Pidgin (GAIM, back then) makes a bleep that makes my ears ring (followed by about 10 more, due to the person sending me many messages at once). This has happened quite a LARGE number of times, and this wasn't the only situation where this would occur.

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)

Kit — Fri, 30 Apr 2010 02:32:00 +0000

>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.

Jack will not disapper

mezcalero — Thu, 29 Apr 2010 23:33:28 +0000

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.

Linux audio explained (Techradar)

jwb — Thu, 29 Apr 2010 23:18:53 +0000

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)

drag — Thu, 29 Apr 2010 22:53:28 +0000

> 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)

foom — Thu, 29 Apr 2010 22:37:54 +0000

> 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)

nwmcsween — Thu, 29 Apr 2010 22:07:42 +0000

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)

mezcalero — Thu, 29 Apr 2010 21:57:01 +0000

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)

mezcalero — Thu, 29 Apr 2010 21:41:54 +0000

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)

paulj — Thu, 29 Apr 2010 21:40:18 +0000

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)

paulj — Thu, 29 Apr 2010 21:36:56 +0000

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.

Jack will not disapper

Cyberax — Thu, 29 Apr 2010 20:43:18 +0000

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)

larryr — Thu, 29 Apr 2010 19:40:50 +0000

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)

johill — Thu, 29 Apr 2010 19:30:23 +0000

The audio chip Apple used to use long ago in powerbooks had this in _hardware_!

Linux audio explained (Techradar)

drag — Thu, 29 Apr 2010 18:54:59 +0000

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)

Spudd86 — Thu, 29 Apr 2010 18:40:05 +0000

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)

Spudd86 — Thu, 29 Apr 2010 18:38:26 +0000

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)

Spudd86 — Thu, 29 Apr 2010 18:35:41 +0000

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.

Linux audio explained (Techradar)

foom — Thu, 29 Apr 2010 18:33:22 +0000

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)

Spudd86 — Thu, 29 Apr 2010 18:29:27 +0000

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)

Spudd86 — Thu, 29 Apr 2010 18:25:29 +0000

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)

Spudd86 — Thu, 29 Apr 2010 18:22:41 +0000

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)