ALSA: scarlett2: Default on?

ALSA: scarlett2: Default on?

[Geoffrey D. Bennett]

On Wed, Jun 23, 2021 at 08:39:24AM +0200, Takashi Iwai wrote:
[...]
> OK, now all patches have been merged.

Thanks!

I would next like to consider how we can enable this mixer driver by
default. I originally added the device_setup=1 gate because there were
reports of the driver making the interface hang. These were all traced
back to the problem which was resolved with the commit "Fix device
hang with ehci-pci". That commit fixed the issue for those who had
reported it and since then there have been no more reports that the
mixer driver causes any issues.

Simply removing the device_setup=1 check would leave users with no way
to disable the driver in case that turns out to be necessary for some
reason though, so I don't think that's a good idea.

What I think would be the best option would be to have the driver as
its own loadable module. Does this sound like a good idea to you?

Thanks,
Geoffrey.

Re: ALSA: scarlett2: Default on?

[Takashi Iwai]

On Thu, 24 Jun 2021 17:47:39 +0200,
Geoffrey D. Bennett wrote:
> 
> On Wed, Jun 23, 2021 at 08:39:24AM +0200, Takashi Iwai wrote:
> [...]
> > OK, now all patches have been merged.
> 
> Thanks!
> 
> I would next like to consider how we can enable this mixer driver by
> default. I originally added the device_setup=1 gate because there were
> reports of the driver making the interface hang. These were all traced
> back to the problem which was resolved with the commit "Fix device
> hang with ehci-pci". That commit fixed the issue for those who had
> reported it and since then there have been no more reports that the
> mixer driver causes any issues.
> 
> Simply removing the device_setup=1 check would leave users with no way
> to disable the driver in case that turns out to be necessary for some
> reason though, so I don't think that's a good idea.

They can blacklist snd-usb-audio, either the module itself (if it's
the only device), or with enable option of snd-usb-audio module, if
there are multiple devices bound with the driver.

> What I think would be the best option would be to have the driver as
> its own loadable module. Does this sound like a good idea to you?

I'm not against splitting, but that is no solution at all, per se.


Takashi

Re: ALSA: scarlett2: Default on?

[Geoffrey D. Bennett]

On Thu, Jun 24, 2021 at 07:40:53PM +0200, Takashi Iwai wrote:
> On Thu, 24 Jun 2021 17:47:39 +0200,
> Geoffrey D. Bennett wrote:
> > 
> > On Wed, Jun 23, 2021 at 08:39:24AM +0200, Takashi Iwai wrote:
> > [...]
> > > OK, now all patches have been merged.
> > 
> > Thanks!
> > 
> > I would next like to consider how we can enable this mixer driver by
> > default. I originally added the device_setup=1 gate because there were
> > reports of the driver making the interface hang. These were all traced
> > back to the problem which was resolved with the commit "Fix device
> > hang with ehci-pci". That commit fixed the issue for those who had
> > reported it and since then there have been no more reports that the
> > mixer driver causes any issues.
> > 
> > Simply removing the device_setup=1 check would leave users with no way
> > to disable the driver in case that turns out to be necessary for some
> > reason though, so I don't think that's a good idea.
> 
> They can blacklist snd-usb-audio, either the module itself (if it's
> the only device), or with enable option of snd-usb-audio module, if
> there are multiple devices bound with the driver.

But wouldn't that disable audio for the device entirely? I am talking
about only disabling the mixer part of the driver (the code in
mixer_scarlett_gen2.c) which uses the proprietary USB messages. So
that if there is some unseen so-far bug the user can revert to
previous behaviour of audio working but no proprietary controls.

> > What I think would be the best option would be to have the driver as
> > its own loadable module. Does this sound like a good idea to you?
> 
> I'm not against splitting, but that is no solution at all, per se.
> 
> 
> Takashi

Re: ALSA: scarlett2: Default on?

[Takashi Iwai]

On Fri, 25 Jun 2021 04:11:42 +0200,
Geoffrey D. Bennett wrote:
> 
> On Thu, Jun 24, 2021 at 07:40:53PM +0200, Takashi Iwai wrote:
> > On Thu, 24 Jun 2021 17:47:39 +0200,
> > Geoffrey D. Bennett wrote:
> > > 
> > > On Wed, Jun 23, 2021 at 08:39:24AM +0200, Takashi Iwai wrote:
> > > [...]
> > > > OK, now all patches have been merged.
> > > 
> > > Thanks!
> > > 
> > > I would next like to consider how we can enable this mixer driver by
> > > default. I originally added the device_setup=1 gate because there were
> > > reports of the driver making the interface hang. These were all traced
> > > back to the problem which was resolved with the commit "Fix device
> > > hang with ehci-pci". That commit fixed the issue for those who had
> > > reported it and since then there have been no more reports that the
> > > mixer driver causes any issues.
> > > 
> > > Simply removing the device_setup=1 check would leave users with no way
> > > to disable the driver in case that turns out to be necessary for some
> > > reason though, so I don't think that's a good idea.
> > 
> > They can blacklist snd-usb-audio, either the module itself (if it's
> > the only device), or with enable option of snd-usb-audio module, if
> > there are multiple devices bound with the driver.
> 
> But wouldn't that disable audio for the device entirely? I am talking
> about only disabling the mixer part of the driver (the code in
> mixer_scarlett_gen2.c) which uses the proprietary USB messages. So
> that if there is some unseen so-far bug the user can revert to
> previous behaviour of audio working but no proprietary controls.

Even if you split the mixer part to a module, it'll be always bound
with the main snd-usb-audio due to dependency, so you cannot blacklist
it.  At most, you may add a module option for that, but it's almost
equivalent to introduce a new option to snd-usb-audio such as
  snd_usb_audio.scarlett2_mixer=off

A conditional build would make sense for the compilation size, but
it's not about the feature to turn on/off functionality on the fly.


Takashi