pad encoder lag?

[peter allridge]

Ive just noticed pad encoder lags behind if the audio stream being encoded restarts pad encoder carrys on and lags behind in updating the playing now info? any advice please? im running audioenc in 1 command in supervisor and 1 for padenc aswell so thats 2 as shown in the installer files per station, everything works apart from this and the webstream your encoding does trip up quite abit like there is no buff level hardly and the slightest stream hiccup makes it restart in supervisor.

ive just done a fresh install with everything updated and the issue remains the same stop the stream the pad updates much much later.

supervisor commands are...

[program:audioencoder1legacyuk]

command=odr-audioenc -v http://192.168.0.22:8000/legacyuk -r 48000 -c 1 -o tcp://192.168.0.25:9001 -l -b 40 -s 9999 -g -0 -P /tmp/pad1.fifo -p 36 -w dls1.txt

directory=/home/pi/

autostart=true

autorestart=true

stderr_logfile=/var/log/long1.err.log

stdout_logfile=/var/log/long1.out.log

[program:padencoder1legacyuk]

command=odr-padenc -o /tmp/pad1.fifo -t dls1.txt -d ./pad1 -f 40 -p 36 -s 1

directory=/home/pi/

autostart=true

autorestart=true

stderr_logfile=/var/log/long1.err.log

stdout_logfile=/var/log/long1.out.log

Pete

[Ulrik Brinck]

Hi Pete,

Is the station also broadcasting slides? I can see that your setup is ready for slides, if images are placed in ./pad1.

 

I have experienced that the pad data can lag behind, if there is not enough time to finish broadcasting a slide, before the next is inserted by the pad encoder. If your timing of the pad data is tight, i guess that restarting the audio encoder while the pad encoder stays up, could trigger such lagging.

 

You could try with a smaller image size (in kilobytes) or higher values of -p (pad size) and/or -s (sleep time between slides in odr-padenc). Remember however that when the pad size (-p) goes up, your audio quality goes down, unless you also raise the bit rate.

 

P.S. If you have a DAB USB Stick and use Andreas Gsinn's DAB Player (a 3rd party software for such sticks) to receive the station, you can use that to easily see what goes on, including the progress of broadcasting the slide, and how much your efficient audio bit rate is affected by the slide insertion.

 

Best regards,

Ulrik.

 

 

--
You received this message because you are subscribed to the Google Groups "mmbtools" group.
To unsubscribe from this group and stop receiving emails from it, send an email to crc-mmbtools...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[peter allridge]

Yes slides are enabled but i have not placed the pics in there folders as its a fresh install done earlier on just to see if this lag was a problem which it defo is? adjusting time makes no difference and the size of the slide makes zero difference it just lags out when the webstream is disconnected and reconnects the lag gets worse and can take minutes to update this only happens if the webstream trips out the pad does not stay in time with audioenc.

Ive placed pics in there folders and again no difference at all it just lags behind if the stream hiccups or stops for any reason?

Pete 

[peter allridge]

Ive disabled slides and its fully working again so its obvious there is either a niggle with the software or ive got a setting wrong?

No matter what setting i tried with slides / dls it always lags now its removed from the config dls updates do not lag anymore. so confused right now anyone point me in the right direction please?

Pete 

[Stefan Pöschel]

Hi,

