[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?

[Lin, Mengdong]

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've tried the following methods but still cannot avoid buffer underrun 100%. Could anyone share any idea about other methods?

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 "request_rewind" function on the sink and its "sink->thread_info.max_rewind" is 0.

So I modified handle_seek() function in the "protocol-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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20110617/90c12bc4/attachment.html>