[pulseaudio-discuss] Bluez Questions

[Georg Chini]

On 07.11.2014 12:44, Luiz Augusto von Dentz wrote:
> Hi Georg,
>
> On Tue, Nov 4, 2014 at 3:00 PM, Tanu Kaskinen
> <tanu.kaskinen at linux.intel.com> wrote:
>> On Mon, 2014-11-03 at 20:05 +0100, Georg Chini wrote:
>>> Hello,
>>>
>>> i have two (unrelated) questions regarding bluez5 (with ofono backend):
>>>
>>> 1) I am using the subscription API and when my headset changes profile
>>> the subscription callback (with mask PA_SUBSCRIPTION_MASK_CARD) is
>>> called twice. Is this correct? if yes, one call is for the profile
>>> change, what
>>> is the reason for the other one?
>> I don't know.
> Could be a bug.

Any idea where I would have to look for it?

>
>>> 2) I am playing back audio from my phone to my bluetooth headset. When
>>> I now switch off the headset, bluetooth takes a while to recognize, that the
>>> headset is no longer available. When pulse receives the notification
>>> that the
>>> headset is gone, the stream is switched to the default device and starts
>>> playing exactly at the point where the headset was switched off and goes on
>>> playing for a while after I stop playback on the phone. All future sounds I
>>> feed into th loopback module are now delayed by the gap between
>>> the switch off of the headset and the moment pulseaudio is notified.
>>> Is there a way to reset the loopback module to its initial state?
>> No, there's no "reset loopback" feature. The loopback also has the
>> problem that if the initial startup of the sink takes a long time, that
>> also causes unwanted latency.
>>
>> The loopback module could probably be improved by discarding data from
>> the source until the sink asks for data for the first time (would fix
>> the slow startup problem) and flushing the buffer when the sink input
>> gets detached (would help with your problem).
> +1, either we do this unconditionally or have an API to define such policies.


I tried to figure out what module-loopback is doing. Unfortunately I don't
know a lot about the pulseaudio internals but as far as I could find out
unconditionally flushing the buffer when the output is detached is a
one-line patch and indeed solves my problem.
(Just added pa_memblockq_flush_write(u->memblockq, true) to
the function sink_input_detach_cb)

Regarding the slow startup, I wonder where the delay shows up in 
pulseaudio.
Is it the time between the sink being IDLE and RUNNING?
If so, the fix is probably also a simple change, because 
sink_input_process_msg_cb
checks for PA_SINK_IS_OPENED when processing the message and could instead
check for PA_SINK_IS_RUNNING.

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