@Ulrik:
An overflow/delay due to too big slides could only happen with the
old/default burst mode. But Peter has the uniform mode enabled ("-f
40"), where such an overflow no more happens. Instead, a warning, that
the slide is skipped, is shown in the log then, as the previous slide is
not yet finished.

@Pete:
As you use "-s 1", you probably will get many warnings in the log, as I
doubt that the slide transmission is already finished after 1s. You
could use a higher value, or instead use "-s 0" to transmit the next
slide after the previous one is finished. So no more slide warnings.
Could you post the log of your ODR-PadEnc instance?

The reason for the delayed PAD indeed seems to be the stream reconnect,
as in that time apparently no PAD is processed. However the PAD
generation continues and therefore the PAD is queued.

I'm also not surprised that the issue doesn't show up if you use only DLS:

When slides are transmitted, (nearly) every audio frame gets PAD data
embedded. While no audio frames are generated, the PAD data fills up the
queue and is inserted later...after having been delayed. As the queue is
filled/emptied at a similar bandwidth, the delay persists.

However when only DLS is used, PAD is inserted only in regular intervals
(here every 30 frames, as you have a frame len of 40ms and the default
DLS interval is 1200ms; see also parameter "-L"). So the PAD generation
continues here as well, but the PAD queue is filled up *way slower*. And
when the audio encoder resumes, it hence can be cleared way faster, as
the audio encoder for every audio frames tries to insert PAD.

So one solution can be to just use DLS.

Does the reconnect mean that ODR-AudioEnc is restarted, or does it
resume playback/encoding without restart?
With restart, one could just also restart ODR-PadEnc to solve the issue.
Without restart, there finally seems to be the need to rework the
interface between ODR-AudioEnc and ODR-PadEnc, to generate PAD data only
on request (which I hoped to be able to avoid, but for which we maybe
now have a good reason).

Regards,
Stefan

> --
> You received this message because you are subscribed to the Google
> Groups "mmbtools" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to crc-mmbtools...@googlegroups.com

> <mailto:crc-mmbtools...@googlegroups.com>.

[Ulrik Brinck]

Thank you for that good explanation, Stefan. :)

Best regards,
Ulrik.


----- Original Message -----

To unsubscribe from this group and stop receiving emails from it, send an email to crc-mmbtools...@googlegroups.com.

[peter allridge]

I think i now understand and will try this later on thanks for info 

Pete

[peter allridge]

-s 0 has fixed everything i understand it now thanks 

Pete

[Gerard Lokhoff]

This is a pretty old topic, so it seems weird to add something to it. Nevertheless, I have been struggling with trying to minimize the time lag between the moment a new 'ICY' text appears from ODR-AudioEnc - taken from the audio stream input - and the moment it is show on the display of a DAB receiver. I am using ODR-AudioManager and have not been able to reduce this to less than about 90 seconds (!) when using the 'uniform PAD' as recommended in the wiki. I have tried every possible setting that I could imagine (varying initial buffer size, time between labels and label repetition time, as well as slide sleeping time), but all with the same result. I checked that ODR-AudioManager actually put the correct settings in the supervisor control file, but could not find any error. And yes, I did a restart of the Pad encoder after every change to the settings.

I finally managed to bring the delay back to an acceptable level (something between 15 to 20 seconds) by not using the Uniform PAD setting. However, I had to set the slide sleeping time to much longer than I would calculate given the explanation in https://groups.google.com/g/crc-mmbtools/c/Ivn6JggYlNY/m/O5n12NpNCAAJ

Versions used:  PadEnc 2.3.0  AudioEnc 2.6.1 EncoderManager 4.0.3

Any explanation as to why Uniform PAD is giving this problem is appreciated.

Gerard Lokhoff

[Matthias Brändli]

Hi Gerard,

it's an old subject, but it's something that bites us from time to time.

I will probably replace the communication FIFO with a socket in the next
major version of ODR-AudioEnc, ODR-SourceCompanion and ODR-PadEnc. That
way, we won't suffer from having data pending in the FIFO anymore, and
the audio encoder can request PAD data at the correct rate.

If you want to test this out, you can switch to the "padsocket" branch
in ODR-AudioEnc and ODR-PadEnc, and recompile. Read the --help display,
because some options change, which also means it's not compatible with
ODR-EncoderManager.

With this change, the burst vs uniform distinction is also gone.

mpb

