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
