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