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

[Takashi Iwai]

At Sun, 14 Jun 2015 01:03:42 +0200,
Robin Gareus wrote:
> 
> On 06/10/2015 06:24 AM, Adam Goode wrote:
> [..]
> > My guess is that the ALSA mixer settings are cached too soon, before
> > the device itself internally overwrites the settings from NVRAM. We
> > are either missing some invalidation event from the device itself, or
> > we don't do the right thing during initialization.
> 
> I didn't follow the whole discussion, so please excuse me if this was
> mentioned before:
> 
> I'm pretty sure that the NVRAM is restored on the Scarlet before the
> device shows up on USB: Save a config with Hi-Z on but configuring it as
> off in software. When connecting & re-powering the device, the indicator
> LED will blink on and then go off.
> 
> 
> It is not possible to read the full state from the device itself.
> Trying to read the value from the device results in garbage for the most
> part. The values must be set by ALSA and ALSA must remember the state.
> That worked in the original alsa mixer even across suspend/resume for
> the 18i6. Either something was changed or has been lost since.
> 
> This is also how the OSX and Windows drivers work for the Scarlett
> series. As soon as the device is [re]connected, software pushes the last
> known state (on that given machine) to the device. (At least it was that
> way ~2 years ago when I reverse engineered it).

OK, then the initial values seem missing.  The driver has already
cache in it, so the suspend/resume should work as is now.  The only
the initial values have to be set up explicitly.

> BTW the prop. driver saves state to the NVRAM quite often. I don't know
> if this is a marketing trick (intentionally wear it out quickly) or if
> it's OK to do that.

We have a control already in user-space (simple "alsactl restore"
should do), so there is no big merit to do it in the driver level,
IMO.


thanks,

Takashi