[pulseaudio-discuss] Sinks: thread_info.max_rewind debug printfs

[Tanu Kaskinen]

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 
defaults.

-- 
Tanu