* Keeping the codec running at all times
@ 2020-05-06 15:15 Ricard Wanderlof
2020-05-06 15:40 ` Jaroslav Kysela
0 siblings, 1 reply; 5+ messages in thread
From: Ricard Wanderlof @ 2020-05-06 15:15 UTC (permalink / raw)
To: alsa-devel
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Keeping the codec running at all times
2020-05-06 15:15 Keeping the codec running at all times Ricard Wanderlof
@ 2020-05-06 15:40 ` Jaroslav Kysela
2020-05-06 16:12 ` Pierre-Louis Bossart
0 siblings, 1 reply; 5+ messages in thread
From: Jaroslav Kysela @ 2020-05-06 15:40 UTC (permalink / raw)
To: Ricard Wanderlof, alsa-devel
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Keeping the codec running at all times
2020-05-06 15:40 ` Jaroslav Kysela
@ 2020-05-06 16:12 ` Pierre-Louis Bossart
2020-05-07 16:28 ` Ricard Wanderlof
0 siblings, 1 reply; 5+ messages in thread
From: Pierre-Louis Bossart @ 2020-05-06 16:12 UTC (permalink / raw)
To: Jaroslav Kysela, Ricard Wanderlof, alsa-devel
>> 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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Keeping the codec running at all times
2020-05-06 16:12 ` Pierre-Louis Bossart
@ 2020-05-07 16:28 ` Ricard Wanderlof
2020-05-07 16:35 ` Pierre-Louis Bossart
0 siblings, 1 reply; 5+ messages in thread
From: Ricard Wanderlof @ 2020-05-07 16:28 UTC (permalink / raw)
To: Pierre-Louis Bossart; +Cc: alsa-devel
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Keeping the codec running at all times
2020-05-07 16:28 ` Ricard Wanderlof
@ 2020-05-07 16:35 ` Pierre-Louis Bossart
0 siblings, 0 replies; 5+ messages in thread
From: Pierre-Louis Bossart @ 2020-05-07 16:35 UTC (permalink / raw)
To: Ricard Wanderlof; +Cc: alsa-devel
>> 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
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2020-05-07 16:36 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-05-06 15:15 Keeping the codec running at all times Ricard Wanderlof
2020-05-06 15:40 ` Jaroslav Kysela
2020-05-06 16:12 ` Pierre-Louis Bossart
2020-05-07 16:28 ` Ricard Wanderlof
2020-05-07 16:35 ` Pierre-Louis Bossart
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.