At Tue, 18 Sep 2001 13:24:03 +0200 (CEST),
Jaroslav wrote:
>
> Hello,
>
> I would like to discuss the desired behaviour for suspend/resume
> cycles for the PCM interface. The actual implementation of PM in ALSA
> drivers silently assumes that the application doesn't handle anything and
> the PCM stream continues with the time gap. It doesn't look bad until the
> application is real-time related. The question is, if we should define a
> new PCM state 'SUSPEND' which behaves like XRUN but it's not guaranteed
> that all samples from ring buffer are drained for playback (capture should
> behave like standard overrun). The actual position can be determined, so
> the application can choose, if the data would be lost or resent them
> again. We can eventually implement a new RESUME syscall which will resume
> playback after next 'write' call or capture before next 'read' call.
>
> So the power management write loop should be:
>
> res = snd_pcm_write(pcm, data, size);
> if (res == -ESTRPIPE) { /* SUSPEND */
> err = snd_pcm_resume(pcm);
> if (err == -ENXIO) /* not implemented */
> err = snd_pcm_prepare(pcm);
> if (err < 0)
> /* report error */ ;
> } else if (res == -EPIPE) { /* underrun */
> err = snd_pcm_prepare(pcm);
> if (err < 0)
> /* report error */ ;
> }
Can't we merge both functions into snd_pcm_prepare()?
res = snd_pcm_write(pcm, data, size);
if (res == -EPIPE || res == -ESTRPIPE) {
err = snd_pcm_prepre(pcm);
if (err < 0)
error;
}
I think it's ok even returning -EPIPE in the case of suspend, too.
From user application side, it doesn't matter whether underrun or
suspend.
PCM stream knows its current state, so user doesn't need to handle
these exceptional cases.
Of course, the exact status (whether underrun or suspend) should be
available via snd_pcm_status().
Takashi
_______________________________________________
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
