[pulseaudio-discuss] Bluetooth HSP sink is more likely to cause buffer underrun when moving a live stream to it from ALSA, how to ask application to write more data?

[Lu Guanqun]

On Fri, Jun 17, 2011 at 10:36:34AM +0800, Lin, Mengdong wrote:
> I found when moving a running live stream (of Gtalk) from an ALSA sink
> to a new created Bluetooth HSP sink, buffer underruns and rewind flood
> can happen and so I can no longer hear the voice from the other side.
> I抳e tried the following methods but still cannot avoid buffer
> underrun 100%. Could anyone share any idea about other methods?

Hi Amanda,

Though I me it in a different situation, but I've met this: one underrun
then rewind crazily, then no sound can be heard.

Generally, the read index should be less than the write index of sink's
memblockq. But after the underrun, the read index becomes larger than
the write index and then cause the rewrite rewind.

However, I've no idea how to overcome it right now.

> 
> Here are the methods I tried:
> 
> 1.       Using the application original requested latency when moving sinks, with patch of Arun http://lists.freedesktop.org/archives/pulseaudio-discuss/2011-June/010291.html
> 
> But, I found the original latency (200ms) is still not enough to overcome excessive underrun. After I increase the audio latency to 500ms, there are no excessive underruns for most time. But not 100% safe.
> 
> 
> 
> 2.       Force the implementor to rewind by itself when underrun happens. (original audio latenty 200ms is used on moving the sink)
> 
> I found for the BT HSP sink cannot really rewind, because It does not implement 搑equest_rewind? function on the sink and its 搒ink->thread_info.max_rewind? is 0.
> 
> So I modified handle_seek() function in the 損rotocol-native.c? to let the implement rewind by itself:
> 
> 
> 
> if (indexw < indexr) {
> 
>             /* OK, the sink already asked for this data, so
> 
>              * let's have it usk us again */
> 
> 
> 
>             pa_log_debug("Requesting rewind due to rewrite.!");
> 
>             pa_sink_input_request_rewind(s->sink_input, (size_t) (indexr - indexw), TRUE, FALSE, FALSE);
> 
> 
> 
> 
> 
>             + /* amanda: to fight BT underrun */
> 
>             + if(s->sink_input->sink)
> 
>             +{
> 
>             +    pa_sink * sink = s->sink_input->sink;
> 
>             +    if(!sink->request_rewind && !sink->thread_info.max_rewind)
> 
>             +    {
> 
>             +        /* the sink cannot handle rewind, implementor rewind by itself */
> 
>             +       sink_input_process_rewind_cb(s->sink_input, (size_t) (indexr - indexw));
> 
>             +      }
> 
>             +}
> 
> 
> 
>         }
> 
> Unfortunately, excessive rewind cannot be avoided and the voice is frequently interrupted.
> 
> 
> What other method can I try? How to ask the application to feed more data?
> Does the application write data during sink moving so that there are some data buffered for the destination sink?
> 
> Great thanks!
> Amanda
> 

> _______________________________________________
> pulseaudio-discuss mailing list
> pulseaudio-discuss at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss


-- 
guanqun