[no subject]

I'm also a bit worried about being able to accurately represent
+0dB/unity (for bit-perfect passthrough), since ALSA uses 1/100th of a
dB as scale for the TLVs (I think?). x2 gain is +6.02(...) dB, but that
isn't enough significant digits to precisely map 0x8000 to 0dB:

>>> hex(int(0x10000 * (10**(-6.02 / 20))))
'0x8002'
>>> hex(int(0x10000 * (10**(-6.03 / 20))))
'0x7fdc'

So userspace that tries to use the TLV scale data to set "0dB" using the
simple API is unlikely to actually get precisely 0dB.

(This is also a problem for the output fader controls unrelated to the
matrix mixer, since they use the exact same scale encoding with inversion)

Maybe the driver should just use an arbitrary log dB TLV scale for the
controls and internally map to the hardware values? That means doing the
conversions internally and lying about precision at the lower end but at
least it would avoid rounding error when setting a gain to 0dB...

> 
>> OTOH, if you need more efficiency (e.g. the control access is way too
>> much overhead), it can be implemented freely via a hwdep device and
>> your own ioctls or mmaps, too.  But this is literally h/w dependent,
>> and the API becomes too specific, no other way than using own tool, as
>> a drawback.
> 
> [1] https://github.com/PhilippeBekaert/snd-hdspe/issues/13

There's one more thing I'd like to ask. Would it be useful for me to
submit just the streaming part of the device support upstream first
(which would work with the userspace app for config) and then worry
about designing the mixer control interface later? Or should it all be
done in one submission?

~~ Lina