Closed argilo closed 2 weeks ago
Great, thank you!
Does that mean that the flowgraph will automatically apply the setting once Chunks to Symbols is fixed or would this require another patch?
Does that mean that the flowgraph will automatically apply the setting once Chunks to Symbols is fixed
Yes.
And to get the latency reduction without waiting for a bug fix, the generated rds_tx.py can be edited to replace this line:
self.digital_chunks_to_symbols_xx_0.set_max_output_buffer(outbuffer)
with:
self.digital_chunks_to_symbols_xx_0.set_max_output_buffer(0, outbuffer)
To control RDS latency, many blocks in rds_tx.grc have a maximum output buffer size (Maxoutbuf) specified. As noted in https://github.com/bastibl/gr-rds/issues/83#issuecomment-2447309950, this causes excessively high CPU utilization. This stems almost entirely from the high-sample-rate blocks (Multiply, Add, Frequency Mod) which contribute a negligible amount to the overall RDS latency. Removing the Maxoutbuf setting for these blocks reduces CPU utilization by about 65% without any noticeable effect on latency.
Also, two low-sample-rate blocks (RDS Encoder, Chunks to Symbols) do not specify a maximum output buffer size. Adding the setting to the RDS Encoder block reduces RDS latency from 72 seconds to 20. I've added the setting to the Chunks to Symbols block as well, but unfortunately it has no effect at the moment due to a bug in GNU Radio: https://github.com/gnuradio/gnuradio/issues/7534. If that bug is fixed, then another 7 seconds of latency could be removed.
As noted in https://github.com/bastibl/gr-rds/issues/83#issuecomment-2448942441, a better way to control latency would be to use the approach taken by gr-latency_manager: have the RDS Encoder block generate stream tags, and limit its output until those tags are seen downstream. That's a bigger change, so I thought it would make sense to do a quick fix to the Maxoutbuf settings first, which already gives a substantial improvement.