Keeping the codec running at all times

Keeping the codec running at all times

[Ricard Wanderlof]

In certain system-on-chip systems, with separate ADCs and DACs for 
instance, the ADC could generate clocks for the DAC, where it not for the 
fact that ALSA shuts down whatever device is not being used in order to 
conserve power. Is it possible to instruct ALSA not to do this, i.e. once 
a codec has been configured to operate at a given sample rate, it will 
continue to do so, even after all streams have stopped.

I suppose one way to do this would be to change the codec set_bias_level() 
callback so that the BIAS_OFF and BIAS_STANDBY cases don't do anything but 
leave the codec running. But it doesn't sound like a clean way of doing 
this.

Of course, one complication is that at system startup, before any capture 
or playback operations have been attempted, ALSA doesn't know which sample 
rate should be configured, as there is no concept of a 'default sample 
rate'; the sample rate is always set when a stream is opened.

/Ricard
-- 
Ricard Wolf Wanderlof                           ricardw(at)axis.com
Axis Communications AB, Lund, Sweden            www.axis.com
Phone +46 46 272 2016                           Fax +46 46 13 61 30

Re: Keeping the codec running at all times

[Jaroslav Kysela]

Dne 06. 05. 20 v 17:15 Ricard Wanderlof napsal(a):
> 
> In certain system-on-chip systems, with separate ADCs and DACs for
> instance, the ADC could generate clocks for the DAC, where it not for the
> fact that ALSA shuts down whatever device is not being used in order to
> conserve power. Is it possible to instruct ALSA not to do this, i.e. once
> a codec has been configured to operate at a given sample rate, it will
> continue to do so, even after all streams have stopped.
> 
> I suppose one way to do this would be to change the codec set_bias_level()
> callback so that the BIAS_OFF and BIAS_STANDBY cases don't do anything but
> leave the codec running. But it doesn't sound like a clean way of doing
> this.
> 
> Of course, one complication is that at system startup, before any capture
> or playback operations have been attempted, ALSA doesn't know which sample
> rate should be configured, as there is no concept of a 'default sample
> rate'; the sample rate is always set when a stream is opened.

The driver may limit the available rates (thus it may be possible to set the 
one accepted rate via the module parameter or so which may be used for the 
codec initialization before an application uses the PCM device).

						Jaroslav

> 
> /Ricard
> 


-- 
Jaroslav Kysela <perex@perex.cz>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.

Re: Keeping the codec running at all times

[Pierre-Louis Bossart]

>> In certain system-on-chip systems, with separate ADCs and DACs for
>> instance, the ADC could generate clocks for the DAC, where it not for the
>> fact that ALSA shuts down whatever device is not being used in order to
>> conserve power. Is it possible to instruct ALSA not to do this, i.e. once
>> a codec has been configured to operate at a given sample rate, it will
>> continue to do so, even after all streams have stopped.
>>
>> I suppose one way to do this would be to change the codec 
>> set_bias_level()
>> callback so that the BIAS_OFF and BIAS_STANDBY cases don't do anything 
>> but
>> leave the codec running. But it doesn't sound like a clean way of doing
>> this.
>>
>> Of course, one complication is that at system startup, before any capture
>> or playback operations have been attempted, ALSA doesn't know which 
>> sample
>> rate should be configured, as there is no concept of a 'default sample
>> rate'; the sample rate is always set when a stream is opened.
> 
> The driver may limit the available rates (thus it may be possible to set 
> the one accepted rate via the module parameter or so which may be used 
> for the codec initialization before an application uses the PCM device).

It's a valid request, some platforms want to avoid any glitches due to 
clocks and require that they remain active, even if it means writing-off 
power optimizations.

If your codec exposes a clock object then you could have e.g. a board or 
machine driver configure the clock 
(clk_get/clk_set_rate/clk_prepare_enable) and leave it on regardless of 
the streaming usages. You would still need to make sure that the clock 
rates are compatible with the hw_params when streaming does happen.
that's what e.g. was done for Intel to make sure the MCLK, BCLK and 
FSYNC could be enabled even when the DSP was idle.

Re: Keeping the codec running at all times

[Ricard Wanderlof]

On Wed, 6 May 2020, Pierre-Louis Bossart wrote:

> >> In certain system-on-chip systems, with separate ADCs and DACs for
> >> instance, the ADC could generate clocks for the DAC, where it not for the
> >> fact that ALSA shuts down whatever device is not being used in order to
> >> conserve power. Is it possible to instruct ALSA not to do this, i.e. once
> >> a codec has been configured to operate at a given sample rate, it will
> >> continue to do so, even after all streams have stopped.
> >> ...

> It's a valid request, some platforms want to avoid any glitches due to
> clocks and require that they remain active, even if it means writing-off
> power optimizations.

Yes, if one looks at how standalone audio devices normally work, the codec 
is set up at power on time, and just keeps running until the device is 
switched off. Of course in that case, there is usually also some form of 
application that is also running all the time.

> If your codec exposes a clock object then you could have e.g. a board or
> machine driver configure the clock
> (clk_get/clk_set_rate/clk_prepare_enable) and leave it on regardless of
> the streaming usages. You would still need to make sure that the clock
> rates are compatible with the hw_params when streaming does happen.
> that's what e.g. was done for Intel to make sure the MCLK, BCLK and
> FSYNC could be enabled even when the DSP was idle.

Which driver is that?

/Ricard
-- 
Ricard Wolf Wanderlof                           ricardw(at)axis.com
Axis Communications AB, Lund, Sweden            www.axis.com
Phone +46 46 272 2016                           Fax +46 46 13 61 30

Re: Keeping the codec running at all times

[Pierre-Louis Bossart]

>> If your codec exposes a clock object then you could have e.g. a board or
>> machine driver configure the clock
>> (clk_get/clk_set_rate/clk_prepare_enable) and leave it on regardless of
>> the streaming usages. You would still need to make sure that the clock
>> rates are compatible with the hw_params when streaming does happen.
>> that's what e.g. was done for Intel to make sure the MCLK, BCLK and
>> FSYNC could be enabled even when the DSP was idle.
> 
> Which driver is that?

sound/soc/intel/skylake/skl-ssp-clk.c

and its users in

sound/soc/intel/boards/

kbl_rt5663_rt5514_max98927.c
kbl_rt5663_max98927.c

these examples are more to turn the clock on to meet codec requirements, 
but there were other cases that weren't upstreamed where the clocks were 
turned on at boot time as you described it.

The code is probably rather obscure but the idea itself holds water. As 
long as the clock is used the provider remains active - even if no 
streaming takes place.

Hope this helps
-Pierre