Headphone volume adjustment

[James Cameron]

On Thu, Aug 15, 2013 at 11:55:34PM +0100, Mark Brown wrote:
> On Sat, Jul 06, 2013 at 09:47:33AM +1000, James Cameron wrote:
> 
> > I wasn't directly involved at the time, but from memory of work by
> > Saadia and Mitch the audio did not work well until a major rework to
> > reduce the control set and routes (arm-3.5 7632883).
> 
> So, I've been meaning to e-mail you guys about this.  I noticed that
> you've gone very far away from mainline on the audio, partly due to some
> new featurs that haven't been upstreamed in the CPU but mostly with use
> case management in the CODEC driver.

Yes, afraid so.  Do or die.

> > The codec we are using has three digital "volume" controls pertinent
> > to this discussion:
> 
> > - the DAC,
> 
> > - the headphones,
> 
> > - the speaker amplifier.
> 
> > On XO-1.75 we preset the latter two and vary the first, calling the
> > first Master and exporting three controls to user space.
> 
> In general you want to use an analogue volume control for playback if
> you possibly can and keep the digital volumes at 0dB - this allows you
> to get the maixmum resolution from the DACs.  

Yes.  This is important when maximum volume resolution is desired and
other problems can be fixed.  It was the other problems that prevented
this for us.

> > I don't recall any design decision like that.  As far as I can tell we
> > ended up with a different control set and routes because the previous
> > control set and routes couldn't be made to work reliably with the new
> > kernel in the time available.
> 
> > (And now that I've begun to understand the complexity of this codec, I
> > can appreciate the problems that Saadia and Mitch had with it!)
> 
> I suspect it wasn't to do with kernel version churn...  in any case, the
> general goal upstream is to push the routing into the application layer
> partly to make it possible to figure out the complexity interactively
> (no kernel rebuilds to change settings) and partly to allow the same
> drivers to be used over multiple boards.

Yes, good goal for upstream.  No argument there.

> End users aren't supposed to see the configuration, the system sound
> server is supposed to do that - there's some work going on to improve
> this in PulseAudio at the minute and there's a standard set of helpers
> in alsa-lib (UCM) which should help implement this for anything
> else.

We certainly don't use PulseAudio, and probably don't use UCM.

Therefore the number and type of controls exposed to user space were
actually quite important to us.  We have had bad experiences with
controls being set by uncontrolled applications, being saved by
alsactl for next boot, and resulting in laptops in the field without
working audio.  For many weeks during development and board bringup
the default controls didn't get us sound, but developers with suitable
saved controls had no trouble.  This delayed us significantly, as test
results could not be reproduced.

> There's some work going on on this upstream for PulseAudio, it might be
> good to 

Your message ends abruptly at this point.

-- 
James Cameron
http://quozl.linux.org.au/