[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