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