On 07.11.2014 12:44, Luiz Augusto von Dentz wrote:
Hi Georg,
On Tue, Nov 4, 2014 at 3:00 PM, Tanu Kaskinen
<[email protected]> 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
[email protected]
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
_______________________________________________
pulseaudio-discuss mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
