On Mon, Jun 07, 2021 at 09:23:34AM +0200, Takashi Iwai wrote:
On Sun, 06 Jun 2021 16:16:44 +0200, Geoffrey D. Bennett wrote:
These two patches add support for reading the mixer volumes and mux configuration from the hardware when the driver is initialising.
Previously the ALSA volume controls were initialised to zero and the mux configuration set to a fixed default instead of being initialised to match the hardware state.
The ALSA controls for the Scarlett Gen 2 interfaces should now always be in sync with the hardware. Thanks to Vladimir Sadovnikov for figuring out how to do this.
Takashi, if these pass your review, I believe that they are appropriate for: #Cc: stable@vger.kernel.org
Well, in general, having a proper fixed value for the initial mixer value is the right thing, which is a part of the driver's role. Though, in snd-usb-audio, we don't set up the initial values just because of laziness; since the topology in USB audio is variable per device and often hard to parse correctly, it's difficult to determine the suitable initial values, hence we leave untouched. So, in that sense, setting the zero isn't wrong, rather safer, per se.
However, Scarlett 2 seems to want to be different; it has already some initialization code to read the existing configs. So this change sounds more or less acceptable. But it's questionable whether it's really for stable as a "fix".
For the Scarlett devices, the sensible (but not all good) initialisation options are:
1. Don't load configuration from hardware so the ALSA controls show default values not in sync with hardware. This is a bad user experience.
2. Reset hardware configuration to hard-coded defaults so ALSA controls will be in sync with hardware. This is a really bad user experience as it is common for the device to be configured using the proprietary vendor-supplied software and then connected to Linux with the expectation that the configuration is kept.
3. Load configuration from hardware so ALSA controls are in sync with hardware. This is a good user experience.
Before these two patches, it was option (1) for the mix/mux controls and option (3) for the remainder of the controls. I would call this definitely not sensible behaviour.
I got many queries as to the apparently strange workings of the driver due to this; certainly many users besides myself considered the original behaviour a bug so it does fit the rule "It must fix a real bug that bothers people" from Documentation/process/stable-kernel-rules.rst
You might consider that it does not meet the "It must be obviously correct and tested" rule though, and I could agree with that. Perhaps leave it out from stable for now and revisit later after we get more test results? Is there a particular amount of time or number of test success reports that you would consider sufficient?
In anyway, please fix the bug ktest bot spotted, the missing endian conversions and resubmit.
Thanks, I have resubmitted.
Regards, Geoffrey.