On Tue, 18 Sep 2001, Takashi Iwai wrote:

> 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().

There are some differences between the xrun and suspend cases. The ring
buffer can contain some data for playback which can be used to continue
for playback and the old data can be flushed (discarded) for capture. But
I think that this choice is on an application. Note that your simplified
code will work ok, but the samples will be flushed (discarded).

                                                Jaroslav

-----
Jaroslav Kysela <[EMAIL PROTECTED]>
SuSE Linux    http://www.suse.com
ALSA project  http://www.alsa-project.org


_______________________________________________
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Reply via email to