2012/1/22 Tanu Kaskinen <tanuk at iki.fi>: > On Fri, 2011-12-30 at 11:17 +0200, Ismo Puustinen wrote: >> I tried a similar thing a while ago. The patch is attached if you are >> interested! This approach works through a D-Bus interface. I tested >> the >> patch by changing algorithm parameters on the sink while the stream >> was >> playing, and it appeared to work properly also in that case. > > Cool stuff! As you offered the patch only to Masahide, is this not yet a > final version to be considered for upstream? > > A couple of review comments anyway: > > I'd like the parameter updates to be implemented by sending a message to > the sink with pa_asyncmsgq_send() instead of setting a boolean flag that > sink_input_pop_cb() checks every time it's called. That makes any > concurrency issues much easier to understand. It also gives better > reactivity: the delay between sink_input_pop_cb() calls may be quite > long if the hardware buffer is big (like it is by default). Sending a > message will cause the IO thread to be woken up pretty much immediately. > > Message passing alone won't solve the latency issues, though. The > previously rendered data has to be thrown away, so > pa_sink_input_request_rewind() needs to be called for u->sink_input. > > -- > Tanu > Thank you. My Patch "module-ladspa-sink" not even an alpha version of an experimental sample for the external parameter changes and dynamic changes of the parameters of LADSPA. I'm sorry. Merged into the upstream patch for me isom's D-Bus is recommended. sink_input_pop_cb() The delay is more aware. "u->control" at the store to complete the pre-parse the parameters in W-buffer to make, we would only be reduced somewhat by reversing pointers Flag = True.