On 21/08/2020 22:40, Gerard Lokhoff wrote:
> This is a pretty old topic, so it seems weird to add something to it.
> Nevertheless, I have been struggling with trying to minimize the time
> lag between the moment a new 'ICY' text appears from ODR-AudioEnc -
> taken from the audio stream input - and the moment it is show on the
> display of a DAB receiver. I am using ODR-AudioManager and have not been
> able to reduce this to less than about 90 seconds (!) when using the
> 'uniform PAD' as recommended in the wiki. I have tried every possible
> setting that I could imagine (varying initial buffer size, time between
> labels and label repetition time, as well as slide sleeping time), but
> all with the same result. I checked that ODR-AudioManager actually put
> the correct settings in the supervisor control file, but could not find
> any error. And yes, I did a restart of the Pad encoder after every
> change to the settings.
>
> I finally managed to bring the delay back to an acceptable level

> (something between 15 to 20 seconds) by _not_ using the Uniform PAD

> setting. However, I had to set the slide sleeping time to much longer
> than I would calculate given the explanation in
> https://groups.google.com/g/crc-mmbtools/c/Ivn6JggYlNY/m/O5n12NpNCAAJ
>
> Versions used:  PadEnc 2.3.0  AudioEnc 2.6.1 EncoderManager 4.0.3
>
> Any explanation as to why Uniform PAD is giving this problem is appreciated.
>
> Gerard Lokhoff
>

> --
> You received this message because you are subscribed to the Google
> Groups "mmbtools" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to crc-mmbtools...@googlegroups.com
> <mailto:crc-mmbtools...@googlegroups.com>.

> To view this discussion on the web visit
> https://groups.google.com/d/msgid/crc-mmbtools/d9a72cf1-d9f7-4e94-8732-9c87bf2004ebn%40googlegroups.com
> <https://groups.google.com/d/msgid/crc-mmbtools/d9a72cf1-d9f7-4e94-8732-9c87bf2004ebn%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Gerard Lokhoff]

OK, Matthias, I'll try to do this (not very familiar with GitHub, but learning !) on a separate install for PadEnc and AudioEnc and report back.

Thanks !

Gerard

[Matthias Brändli]

On 22/08/2020 19:28, Gerard Lokhoff wrote:
> not very familiar with GitHub, but learning !

Just clone the repository, and then do "git checkout padsocket" after that.

Let me know!

mpb

[Gerard Lokhoff]

Hi Matthias,

I managed to install the padsocket branch version today and tested it - it works fine, very quick take up of the information.

Any idea when this will be in the 'production' version of AudioEnc and PadEnc ?

Gerard

Op maandag 24 augustus 2020 om 09:00:49 UTC+2 schreef Matthias Brändli:

[Matthias Brändli]

> I managed to install the padsocket branch version today and tested it -
> it works fine, very quick take up of the information.

Excellent, thanks for testing it!

> Any idea when this will be in the 'production' version of AudioEnc and
> PadEnc ?

I'd say relatively soon. My aim is to coordinate with Yoann so that we
can do a combined release with the ODR-EncoderManager.

mpb

[Fabien Cuny]

Hello everyone,

I also noticed these lags on my trial muxes, sometimes with 2mins of lag between the slides and txt updates when a new title is broadcasted and the update on a tuner.

I tried this new branch on ODR-PadEnc and ODR-AudioEnc. It works like a charm on MP3 streams. But I got a FLAC (OGG/FLAC) stream on one of my channels, and the PAD broadcast stucks, no SLS broadcasted and the DLS is stucked on the first file (i have two text files rotating).

Do you have the same issue ?

Fabien

[Jens]

Hello Fabien,

I've been testing the "padsocket" branch of ODR-PadEnc and ODR-AudioEnc for a few days already. MOT SLS and DL Plus are performing flawlessly and there are no lags anymore.

I'm also feeding a channel with an OGG/FLAC stream using the GStreamer input of ODR-AudioEnc. I haven't noticed any issues.

Maybe you're using the VLC input? As far as I can say the GStreamer input is much more reliable than the VLC input.

Regards,

Jens

[Gerard Lokhoff]

All, I agree Gstreamer seems more reliable. However, it also seems to use more processing cycles.

Gerard

Op maandag 7 september 2020 om 00:29:19 UTC+2 schreef Jens: