Keeping the codec running at all times
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
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
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.
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
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
participants (3)
-
Jaroslav Kysela -
Pierre-Louis Bossart -
Ricard Wanderlof