Headphone volume adjustment

[Mark Brown]

On Fri, Aug 16, 2013 at 10:07:34AM +1000, James Cameron wrote:
> On Fri, Aug 16, 2013 at 12:55:41AM +0100, Mark Brown wrote:

> > I guess the Fedora installs will?  You'd have to try not to.  In
> > general I'd recommend it for any use; it's really rather advanced in
> > terms of features (I've not seen anything else that has the
> > dynamically adjusted buffer sizes during playback) and does a great
> > job of simplifying the system setup down for the applications.

> Yes, we try not to.  I do not recall the technical arguments in full,
> Daniel would, but they included very limited processing power, very
> limited memory, it didn't work when we first tried it, and a suite of
> applications that use the ALSA controls directly that we would have to
> port.

Hrm, I suspect you'll find that either the processing power stuff is all
fixed or it's due to bugs in the DMA in the driver which will probably
get you sooner or later - worth checking out just in case, Pulse gets a
lot of stick for things that are actually driver issues, it ends up
being a really good test of the DMA implementation (some of the issues
I saw mentioned in the changelogs sound like they might've been an issue
for Pulse).  Even if you don't use it it might help validate the driver
layer.

The control based stuff may actually still work depending on how it's
done; applications still get to talk ALSA and if what they're doing is
stuff like volume management that's definitely still there.

> > Right, this is where not having use case management in your sound
> > server tends to cause trouble - if your userspace just uses whatever
> > happens to be lying around on the box and worse saves user settings
> > then things are going to go wrong.  To be honest I'm surprised that
> > there still aren't problems even with cutting down the number of
> > controls, so long as there's any configurability people are going to
> > be able to cause problems.

> We handle the remaining controls manually in a startup script to
> ensure their sanity.

Ah, so probably you could just use that anyway.  

One thing that tends to work well for that sort of setup is to remove
the alsactl save and restore from the init scripts and instead just save
specific control values - that way if you are tweaking things with
register twiddling in the kernel there's less interaction with userspace
possibly overriding settings and you know that for the script on startup
there's not going to be any settings that the user can tweak that you
forgot to override.  Unless you only have the save and restore it tends
to be a source of problems.

> > You're kind of not supposed to have working audio with the out of
> > the box setup, or at least you're supposed to just have the default
> > setup for the CODEC when tends to have everything off.

> Heh.

The reasoning for that being that you don't want to get into arguments
about what the default setup should be, especially with things that may
for example end up with speaker amps on headphone outputs.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.laptop.org/pipermail/devel/attachments/20130816/98a532ab/attachment.sig>