| Message ID | cover.1622974661.git.g@b4.vu (mailing list archive) |
|---|---|
| Headers | show |
| Series | ALSA: usb-audio: scarlett2: Read all configuration at init time | expand |
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
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/mixer_scarlett_gen2.c > > 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 > >
Hello all, if I may add to this; I agree with Daniel here. Geoffreys proposed changes are already a big improvement to the usability. They avoid a lot of confusion, especially for new users, caused by the hardware being out of sync with alsamixer; and also helping with identifying the changes that Windows did to the configuration from what I can tell. Additionally, it makes it easier to just adjust the current configuration after a reboot. Rather than having to either start from scratch or work from restoring an already stored configuration. Since I think it'd be an improvement for most users, I'd appreciate it if these changes could be integrated until a better solution is available. Best Regards, Markus On 07.06.21 17:12, Takashi Iwai wrote: > 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/mixer_scarlett_gen2.c >> >> 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 >>
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.