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.