[alsa-devel] ASOC and 12 bit volume control
jonsmirl at gmail.com
Mon Jul 21 00:19:24 CEST 2008
On 7/20/08, Mark Brown <broonie at opensource.wolfsonmicro.com> wrote:
> 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
> > > > 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?
>>The chip supports DRC (compression and expansion), some of the DRC
>>parameters are 48bits in 25.23 format. Loudness is 25.23 too.
>>0x92 and 0x94 are examples of 64 bit registers.
Most registers are 5.23. About eight of them are 25.23. 5.23 fits in
4 bytes, 25.23 (48bits) needs 2 words, 8 bytes.
> > To support this chip you could add the concept of fields to ALSA
> > 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.
A better idea might be to expand the current 'shift' from 4 bits to 8
bits. And then allow masks for upto 64 bits. But this messes with the
current register interface since you would need to pass the value and
shift into the driver.
I have registers that are 256 bits. That's a 32 bit value with a shift of 224.
Another is 64 bits with a shift of zero.
The problem is encoding all of this into .private_value, it's too small.
I have to go read the control code since I don't know exactly how it
works. I haven't located any doc for it.
jonsmirl at gmail.com
More information about the Alsa-devel