On Dec 5 2016 16:32, Jiada Wang wrote:
Hi Sakamoto
On 11/30/2016 02:45 AM, Takashi Sakamoto wrote:
Hi Jiada,
I don't oppose this patch. Nevertheless, your description is not necessarily correct.
On Nov 30 2016 16:59, Jiada Wang wrote:
From: Daniel Girnus dgirnus@de.adit-jv.com
ALSA usually calls the prepare function twice before starting the playback:
- On hw_params call from userland and
- internally when starting the stream.
ALSA PCM core in kernel land doesn't perform like this.
In alsa-lib, 'snd_pcm_hw_params()' calls 'snd_pcm_hw_params_internal()' and 'snd_pcm_prepare()' sequentially. http://git.alsa-project.org/?p=alsa-lib.git;a=blob;f=src/pcm/pcm.c;h=cd87bc7...
In system call level (e.g. see by strace(1)), this looks like two ioctl(2)s with 'SNDRV_PCM_IOCTL_HW_PARAMS' and 'SNDRV_PCM_IOCTL_PREPARE'.
Well, when applications are written to execute 'snd_pcm_hw_params()' and 'snd_pcm_hw_prepare()' sequentially, additional ioctl(2) with 'SNDRV_PCM_IOCTL_PREPARE' appears. PulseAudio is this kind of application. I indicated the useless in 2014, but it still remains: https://lists.freedesktop.org/archives/pulseaudio-discuss/2014-January/01977...
You have the misunderstanding due to a nature of alsa-lib and tendency of major applications, from my point of view.
Thanks for your indication, so because some of userland applications call 'snd_pcm_hw_params()' and 'snd_pcm_hw_prepare()' sequentially, means the second 'SNDRV_PCM_IOCTL_PREPARE' be called in 'SNDRV_PCM_STATE_PREPARED' state,
Exactly. Furthermore, ALSA PCM core has no code to call .prepare() in contexts unrelated to SNDRV_PCM_IOCTL_PREPARE.
some devices are unable to manage this and stop working. I will update Changelog in v2 Patchset.
Regards
Takashi Sakamoto