From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: Scarlett 18i8 hardware out of sync with AlsaMixer Date: Fri, 19 Jun 2015 13:34:50 +0200 Message-ID: References: <20150527135325.GA12862@canonical.com> <557CB6CE.4090702@gareus.org> Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mx2.suse.de (cantor2.suse.de [195.135.220.15]) by alsa0.perex.cz (Postfix) with ESMTP id E5CC6260525 for ; Fri, 19 Jun 2015 13:34:50 +0200 (CEST) In-Reply-To: <557CB6CE.4090702@gareus.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: alsa-devel-bounces@alsa-project.org To: Robin Gareus Cc: Adam Goode , alsa-devel@alsa-project.org, Chris J Arges List-Id: alsa-devel@alsa-project.org 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