On 7/20/08, Mark Brown <broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx> 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 > 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? >>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 > > > 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. > 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. -- Jon Smirl jonsmirl@xxxxxxxxx _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
