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
