[alsa-devel] [PATCH] Two patches for Alsa-plugins (pulse)
launchpad.web at epost.diwic.se
Fri Jun 25 12:41:46 CEST 2010
On 2010-06-24 08:42, Takashi Iwai wrote:
> At Wed, 23 Jun 2010 21:57:01 +0200,
> David Henningsson wrote:
>> These two patches are being used in Ubuntu Lucid (released this April)
>> and are working well enough to have people asking us to backport them to
>> Karmic. Today I got an email, asking for the upstream status of one of
>> these patches, since he wanted them in Fedora. If posting them here
>> isn't the correct way to upstream them, please tell me so.
>> The first one (Fix invalid buffer pointer return value) fixes broken logic:
>> This patch improves recovering from underruns, and prevents hangs inside
>> snd_pcm_write* and snd_pcm_read* due to snd_pcm_avail* returning too
>> low values. It especially helps low latency situations.
> This one looks OK. Applied now.
>> 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?
More information about the Alsa-devel