On Mon, 07 Jun 2021 17:00:10 +0200, Vladimir Sadovnikov wrote:
Hello!
I would like to say some words from my side.
The Scarlett device (especially 18i20) is pretty complicated device and holds a lot of settings in it's internal configuration area (hardware and software).
So this is not the only patch which will configure the driver in proper way. Since the device stores it's internal state (and that's good for power safety and mobility), ideally, we should get the almost fully compatible mixer settings with the original Focusrite Control Software.
The huge amount of job I've already done i my fork of Geoffrey's driver: https://github.com/sadko4u/focusrite-scarlett-backports/blob/master/prod-drv...
So we're planning to work on integrating our changes into the common patch sets and will submit changes here.
Sure, I don't mean against the patches, this looks like an acceptable approach. So don't worry, I'd take the patches once when the fixed version is submitted.
However, from the system design POV, all those configurations should be a software issue, and ideally we shouldn't rely on the hardware preset state which has been done *somehow* -- it may allow malfunction easily. One thing I've learned over years is that you can never trust hardware :)
Takashi
Best, Vladimir
07.06.2021 10:23, Takashi Iwai пишет:
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".
In anyway, please fix the bug ktest bot spotted, the missing endian conversions and resubmit.
thanks,
Takashi