[pulseaudio-discuss] Sinks: thread_info.max_rewind debug printfs
tanuk at iki.fi
Sun Mar 31 23:33:47 PDT 2013
On Sunday, March 31, 2013 10:06:01 PM Justin Chudgar wrote:
> Here is a slightly better one than the gist I posted last night. Note the
> "update_max_rewind_cb not called!" line. Seems that if a sink is unlinked,
> sink.c sets its max_rewind but; because there is no sink input, it does not
> call the callback.
If the sink is unlinked, max_rewind doesn't have any meaning anyway. You don't
need to care about max_rewind during times when your sink input isn't
connected to the master sink. You get notifications about connection state
changes via the attach() and detach() callbacks. You can check in attach()
what the current max_rewind is and allocate the rewind buffer accordingly.
Before the initial attach() call, and between detach() and attach() calls when
the sink input is moved, you shouldn't have any need to access the rewind
buffer, because pop(), update_max_rewind() and process_rewind() won't be
called during those times.
I should have told you already earlier that in addition to updating the rewind
buffer in update_max_rewind(), you need to initialize/update it also in
attach(), but I didn't think about this before now.
> Is it possible to have an update_max_rewind callback for the sink as well
> as the sink_input? That would seem to make things more consistent and
> prevent different threads from messing with a sink member value.
Different threads never mess with the thread_info variables. They are accessed
exclusively from the sink IO thread, with the exception that when the IO
thread is not running, the main thread may initialize the variables to some
More information about the pulseaudio-discuss