[alsa-devel] [PATCH] Two patches for Alsa-plugins (pulse)
Raymond Yau
superquad.vortex2 at gmail.com
Thu Jul 29 09:11:26 CEST 2010
2010/7/10 David Henningsson <launchpad.web at epost.diwic.se>
> 2010-07-09 18:23, Takashi Iwai skrev:
> > At Fri, 9 Jul 2010 21:13:52 +0800,
> > Raymond Yau wrote:
> >>>>>>> The second one (Do not report underruns to the ALSA layer) is more
> a
> >>>>>>> change of behavior, which could be questioned. The arguments for
> >>>>>>> removing that code are these:
> >>>>>>>
> >>>>>>> * If pulseaudio gets an underrun, the normal way to end that
> >>> underrun
> >>>>>>> is to feed it with more buffers. This is different from the ALSA
> way
> >>> of
> >>>>>>> dealing with underruns, which requires hardware buffer pointers to
> >>> be reset.
> >>>>>>> * In addition, underrun signals are delivered asynchronously from
> >>>>>>> pulseaudio. This means that there might be more buffers on the way
> >>> to
> >>>>>>> pulseaudio when the underrun is reported, making the underrun
> >>> obsolete.
> >>>>>>> Unfortunately, there is currently no known way to determine whether
> >>> this
> >>>>>>> is the case or not.
> >>>>>>
> >>>>>> I think this helps for normal use-cases, so it'd be good to apply.
> >>>>>> But, I prefer having a runtime option for such a behavior change
> >>>>>> (although the default value can be the new behavior).
> >>>>>>
> >>>>>> Care to add it?
> >>>>>
> >>>>> Sure, I can do that - it sounds like a good idea to have it
> >>> configurable.
> >>>>> Just so I understand you right, exactly how do you expect the user /
> >>>>> application to configure it?
> >>>>
> >>>> I suppose it can be simply added as an alsa-lib plugin config, i.e.
> >>>> in SND_PCM_PLUGIN_DEFINE_FUNC(pulse) of
> alsa-plugins/pulse/pcm_pulse.c,
> >>>> add the code like below:
> >>>>
> >>>> int handle_underrun = 0;
> >>>> ...
> >>>>
> >>>> snd_config_for_each(i, next, conf) {
> >>>> ...
> >>>> if (strcmp(id, "handle_underrun") == 0) {
> >>>> handle_underrun = snd_config_get_bool(n);
> >>>> if (handle_underrun < 0) {
> >>>> SNDERR("Invalid value for %s", id);
> >>>> return handle_underrun;
> >>>> }
> >>>> continue;
> >>>> }
> >>>> }
> >>>
> >>> FYI, I modified the patch and applied to git tree right now.
>
> Thanks! I've been on holiday this week but thought I would do it in the
> following week. Only nice to see it being done :-)
>
> >> This behaviour is a little bit strange , using the same buffer size 128
> >>
> >> aplay -Dhw:0,0 --buffer-size=128 test.wav
> >>
> >> report underrun
> >>
> >>
> >> aplay -D pulse --buffer-size=128 test.wav
> >>
> >> did not report underrun but the sound is distorted
> >
> > Other subsystem, other behavior.
> > The detection of underrun is even unreliable on ALSA native, so user
> > can't expect it'll get underrun.
> >
> > The biggest drawback by this change is that whether the sound goes
> > well or not isn't reported any more to the application layer.
> > It's an unfortunate design, but it's life with PA.
>
> The question is - is there an application that detects the underrun
> condition and actually acts on that condition? If so, this could be a
> regression for that app. For other apps it's an improvement, for the
> reasons originally stated.
>
>
This patch by Lennart Poettering should answer your question
http://git.alsa-project.org/?p=alsa-plugins.git;a=commit;h=660e0f16145167a966e9b8387e9a8e08274a8f7c
More information about the Alsa-devel
mailing list