On Sat, 2014-11-08 at 16:58 +0100, Georg Chini wrote: > 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? Even if it's a bug, it's not very serious, right? Or does the extra card event cause actual trouble for you? (And what kind of card event are you talking about? I guess you mean there are two "change" events, but you weren't explicit about that.) How I'd debug it: run pulseaudio in gdb and get a stack trace whenever a card change event is sent for a bluetooth card (might need adding some extra code to filter out all other events). > > > >>> 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? No, it's the time between the point where the sink state changes to IDLE or RUNNING (from SUSPENDED or IDLE) and the point where the pop() callback in module-loopback gets called for the first time. -- Tanu
