[alsa-devel] ASOC and 12 bit volume control

Mark Brown broonie at opensource.wolfsonmicro.com
Sun Jul 20 23:49:37 CEST 2008


On Sun, Jul 20, 2008 at 03:51:20PM -0400, Jon Smirl wrote:

> > The issue is the time taken to do the I/O via the I2C bus, not the
> >  implementation in the chip - if anything I'd expect this to be slower
> >  than a direct hardware implementation but not perceptibly.  If
> >  applications try to step through all the values for a control with
> >  anything approaching the available resolution then that'd be a lot of
> >  data being written.  Like I say, it may not be a practical issue (I'd
> >  expect applications to be smarter) but it raised my eyebrows.

> Yes, stepping through 4096 volume levels individually would be a pain.
> A UI would need to initially move in larger increments.

> I have thought about building a pseudo interface for the chip that
> would be compatible with the existing ASLA controls, and then using an

I'd just ignore it initially and if it's a problem look at doing things
like deferring the register writes by a short amount.  Most UIs won't be
able to display anything like the resolution required to cause trouble
in the first place - they are scaling the resolution of the control into
the resolution of the UI anyway.

> IOCTL to bypass for finer control. But isn't this problem going to
> reoccur as we encounter more HD audio level hardware?

My own expectation would be that if it is a serious issue it'll be dealt
with in user space - my concern here was that the effects are being
magnified by the combination of the slow control bus and the large
registers that contain the controls.  As I say, it may not be a real
issue.

> > > 0x49-0x50, bass management
> >  > 4 bytes, contain 5.23 coefficients

...

> > OK, so the bass management looks like it should be able to fit in a
> >  processor word?

> If the word is 64 bits.

Err...  you said it's 4 bytes?

> To support this chip you could add the concept of fields to ALSA

ASoC?

> registers. Fields would be 32 bit. For backward compatibility the
> existing chips would just set field to 0.

The use of a shift plus mask is largely a function of the fact that that
maps well onto how datasheets are usually written - I'm not sure that
using numbered fields would help there.  I'm also not sure that it's a
good idea to build the 32 bit assumption in - someone is bound to come
up with controls that are either larger that or cross a 32 bit boundary
within a register.


More information about the Alsa-devel mailing list