[alsa-devel] Can I stop sound from driver as system error ?
Hi
I wonder can I stop sound from driver side (not from user-land) as system error during playback or capture ? How to do it if we can ?
Best regards --- Kuninori Morimoto
Hi,
On Dec 15 2015 10:25, Kuninori Morimoto wrote:
I wonder can I stop sound from driver side (not from user-land) as system error during playback or capture ? How to do it if we can ?
Stop PCM substreams with SNDRV_PCM_STATE_XRUN. In detail, see implementation of snd_pcm_stop_xrun() available in 3.19 or later. Then, userspace applications cannot continue to read/write PCM frames via ALSA uapi.
When using alsa-lib, then, userspace applications receive -EPIPE as return value of calling PCM APIs. The applications can stop their operation for PCM character devices, or can also recover the XRUN state of PCM substream by calling snd_pcm_prepare(). In this case, struct snd_pcm_ops.prepare() is called again in driver side.
I think tinyalsa works almost the same.
Regards
Takashi Sakamoto
Hi Takashi
I wonder can I stop sound from driver side (not from user-land) as system error during playback or capture ? How to do it if we can ?
Stop PCM substreams with SNDRV_PCM_STATE_XRUN. In detail, see implementation of snd_pcm_stop_xrun() available in 3.19 or later. Then, userspace applications cannot continue to read/write PCM frames via ALSA uapi.
When using alsa-lib, then, userspace applications receive -EPIPE as return value of calling PCM APIs. The applications can stop their operation for PCM character devices, or can also recover the XRUN state of PCM substream by calling snd_pcm_prepare(). In this case, struct snd_pcm_ops.prepare() is called again in driver side.
I think tinyalsa works almost the same.
Thank you for detail explanation ! I will try/investigate it
Best regards --- Kuninori Morimoto
Hi,
On Dec 15 2015 11:47, Kuninori Morimoto wrote:
I wonder can I stop sound from driver side (not from user-land) as system error during playback or capture ? How to do it if we can ?
Stop PCM substreams with SNDRV_PCM_STATE_XRUN. In detail, see implementation of snd_pcm_stop_xrun() available in 3.19 or later. Then, userspace applications cannot continue to read/write PCM frames via ALSA uapi.
When using alsa-lib, then, userspace applications receive -EPIPE as return value of calling PCM APIs. The applications can stop their operation for PCM character devices, or can also recover the XRUN state of PCM substream by calling snd_pcm_prepare(). In this case, struct snd_pcm_ops.prepare() is called again in driver side.
I think tinyalsa works almost the same.
Thank you for detail explanation ! I will try/investigate it
The state of PCM substreams can be changed by process context, software IRQ (softIRQ) context and hardware IRQ (hardIRQ) context. Therefore, ALSA PCM core uses spin_lock_irqsave()/spin_lock_irqrestore() to manage the race condition with softIRQ disabled, hardIRQ disabled and kernel-preemption disabled in local processor core.
As a glance, snd-soc-rcar in upstream pushes many operations to PCM trigger processing, while this trigger processing is protected with the critical section.
When you program the xrun handling in hardware/software IRQ context, it's better to pay enough attention to the lock, because any process contexts can spin in some processor cores.
Regards
Takashi Sakamoto
participants (2)
-
Kuninori Morimoto
-
Takashi Sakamoto