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