From: Takashi Sakamoto <o-takashi@sakamocchi.jp>
To: "S.j. Wang" <shengjiu.wang@nxp.com>
Cc: alsa-devel@alsa-project.org
Subject: Re: [PATCH] aplay: support no period wakeup option in argument
Date: Thu, 27 Dec 2018 20:58:01 +0900 [thread overview]
Message-ID: <20181227115801.GA15692@workstation> (raw)
In-Reply-To: <AM0PR0402MB3379A907F2E41F7DC17A1E5AE3B60@AM0PR0402MB3379.eurprd04.prod.outlook.com>
Hi,
On Thu, Dec 27, 2018 at 06:46:57AM +0000, S.j. Wang wrote:
> I still have two questions:
> 1. It seems the no-period-wakeup feature should be dropped for it isn't recommended
> By alsa, right? I still found some driver in kernel support it, what's the reason?
You can see the driver supports 'period-wakeup' runtime as well as
'no-period-wakeup' runtime. The driver likely includes a condition
statement to check 'struct snd_pcm_runtime.no_period_wakeup' flag,
then it switches own behaviour for both cases.
Please keep it in your mind that 'period-wakeup' runtime is a
default. At present, there's no way for drivers to tell userspace
applications that 'period-wakeup' runtime is not supported.
> 2. Shall we add this option in aplay for it is feature that alsa support, even it is optional?
Initially 'no-period-wakeup' runtime was introduced to achieve
timer-based scheduling model[1]. Current design of aplay is not
suitable to this model in many points (e.g. value of timeout
argument in each call of poll(2) system call). If adopting
aplay to the model, heavy refactoring is required. For this
reason, I'm not positive to your idea. It's not practical.
However, just configuring hardware parameter with 'no-period-wakeup'
flag, it's possible, as you posted. In this case, you misses some
issues. At least:
- alsa-lib configures the flag just for non-blocking operation.
- alsa-lib calls poll(2) without timeout in many parts. When
configuring the flag to PCM runtime, no tasks and IRQ contexts
awaken the sleep process. Therefore processing of PCM frame is
blocked forever in some cases.
(A call of 'snd_pcm_sw_params_set_period_event()' expects 'hw' PCM
plugin in alsa-lib to use ALSA timer interface for 'emulated'
periodical wakeup, however an instance of timer is for the PCM
runtime with 'no-period-wakeup' thus it can't awakens the sleep
process. I think this is a bug in alsa-lib.)
[1] http://0pointer.de/blog/projects/pulse-glitch-free.html
[2] https://github.com/alsa-project/alsa-utils/blob/master/axfer/xfer-libasound-timer-mmap.c#L22
Thanks
Takashi Sakamoto
next prev parent reply other threads:[~2018-12-27 11:58 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-26 11:28 [PATCH] aplay: support no period wakeup option in argument S.j. Wang
2018-12-26 13:35 ` Takashi Sakamoto
2018-12-27 2:13 ` S.j. Wang
2018-12-27 4:28 ` Takashi Sakamoto
2018-12-27 6:46 ` S.j. Wang
2018-12-27 11:58 ` Takashi Sakamoto [this message]
2019-01-01 9:13 ` Takashi Iwai
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20181227115801.GA15692@workstation \
--to=o-takashi@sakamocchi.jp \
--cc=alsa-devel@alsa-project.org \
--cc=shengjiu.wang@nxp.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.