[alsa-devel] no period wakeup support
Hi,
Nowadays, is this reasonable to consider disabling the period wakeup as default instead of expecting period wakeup by default?
regards,
Nowadays, is this reasonable to consider disabling the period wakeup as default instead of expecting period wakeup by default?
I'd say yes - it's been nearly 10 years since this capability was added, and it's quite common across HDaudio, Chrome, Android plaforms.
But considering this as a default doesn't mean it's available in 100% of the cases, you still you need to check that
a) the driver is capable of disabling the period wakeup b) the driver is capable of providing a precise position outside of period elapsed events (usually marked with the INFO_BATCH capability).
alsa-lib gives you the means to query both cases.
Note that you also have the case where you cannot disable interrupts but can still use timer-based solutions (e.g. for USB audio).
Hope this helps -Pierre
On Wed, Jan 29, 2020 at 05:43:19PM -0600, Pierre-Louis Bossart wrote:
Note that you also have the case where you cannot disable interrupts but can still use timer-based solutions (e.g. for USB audio).
Oh, Ok. I'll probably stick to the classic model then.
thx for your time.
regards,
On Wed, Jan 29, 2020 at 05:43:19PM -0600, Pierre-Louis Bossart wrote:
Nowadays, is this reasonable to consider disabling the period wakeup as default instead of expecting period wakeup by default?
I'd say yes - it's been nearly 10 years since this capability was added, and it's quite common across HDaudio, Chrome, Android plaforms.
But considering this as a default doesn't mean it's available in 100% of the cases, you still you need to check that
a) the driver is capable of disabling the period wakeup b) the driver is capable of providing a precise position outside of period elapsed events (usually marked with the INFO_BATCH capability).
alsa-lib gives you the means to query both cases.
Note that you also have the case where you cannot disable interrupts but can still use timer-based solutions (e.g. for USB audio).
I suspect this advice.
In design of ALSA PCM core, runtime of PCM substream is configured for the mode of no-period-wakeup just in a case that userspace application requests it[1].
As long as developers take enough care of compatibility for existent applications, it's better to support period wakeup for each IRQ as a default, then support no-period-wakeup mode as an option.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/tree/sound/c...
Regards
Takashi Sakamoto
Dne 30. 01. 20 v 8:06 Takashi Sakamoto napsal(a):
On Wed, Jan 29, 2020 at 05:43:19PM -0600, Pierre-Louis Bossart wrote:
Nowadays, is this reasonable to consider disabling the period wakeup as default instead of expecting period wakeup by default?
I'd say yes - it's been nearly 10 years since this capability was added, and it's quite common across HDaudio, Chrome, Android plaforms.
But considering this as a default doesn't mean it's available in 100% of the cases, you still you need to check that
a) the driver is capable of disabling the period wakeup b) the driver is capable of providing a precise position outside of period elapsed events (usually marked with the INFO_BATCH capability).
alsa-lib gives you the means to query both cases.
Note that you also have the case where you cannot disable interrupts but can still use timer-based solutions (e.g. for USB audio).
I suspect this advice.
In design of ALSA PCM core, runtime of PCM substream is configured for the mode of no-period-wakeup just in a case that userspace application requests it[1].
As long as developers take enough care of compatibility for existent applications, it's better to support period wakeup for each IRQ as a default, then support no-period-wakeup mode as an option.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/tree/sound/c...
I agree. We should not break the basic part of the API.
Jaroslav
On 1/30/20 1:46 AM, Jaroslav Kysela wrote:
Dne 30. 01. 20 v 8:06 Takashi Sakamoto napsal(a):
On Wed, Jan 29, 2020 at 05:43:19PM -0600, Pierre-Louis Bossart wrote:
Nowadays, is this reasonable to consider disabling the period wakeup as default instead of expecting period wakeup by default?
I'd say yes - it's been nearly 10 years since this capability was added, and it's quite common across HDaudio, Chrome, Android plaforms.
But considering this as a default doesn't mean it's available in 100% of the cases, you still you need to check that
a) the driver is capable of disabling the period wakeup b) the driver is capable of providing a precise position outside of period elapsed events (usually marked with the INFO_BATCH capability).
alsa-lib gives you the means to query both cases.
Note that you also have the case where you cannot disable interrupts but can still use timer-based solutions (e.g. for USB audio).
I suspect this advice.
In design of ALSA PCM core, runtime of PCM substream is configured for the mode of no-period-wakeup just in a case that userspace application requests it[1].
As long as developers take enough care of compatibility for existent applications, it's better to support period wakeup for each IRQ as a default, then support no-period-wakeup mode as an option.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/tree/sound/c...
I agree. We should not break the basic part of the API.
I think you misunderstood my point. I was suggesting an approach similar to that of PulseAudio/CRAS/Android, where you first try and use the no-period-wakeup, and fallback to the traditional interrupt-based mode if it's not possible. The idea is that the no-period-wakeup should work now in a majority of the cases, so should be the primary mode recommended, not to deprecate or break the period-based solution.
On Thu, Jan 30, 2020 at 07:22:00AM -0600, Pierre-Louis Bossart wrote:
On 1/30/20 1:46 AM, Jaroslav Kysela wrote:
Dne 30. 01. 20 v 8:06 Takashi Sakamoto napsal(a):
On Wed, Jan 29, 2020 at 05:43:19PM -0600, Pierre-Louis Bossart wrote:
Nowadays, is this reasonable to consider disabling the period wakeup as default instead of expecting period wakeup by default?
I'd say yes - it's been nearly 10 years since this capability was added, and it's quite common across HDaudio, Chrome, Android plaforms.
But considering this as a default doesn't mean it's available in 100% of the cases, you still you need to check that
a) the driver is capable of disabling the period wakeup b) the driver is capable of providing a precise position outside of period elapsed events (usually marked with the INFO_BATCH capability).
alsa-lib gives you the means to query both cases.
Note that you also have the case where you cannot disable interrupts but can still use timer-based solutions (e.g. for USB audio).
I suspect this advice.
In design of ALSA PCM core, runtime of PCM substream is configured for the mode of no-period-wakeup just in a case that userspace application requests it[1].
As long as developers take enough care of compatibility for existent applications, it's better to support period wakeup for each IRQ as a default, then support no-period-wakeup mode as an option.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/tree/sound/c...
I agree. We should not break the basic part of the API.
I think you misunderstood my point. I was suggesting an approach similar to that of PulseAudio/CRAS/Android, where you first try and use the no-period-wakeup, and fallback to the traditional interrupt-based mode if it's not possible. The idea is that the no-period-wakeup should work now in a majority of the cases, so should be the primary mode recommended, not to deprecate or break the period-based solution.
Although I've expected your assumption on the above (of cource), I think it is not reasonable since it misleads people toward the localized solution with limited number of applications and purposes. It ignores actual design of ALSA PCM core even if it just satisfies the use cases in your and his work.
Regards
Takashi Sakamoto
participants (4)
-
Jaroslav Kysela -
Pierre-Louis Bossart -
sylvain.bertrand＠gmail.com -
Takashi Sakamoto