On 08/29/2011 10:51 AM, Colin Guthrie wrote:
'Twas brillig, and David Henningsson at 29/08/11 08:04 did gyre and gimble:
On 08/26/2011 03:05 PM, Colin Guthrie wrote:
'Twas brillig, and Colin Guthrie at 25/08/11 17:17 did gyre and gimble:
'Twas brillig, and Arun Raghavan at 25/08/11 17:08 did gyre and gimble:
On Wed, 2011-08-24 at 22:58 +0100, Colin Guthrie wrote:
Hi,
This is a patch set that will likely mostly interest David, but also
solves one of the remaining niggles I have for 1.0 - the fact that
volumes are not set properly on port changes.
Now this only "solves" that niggle when the module-device-restore
is used,
but I'm happy enough to rely on that for now seeing as it's the
default
on 99.999% of desktop installs.
The overall benefit of this patch is that it allows different volumes
to be saved and restored for different ports. Combine this with
David's
work on making jack-detection work (which triggers port changes)
and you
automatically get different volumes on headphones vs. speakers.
My main concern is the following scenario:
0. Say we start with built-in speaker and headphone port and equal
(maybe 70%) volume
1. With headphones plugged in, I've got the volume turned up while
playing something that's naturally not very loud
2. I pull out headphones, start playing something that's quite loud, I
turn down the volume
3. I put the headphones back, find the output too loud (since the port
volume was turned up for the previous stream)
While the current scenario isn't ideal, it's easy for users to wrap
their head around (different devices have different loudness
levels). If
we don't handle this sort of case in the per-port-volume case, IMO the
behaviour is potentially confusing/frustrating to users.
Maybe there's a simple way to handle this that I'm missing ...
I'm not sure there is a way to handle this really. Either we want
volumes per-port or we don't. IMO we do (this is how it works on my
iPhone for example) and I think from the various mumblings I've heard
over the years most people want this type of functionality.
But perhaps there is indeed some magic solution that we are both
missing :p
Anyone else got any comments on this? I'd like to push it out if all is
well otherwise.
FWIW, to address Arun's concern somewhat, we could relatively easily
make a change here that kept the same volume for every port simply by
changing the key name used and then expose this as a module argument
should people really hate this behaviour.
Any comments on the code would be appreciated too :)
Well, I'm not that much into the database format, so can't really look
for bugs there...I have a question though: What about loudness bumps? It
looks like that could be the effect if you set the volume in such a
reactive fashion?
Well if you plug in a jack, you kinda expect the volume to change anyway
(it's a different physical thing outputting the sound.
Not really sure what you're meaning by loudness bumps in this respect.
Sure it's possible that the user configures things such that things get
too loud when they unplug things, but I'm not convinced there is a way
around that while still supporting independent volumes for headphones
vs. speakers.
Assume we have a card with one ALSA kcontrol named "Master" that
controls both headphone and speaker volume. User likes to have volume at
-6 dB with headphones and -24 dB with speakers. When user unplugs
headphones, he will have -6 dB in his speakers from the point when the
kernel does the automute stuff until we have synced the volume, i e a
"bump" in the volume. In that case, I'm not sure if there's anything we
could do about it.
But this also happens when you switch manually, in which case which
*could* do something about it. My point is that a port switch
essentially a change of ALSA kcontrols, and it seems like the proposed
implementation would do the change in two steps, first in reaction to
the port switch, then in reaction to module-device-restore. And there
should be possible to do it in one step only and set the right volume at
the same time as you set the port switch. Do you follow?
There could be some kind of heuristics applied - e.g. if there are some
active streams, perhaps we should ramp up the volume to it's previous
value over a couple seconds giving some time for the user to hit the
volume down buttons. That said, I'm not convinced this would really help
(and we've not yet got nice volume ramping anyway!).
Other methods such as erring on the side of caution and keeping the
volume low, but giving the user an option to restore the previous volume
via some UI feedback. But I don't think the infrastructure is quite
there yet (nor am I convinced this is a good idea generally).
Other thoughts on the issue are welcome tho'.
However - it might be that there is no true way around that anyway, as
in the case of jack detection as we're only reactive to what the kernel
does.
That's my gut feeling but I'd be happy to consider anything that makes
for a better user experience overall.
Col
--
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic
_______________________________________________
pulseaudio-discuss mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
