Takashi Iwai wrote:
Benoît Thébaudeau wrote:
Benoît Thébaudeau wrote:
Clemens Ladisch wrote:
I'll see if I can cobble together some TLV checking code ...
Great.
In all the hardware examples that I've found, the worst case for holes is always, like for the BD37534: mute hole valid dB range hole
So it's perhaps not worth developing something very complicated in the kernel to handle all possible cases of TLV range holes.
Well, it's not only about the TLV dB information. The user-space has no idea where holes exist, and we have no way to expose this information, so far. That is, you can access to some random raw values and now you'll get always errors. This is obviously a bug of the driver.
So, please don't take it as an example to _fix_ the alsa-lib code. Making it working for such a buggy driver isn't called as a fix. It's called as a workaround. And, a workaround is usually ugly.
However, beyond that, there is a good advantage in your change; it can make the code more robust. We should concentrate on that point.
Yes. This is not what I meant here. Clemens seemed to be about to propose a generic solution in the kernel to handle hardware volume range holes so as to remove them when exposed to the user space. What I meant in my previous message was that his solution would probably be sufficient if it only handled one hole between the mute value and the other values, and another hole after the valid values. That would ease the development of drivers for these cases, and thus avoid buggy drivers in the first place.
Regards, Benoît