[alsa-devel] [PATCH alsa-lib] pcm: dmix: Handle slave PCM xrun and unexpected states properly

Takashi Iwai tiwai at suse.de
Fri Oct 30 18:22:56 CET 2015


On Fri, 30 Oct 2015 17:36:31 +0100,
Alexander E. Patrakov wrote:
> 
> 30.10.2015 21:33, Alexander E. Patrakov wrote:
> > [resending to the list, sorry for the duplicate]
> >
> > 30.10.2015 21:18, Takashi Iwai wrote:
> >> Currently, dmix & co plugins ignore the XRUN state of the slave PCM.
> >> It's (supposedly) because dmix deals with the PCM in a free-wheel
> >> mode, which is equivalent with XRUN.  But, this difference (whether
> >> the correct freewheel or XRUN) should be done by the kernel, and we
> >> may have an XRUN state indeed (e.g. via xrun injection).
> >>
> >> This patch fixes this lack of behavior, to handle PCM xrun and does
> >> prepare when the slave PCM is in such a state.
> >>
> >> Also, the patch consolidates the prepare callback for all dmix, dsnoop
> >> and dshare plugins, and fix/cleanup a bit for dshare/dsnoop codes to
> >> align with dsnoop code.
> >>
> >> Signed-off-by: Takashi Iwai <tiwai at suse.de>
> >
> > Just a nitpick.
> >
> > In snd_pcm_direct_prepare(), you use snd_pcm_state(...) directly in the
> > switch statement, but in other places of the patch you introduce a
> > temporary variable for the state. Why?
> 
> Sorry for the noise - you do need a temporary variable, because you 
> return its value.
> 
> >
> > Also, in snd_pcm_direct_prepare(), the "dmix" variable name is confusing.
> >
> 
> So, other than that, the patch looks OK.

dmix is used in other helper functions in pcm_direct.c, so I took it
as is.  Yes, it's a bit confusing, and we may rename it all to other
agnostic name, if it really matters...


thanks,

Takashi


More information about the Alsa-devel mailing list