* 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
_______________________________________________
pulseaudio-discuss mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
