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.
// David