[pulseaudio-discuss] PA_CORE_HOOK_SINK_INPUT_PUT

[Lennart Poettering]

On Fri, 20.06.08 10:16, Nick Thompson (rextanka at comcast.net) wrote:

> Hi,
>
> I posted yesterday, and whilst I didn't figure out an answer the question 
> about the sequencing of the _put call, I did find another way to get what I 
> need.  I wanted to get the index of a sink input after creation, but
> before 

Is I tried to point out to you your code was heavily racy. I would
assume that the weirdness you are experiencing with the put hook is
mostly caused by this.

> I can't explain why _put is called after the stream completes playback, but 
> I did discover a different way to be notified of sink-input creation with 
> the completely filled sink input, using pa_subscription.  Recall
> that 

The subscription event is triggered at exactly the same place as the
_PUT hook:

http://git.0pointer.de/?p=pulseaudio.git;a=blob;f=src/pulsecore/sink-input.c;h=07ddb83af48b3b1ea8e6e90ca339a2cb1b031725;hb=refs/heads/tags/release-0.9.10#l390

I am pretty much sure fixing that racyness in your code will also make
_PUT work as requested. Also note that _PUT is called *after* the
stream has been passed to the sink's I/O thread. I.e. at that point it
might already have started to play. 

The subscription stuff is not what you want. The idea of the
subscription stuff is to suppress multiple redundant server
change events so that communication with the client is
minimized. i.e. before the callbacks for the subscription events are
called multiple CHANGE events will be replaced by a single one. CHANGE
and NEW events followed by a REMOVE are dropped altogether. Also In
contrast to the hooks the callbacks are dispatched from a new
stackframe, in a later event loop iteration. Along with that goes that
at time of the dispatching the actually objects that those
NEW/CHANGE/REMOVE events have been generated for don't exist anymore.

The subscription stuff predates the hook stuff and I probably should
be implemented the subscription foo based on the hook stuff now. 

Anyway, the hook stuff is not what you want. It is only useful for
writing new protocol modules and very few other cases. (there's some
code in a few of the modules that uses this but shouldn't)

> neither sink-input new hook or the sink-input fixate hook will call back 
> with a complete sink-input (the index of the sink-input has not been set 
> with either) and that I was not seeing the sink-input put hook being called 
> until after a stream had completed playback.  So the method I came across 
> (modified from one of the existing module sources) is as follows.

Yes, the new/fixate hook will hand you the pa_sink_input_new struct so
that you can make changes to it. The sink input will then be created
and initialized. And then when the _put() is called it will actually
be made available to the PA core. And that's when you get the _PUT
callback: at the first time when the sink input is actually a sink input.

Really, _PUT is what you want.

(Unless you want to modify the parameters of the stream *before* the
sink started to play. If that's the case then use the NEW hook and
patch the struct you get passed as needed. Of course, then you won't
have a pointer to the final pa_sink_input object. If you give me a very good
use case and can explain why NEW/FIXATE ain't enough and _PUT is too
late I might be willing to add another hook, one that is called in the
pa_sink_input_put() function immediately before the object is handed
to the IO thread, i.e. immediately before we start playback.)

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4