[alsa-devel] Scarlett 18i8 hardware out of sync with AlsaMixer

Chris J Arges chris.j.arges at canonical.com
Wed May 27 15:53:26 CEST 2015


On Wed, May 27, 2015 at 03:24:17PM +0200, Takashi Iwai wrote:
> [Added more people to Cc]
> 
> At Wed, 27 May 2015 08:55:21 -0400,
> Adam Goode wrote:
> > 
> > The settings were not reset across a mem sleep (echo mem > /sys/power/state).
> > 
> > Hard power off / power on does make the settings get out of sync.
>

Ok did some testing on my Scarlett 18i8:
 suspend/resume -> settings not reset
 poweroff/poweron -> settings not reset
 unplug/replug usb -> settings not reset
 powercycle unit -> settings not reset

Is there a more consistent method to trigger this issue?
In addition are you manually triggering 'alsactl restore/save' in this process?

I'll do some additional testing to see if I can trigger this.
 
> Then maybe the problem is that the device keeps the old setting while
> the driver resets to the default.  I vaguely remember that scarlett
> could save the default state in a persistent area, and the original
> driver patch had a kctl to trigger it.  We didn't take it because it
> might be dangerous.
> 
>

The original issue was this:
  Hey, as Tobias mentioned this is a HW saving (to the mixer's NVRAM)
  function used for using the mixer disconnected from a computer. We
  wouldn't want to continually write the NVRAM on every control update as
  I'm unsure of how many write-cycles the device is capable of.

So if we wrote to NVRAM on each control update we might wear out the memory
very quickly. I think this functionality is more for using the device
disconnected from a computer.
 
> Takashi
> 
> 
> > Adam
> > 
> > 
> > On Wed, May 27, 2015 at 2:43 AM, Takashi Iwai <tiwai at suse.de> wrote:
> > > At Tue, 26 May 2015 21:39:22 -0400,
> > > Adam Goode wrote:
> > >>
> > >> Linux 4.0.2-300.fc22.x86_64
> > >>
> > >> Hi,
> > >>
> > >> I have the Scarlett 18i8 USB device that is supported by the new
> > >> scarlett_mixer.c code. I am happy to say that the mixer code works in
> > >> most cases. But under some conditions, I cannot get any sound out of
> > >> the device until I go and toggle the "Matrix 01 Input" and "Matrix 02
> > >> Input" enums up and then down (from PCM 1 and PCM 2). This appears to
> > >> me to be some kind of cache invalidation bug, where the device is out
> > >> of sync with kernel mixer state.
> > >>
> > >> I will take a look at the code myself at some point, but not for a
> > >> while. But I am happy to try patches if anyone comes up with anything
> > >> in the mean time.
> > >

Does this change anything (untested)? And are non-enum settings affected?

diff --git a/sound/usb/mixer_scarlett.c b/sound/usb/mixer_scarlett.c
index 7438e7c..ad4a452 100644
--- a/sound/usb/mixer_scarlett.c
+++ b/sound/usb/mixer_scarlett.c
@@ -438,11 +438,9 @@ static int scarlett_ctl_enum_put(struct snd_kcontrol *kctl,
 
 	val = ucontrol->value.integer.value[0];
 	val = val + opt->start;
-	if (val != oval) {
-		snd_usb_set_cur_mix_value(elem, 0, 0, val);
-		return 1;
-	}
-	return 0;
+	/* always set cur mix value */
+	snd_usb_set_cur_mix_value(elem, 0, 0, val);
+	return 1;
 }
 
 static int scarlett_ctl_enum_resume(struct usb_mixer_elem_list *list)

--chris

> > > Does it happen after some S3/S4 or even during a normal operation
> > > without power-saving?  The USB-audio device supports autopm, so this
> > > needs to be checked, too.
> > >
> > >
> > > Takashi
> > 
> 


More information about the Alsa-devel mailing list