[alsa-devel] [PATCH] Two patches for Alsa-plugins (pulse)

David Henningsson launchpad.web at epost.diwic.se
Fri Jul 9 19:50:58 CEST 2010

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

More information about the Alsa-devel mailing list