[pulseaudio-discuss] understanding PA cork/uncorking scenarios

Himanshu Chug himanshu.chug at gmail.com
Thu Jun 30 08:33:53 PDT 2011


Hi Colin

I did further debugging for the use-case, music over phone i.e

1. "phone" stream is ongoing
2. "music" stream arrives,

I observed that the music stream is never corked , I assumed that it was
working sometimes but actually the music stream gets "muted" just before
call to cork, as seen in this code from module-cork-music-on-phone.c in
apply_cork() function:

                    if (cork && !corked) {
                        pa_hashmap_put(u->cork_state, ignore,
PA_INT_TO_PTR(1));
                        pa_sink_input_set_mute(ignore, TRUE, FALSE);
                        pa_sink_input_send_event(ignore,
PA_STREAM_EVENT_REQUEST_CORK, NULL);
                        return;
                    }

when I commented pa_sink_input_set_mute() , stream got mixed with phone !!!
and I assumed that the use-case is working fine sometimes!!! sad!

which means that as you mention for "PA_STREAM_START_CORKED flag... streams,
when connecting can say "Please start me corked"
have this problem always and this is a bug in the code. ?? which might needs
to be handle somehow..gracefully.

any comments are welcome?

Best Regards,
Himanshu



On Fri, Jun 17, 2011 at 2:28 PM, Colin Guthrie <gmane at colin.guthr.ie> wrote:

> 'Twas brillig, and Himanshu Chug at 16/06/11 10:39 did gyre and gimble:
> > Thanks Tanu for the clarifications.
> >
> > But the doubt is still , who is actually sending the pause(cork) event
> > to pulsesink or gst, either or both of these:
> > 1. module-x11-cork-request with X11 keyboard events
> > 2. src/pulsecore/protocol-native.has sink_input_send_event_cb(),
>
> The latter. Both former is listening for the cork requests on streams.
>
> e.g. in module-x11-cork-request (which I very much think you should
> ignore completely and disable in any install as it just gets in the way
> and results in very strange behaviour due to non-stateful tracking of
> the current state... e.g. by default if a Skype call comes in when you
> have e.g. Amarok paused, then Amarok will unpause for you when the call
> starts and pause again then it ends... the exact opposite of what you
> want!), there is this hook:
>
>    u->hook_slot = pa_hook_connect(
>            &m->core->hooks[PA_CORE_HOOK_SINK_INPUT_SEND_EVENT],
>            PA_HOOK_NORMAL,
>            (pa_hook_cb_t) sink_input_send_event_hook_cb, u);
>
>
> So the function sink_input_send_event_hook_cb(), is what listens for
> corks and then takes appropriate action (sending synthesised keystrokes).
>
>
> Now the "event" sending stuff is quite generic, with cork and uncork
> just examples of the kind of events we currently support. Other events
> may include "supported formats changed" (e.g. if you move an mp3
> passthrough stream to a sink that does not support mp3 passthrough - the
> client has to be informed so they can take appropriate action to do the
> decode themselves and start delivering PCM data instead).
>
>
> So this is the call but it needs to be triggered by something e.g. in
> module-cork-music-on-phone:
>
> pa_sink_input_send_event(j, PA_STREAM_EVENT_REQUEST_CORK, NULL);
>
> Here it's ultimately using the protocol native
> sink_input_send_event_cb() function to send the request to the client,
> but the trigger starts with the above call.
>
> > and where these event is handled in pulsesink (and gst)?  as
> > gst_pulsering_stream_event_cb( ) is disabled with flag
> > HAVE_PULSE_0_9_15, So I guess
> > this event is handled somewhere else,but not sure where?
>
> We covered this in my last reply. HAVE_PULSE_0_9_15 is defined :)
>
> > I am getting one bug, where pulse-audio daemon is terminated, the
> > usecase is:
> >
> > 1. "phone" stream is ongoing
> > 2. "music" stream arrives,
> >
> > so expected behavior is music should get corked while phone is active,
> > eventually its getting corked sometimes and working fine but not always!
>
>
> Ahh, interesting... yeah, this is perhaps due to the START_CORKED
> flag... streams, when connecting can say "Please start me corked" in
> this case, the client will specifically uncork the music stream at the
> beginning of playback... Hmm, not quite sure how to deal with this.....
>
>
> > and sometimes PA daemon gets terminated saying Failed to handle SIGBUS,
> > here are few gst logs when starting "music" stream from gst-launch:
> >
> > ERROR: from element
> >
> /GstPlayBin2:playbin20/GstPlaySink:playsink0/GstBin:abin/GstBin:bin0/GstPulseSink:pulsesink0:
> > pa_stream_write() failed: Connection terminated
> > Additional debug info:
> > pulsesink.c(1587): gst_pulseringbuffer_commit ():
> >
> /GstPlayBin2:playbin20/GstPlaySink:playsink0/GstBin:abin/GstBin:bin0/GstPulseSink:pulsesink0
> > Execution ended after 75439452 ns.
> > Setting pipeline to PAUSED ...
> > Setting pipeline to READY ...
> >
> /GstPlayBin2:playbin20/GstPlaySink:playsink0/GstBin:abin/GstBin:bin0/GstPulseSink:pulsesink0.GstPad:sink:
> > caps = NULL
> > Assertion 'pa_atomic_load(&(b)->_ref) > 0' failed at
> > pulsecore/memblock.c:590, function pa_memblock_unref(). Aborting.
> > Aborted
>
> Ouch. Not sure how best to debug that one.
>
> > I doubt this issue is related to my earlier question, as you mentioned
> > "module-x11-cork-request is a workaround for clients that don't handle
> > stream events (a workaround that isn't working very well, I've heard) "?
>
> Yeah, I've disabled x11-cork-request in my packages for a long time and
> generally recommend others to do the same.
>
> In fact I thought I had disabled it in git master's
> start-pulseaudio-x11, but it seems I didn't. I remember asking about
> this to gauge a consensus... but can't find anything on the list... I'll
> ask again.
>
> Col
>
>
> --
>
> Colin Guthrie
> gmane(at)colin.guthr.ie
> http://colin.guthr.ie/
>
> Day Job:
>  Tribalogic Limited [http://www.tribalogic.net/]
> Open Source:
>  Mageia Contributor [http://www.mageia.org/]
>  PulseAudio Hacker [http://www.pulseaudio.org/]
>  Trac Hacker [http://trac.edgewall.org/]
>
> _______________________________________________
> pulseaudio-discuss mailing list
> pulseaudio-discuss at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20110630/e36c0c56/attachment.html>


More information about the pulseaudio-discuss mailing list