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/core/pcm_native.c#n715 Regards Takashi Sakamoto _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
