* [alsa-devel] no period wakeup support @ 2020-01-29 23:23 sylvain.bertrand 2020-01-29 23:43 ` Pierre-Louis Bossart 0 siblings, 1 reply; 7+ messages in thread From: sylvain.bertrand @ 2020-01-29 23:23 UTC (permalink / raw) To: alsa-devel Hi, Nowadays, is this reasonable to consider disabling the period wakeup as default instead of expecting period wakeup by default? regards, -- Sylvain (sorry to post here, but sourceforge mailing lists are now using the google braindamaged javascript _only_ recaptcha) _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org https://mailman.alsa-project.org/mailman/listinfo/alsa-devel ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [alsa-devel] no period wakeup support 2020-01-29 23:23 [alsa-devel] no period wakeup support sylvain.bertrand @ 2020-01-29 23:43 ` Pierre-Louis Bossart 2020-01-30 1:20 ` sylvain.bertrand 2020-01-30 7:06 ` Takashi Sakamoto 0 siblings, 2 replies; 7+ messages in thread From: Pierre-Louis Bossart @ 2020-01-29 23:43 UTC (permalink / raw) To: sylvain.bertrand, alsa-devel > 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 _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org https://mailman.alsa-project.org/mailman/listinfo/alsa-devel ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [alsa-devel] no period wakeup support 2020-01-29 23:43 ` Pierre-Louis Bossart @ 2020-01-30 1:20 ` sylvain.bertrand 2020-01-30 7:06 ` Takashi Sakamoto 1 sibling, 0 replies; 7+ messages in thread From: sylvain.bertrand @ 2020-01-30 1:20 UTC (permalink / raw) To: Pierre-Louis Bossart; +Cc: alsa-devel 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, -- Sylvain _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org https://mailman.alsa-project.org/mailman/listinfo/alsa-devel ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [alsa-devel] no period wakeup support 2020-01-29 23:43 ` Pierre-Louis Bossart 2020-01-30 1:20 ` sylvain.bertrand @ 2020-01-30 7:06 ` Takashi Sakamoto 2020-01-30 7:46 ` Jaroslav Kysela 1 sibling, 1 reply; 7+ messages in thread From: Takashi Sakamoto @ 2020-01-30 7:06 UTC (permalink / raw) To: Pierre-Louis Bossart; +Cc: alsa-devel, sylvain.bertrand 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@alsa-project.org https://mailman.alsa-project.org/mailman/listinfo/alsa-devel ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [alsa-devel] no period wakeup support 2020-01-30 7:06 ` Takashi Sakamoto @ 2020-01-30 7:46 ` Jaroslav Kysela 2020-01-30 13:22 ` Pierre-Louis Bossart 0 siblings, 1 reply; 7+ messages in thread From: Jaroslav Kysela @ 2020-01-30 7:46 UTC (permalink / raw) To: Pierre-Louis Bossart, sylvain.bertrand, alsa-devel 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. Jaroslav -- Jaroslav Kysela <perex@perex.cz> Linux Sound Maintainer; ALSA Project; Red Hat, Inc. _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org https://mailman.alsa-project.org/mailman/listinfo/alsa-devel ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [alsa-devel] no period wakeup support 2020-01-30 7:46 ` Jaroslav Kysela @ 2020-01-30 13:22 ` Pierre-Louis Bossart 2020-01-30 23:56 ` Takashi Sakamoto 0 siblings, 1 reply; 7+ messages in thread From: Pierre-Louis Bossart @ 2020-01-30 13:22 UTC (permalink / raw) To: Jaroslav Kysela, sylvain.bertrand, alsa-devel 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. _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org https://mailman.alsa-project.org/mailman/listinfo/alsa-devel ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [alsa-devel] no period wakeup support 2020-01-30 13:22 ` Pierre-Louis Bossart @ 2020-01-30 23:56 ` Takashi Sakamoto 0 siblings, 0 replies; 7+ messages in thread From: Takashi Sakamoto @ 2020-01-30 23:56 UTC (permalink / raw) To: Pierre-Louis Bossart; +Cc: alsa-devel, sylvain.bertrand 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@alsa-project.org https://mailman.alsa-project.org/mailman/listinfo/alsa-devel ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2020-01-30 23:57 UTC | newest] Thread overview: 7+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2020-01-29 23:23 [alsa-devel] no period wakeup support sylvain.bertrand 2020-01-29 23:43 ` Pierre-Louis Bossart 2020-01-30 1:20 ` sylvain.bertrand 2020-01-30 7:06 ` Takashi Sakamoto 2020-01-30 7:46 ` Jaroslav Kysela 2020-01-30 13:22 ` Pierre-Louis Bossart 2020-01-30 23:56 ` Takashi Sakamoto
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.