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.