>>>      * Whenever this source-output calls this function (outputting >>> "rsmplr=30, flags=0x4" in the while loop), there seems to always be >>> another immediately following call (outputting "limit=2304000bytes (1)" >>> at the start of the function) with the*large* 2304000bytes limit that >>> never executes the following "if" and "while" statement bodies. Hence >>> it never calls o->push(). >> The limit is the source's max rewind amount, and I see a bug related to >> that in module-remap-source (I wouldn't be surprised if it's in other >> filter sources too). The remap source max rewind is supposed to mirror >> the master source max rewind, but when the master source max rewind >> changes, the remap source max rewind isn't updated. The remap source >> should set the update_max_rewind source output callback, and use the >> callback to update its own max rewind to match the master source. >> >> If the max rewind isn't updated, as is now the case, it will stay at >> whatever value the master source had when the remap source got loaded. >> At that time there are likely no streams that are forcing lower >> latency, leading to a too high max rewind value when a low latency >> stream appears. > > This seems to be confirmed by the fact that the only max_rewind > changes (other than after creation) happen in the module-rtp-send module. > > Given the platform configuration difficulties I have, can you think of > a CLI-based work-around for this? Further confirmation: I removed the module-remap-source load from the CLI script, then loaded it manually *after* everything else had started up, and the latency has dropped from 4-5minutes to about 1second. I guess this hints at a CLI work-around, but I still need to get the latency down if I can. Thanks for the help Tanu. Steve
