[alsa-devel] no period wakeup support

[alsa-devel] no period wakeup support

[sylvain.bertrand]

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

Re: [alsa-devel] no period wakeup support

[Pierre-Louis Bossart]

> 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

Re: [alsa-devel] no period wakeup support

[sylvain.bertrand]

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

Re: [alsa-devel] no period wakeup support

[Takashi Sakamoto]

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

Re: [alsa-devel] no period wakeup support

[Jaroslav Kysela]

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

Re: [alsa-devel] no period wakeup support

[Pierre-Louis Bossart]

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

Re: [alsa-devel] no period wakeup support

[Takashi Sakamoto]

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