ODR-PadEnc : update DLS not work & DLS file enlarged more and more

[Fabien]

Dear all,

I've a problem with ODR-PadEnc.

When I update the DLS text file, it does not update in the Mux. To force the update, I am forced to restart ODR-PadEnc, ODR-AudioEnc & ODR-DabMux; Also, the DLS stay on the first DLS text as if it were in cache. Tested with several tuner of different brands (including PURE).

I also noticed that the PAD file enlarged more and more with time. After a few days, my PAD file is over 350MB

My config :

odr-padenc --dls=/home/dab/DAB/dls/radiocite.dls --output=/home/dab/DAB/dls/radiocite.pad --dir=/home/dab/DAB/dls/radiocite/ -p 24


odr-audioenc --vlc-uri=https://stream.and-stuff.nl:8443/live-riverside-flac -C 3000 -L --audio-resampler=samplerate -L --src-converter-type=0 -g -1 -b 96 --sbr -r 48000 -o tcp://10.30.10.124:79004 --pad=24 --pad-fifo=/home/dab/DAB/dls/radiocite.pad

And my MUX config : https://pastebin.com/W6TtLGC0

Why is my DLS not updating and getting stuck? ;-(

Thanks

Have a nice week-end,

Fabien

[Stefan Pöschel]

Hi Fabien,

this really sounds as if the PAD file is not a FIFO, but a regular file.
Did you make sure that it is a FIFO (use "mkfifo" to create it)?
What output is returned by "ls -l /home/dab/DAB/dls/radiocite.pad" ?

Best regards,
Stefan

Am 09.02.2018 um 23:54 schrieb Fabien:
> Dear all,
>
> I've a problem with ODR-PadEnc.
>
> When I update the DLS text file, it does not update in the Mux. To force
> the update, I am forced to restart ODR-PadEnc, ODR-AudioEnc &
> ODR-DabMux; Also, the DLS stay on the first DLS text as if it were in
> cache. Tested with several tuner of different brands (including PURE).
>
> I also noticed that the PAD file enlarged more and more with time. After
> a few days, my PAD file is over 350MB
>
> My config :
>
> |
> odr-padenc --dls=/home/dab/DAB/dls/radiocite.dls
> --output=/home/dab/DAB/dls/radiocite.pad

> --dir=/home/dab/DAB/dls/radiocite/-p 24

>
>
> odr-audioenc
> --vlc-uri=https://stream.and-stuff.nl:8443/live-riverside-flac -C 3000
> -L --audio-resampler=samplerate -L --src-converter-type=0 -g -1 -b 96
> --sbr -r 48000 -o tcp://10.30.10.124:79004 --pad=24
> --pad-fifo=/home/dab/DAB/dls/radiocite.pad
> |
>
> And my MUX config : https://pastebin.com/W6TtLGC0
>
> Why is my DLS not updating and getting stuck? ;-(
>
> Thanks
>
> Have a nice week-end,
> Fabien
>

> --
> 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>.
> For more options, visit https://groups.google.com/d/optout.

[Fabien]

Hi Stefan,

Before :

-rw-rw-r-- 1 dab dab 2511597 fév 10 00:10 radiocite.pad

And after, I try when delete radiocite.pad and recreate with command mkfifo radiocite.pad, now it's :

prw-rw-r-- 1 dab dab 0 fév 10 00:16 radiocite.pad

But always the same problem : even after a few minutes, if I change text in my DLS file, it does not change :-/

[Fabien]

Oh, now it's automatically updated, but after > 3min.

With a --pad of 24, it seems too long, no?

[Stefan Pöschel]

I just added a check for the output file to be a FIFO, to prevent the
problem you initiall had in the future.


Indeed; the reason is that one slide cannot be completely transmitted in
the (default) 10 seconds with the chosen PAD size. After the 10s, the
next slide is already transmitted so that there is kind of a PAD
congestion. To prevent this, you have to increase the PAD size or the
delay length, or to decrease the slide size.

An alternative is to use the newer "uniform mode":
https://github.com/Opendigitalradio/ODR-PadEnc/commit/9f62da63eb7577d30dc67fc2823201b4f2598ffa

In your case, you have to add "-f 40", as you use 48 kHz with SBR
(HE-AAC). Now you will get a message if after the 10s the slide
transmission has not been finished yet, and that the next slide is
therefore delayed until the next 10s interval. Meanwhile the label is
repeated as expected, independent from the slideshow.
With the uniform mode, you can also set the slide delay to 0s ("-s 0").
This means that transmission of the following slide starts just when the
transmission of the previous one has finished.

Am 10.02.2018 um 00:27 schrieb Fabien:
> Oh, now it's automatically updated, but after > 3min.
> With a --pad of 24, it seems too long, no?
>

[Fabien]

Thanks Stefan, with -f 40 and -s 0, the DLS text update is done in 10sec

Why *uniform mode* is not by default ?

[888...@gmail.com]

Hi Stefan,

I don't understand difference, without uniform and -s 1 I also have next slide just after previous after 1s

[Stefan Pöschel]

The reason is that the uniform mode requires knowledge of the length of
an audio frame/unit, to adapt the PAD generation to it. The burst mode
does not need to know it, as it just "spits out" all the encoded PADs in
regular intervals.

This was the simplest solution to really utilize the available PAD
bandwidth, without the need to adjust the audio encoder (i.e. to
introduce a feedback channel).

So it cannot be enabled by default, but I will adjust the documentation
accordingly, to strongly recommend the uniform mode, as I did not
receive any negative feedback so far. ;-)

Am 10.02.2018 um 01:20 schrieb Fabien:
> Thanks Stefan, with -f 40 and -s 0, the DLS text update is done in 10sec
> Why *uniform mode* is not by default ?
>

[Stefan Pöschel]

Hi,

you also have the next slide immediately after the previous one, but for
a different reason: The burst mode just outputs the PADs every 1s, and
due to this way too small delay, the FIFO has to buffer more and more PADs.
So any DLS changes or new slides are more and more delayed - the same
thing that happened to Fabien, but just even worse, due to the only 1s
delay. Please try yourself ;-)

[888...@gmail.com]

So how to calculate value for -f parameter?

[Stefan Pöschel]

The value just depends on which codec/sample rate you are using for
audio. The frame length for the -f parameter is contained in the table here:
https://wiki.opendigitalradio.org/ODR-PadEnc#Using_DLS_and_MOT_SLS_together

[Fabien]

Hi,

To be sure to understand: if I have an AAC + audio at 64Kbps and I give a --PAD at 36, it remains for the audio permanently only 28Kbps?

[888...@gmail.com]

Thanks, eg 192k/48kHz will be: AAC-LC -f 20.

[Stefan Pöschel]

Yes, exactly.

> <https://wiki.opendigitalradio.org/ODR-PadEnc#Using_DLS_and_MOT_SLS_together>

[Stefan Pöschel]

Hi,

no, this is not correct:
When you use e.g. 36, it means that one audio frame may contain up to 36
bytes of PAD data. So depending on the actual frame length (see the link
posted earlier) you can roughly calculcate the bandwidth of the audio
that is used for PAD data.
For example when you use AAC-LC with 48 kHz, every audio frame/unit is
20ms long. 1000 / 20 * 36 = 1800 bytes/second. This equals to 14,4 kbps
(like an old modem ;-).

[Yoann QUERET]

Salut Stefan,

I did tests with the UNIFORM mode today, and it works very well.

1 new different DLS every 2 second even when an image is sent
link : https://youtu.be/GSTTyUt6DgA


Question :

When i run odr-padenc without --remove-dls and have for example 5 files
in the images direcotry (--dir), you try to send this 5 images files and
refresh the images files list when you have finish to send it. right ?

If i remove an image file, before you refresh the list of images files,
odr-padenc wait the sleep delay (--sleep) to try to send the next file,
so is it possible to try to send the next image immedialty rather than
wait the sleep delay ?

Yoann

On 11/02/2018 23:33, Stefan Pöschel wrote:
> The value just depends on which codec/sample rate you are using for
> audio. The frame length for the -f parameter is contained in the table here:
> https://wiki.opendigitalradio.org/ODR-PadEnc#Using_DLS_and_MOT_SLS_together
>
> Am 11.02.2018 um 22:39 schrieb 888...@gmail.com:
>> So how to calculate value for -f parameter?
>>
>> On Saturday, February 10, 2018 at 12:38:29 PM UTC+1, Stefan Pöschel wrote:
>>
>> Hi,
>>
>> you also have the next slide immediately after the previous one, but
>> for

>> a different reason: The burst mode just outputs the PADs every 1s, andwhich introduces a delay
>> introducesˌintrəˈd(y)o͞os
>> Définitions de introduce
>> verbe
>> bring (something, especially a product, measure, or concept) into use or operation for the first time.
>> various new taxes were introduced
>> synonymes: institute, initiate, launch, inaugurate, establish, found, bring in, usher in, set in motion, start, begin, commence, get going, get underway, originate, pioneer, kick off; propose, put forward, suggest, bring to the table, submit, set forth, raise, broach, bring up, mention, air, float, run something up the flagpole
>> make (someone) known by name to another in person, especially formally.
>> I hope to introduce Jenny to them very soon
>> synonymes: present (formally), make known, acquaint with
>> insert or bring into something.
>> a device that introduces chlorine into the pool automatically
>> synonymes: insert, inject, put, force, shoot, feed; instill, infuse, inject, add, insert
>> occur at the start of; open.
>> a longer, more lyrical opening that introduces her first solo
>> Voir aussi
>> Introduce, to introduce, introduce oneself, introduce to, introduce from elsewhere
>> Traductions de introduce
>> verbe
>> présenter
>> present, introduce, offer, put, pose, table
>> amener
>> bring, lead, induce, bring about, carry, introduce
>> introduire
>> introduce, enter, insert, place, usher, weave
>> insérer
>> insert, introduce, slot, inset, infix
>> déposer
>> deposit, file, lodge, drop off, introduce, leave
>> faire entrer
>> introduce, admit, usher, take in, squeeze, show in
>> importer
>> import, matter, introduce
>> mettre au courant
>> update, acquaint, brief, inform, introduce, set scene

>>
>> due to this way too small delay, the FIFO has to buffer more and
>> more PADs.
>> So any DLS changes or new slides are more and more delayed - the same
>> thing that happened to Fabien, but just even worse, due to the only 1s
>> delay. Please try yourself ;-)
>>
>> --
>> 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>.
>> For more options, visit https://groups.google.com/d/optout.

--
Yoann QUERET
+33.6.62.61.99.40

[Fabien]

Hi Stefan,

So, if we are in AAC-LC with 48KHz with --PAD = 36, there will be permanently 14,4Kbps reserved for PAD, and therefore 14.4Kbps less for audio?

If we have an audio at 64Kbps, the audio has only one bitrate of 49.6Kbps?

Odr-AudioEnc only uses HE-AAC? AAC-LC is the old generation?

[Yoann QUERET]

Hi Fabien,

The PAD is dynamic. No bandwidth reserved.

If no PAD data to transmit, no bandwidth used, all is for audio.

About AAC, HE-AAC is an AAC profil, AAC-LC is a codec.

Profil AAC = Codec AAC-LC ( AAC with low complexity.)
Profil HE-AAC (AAC+) = Codec AAC-LC + SBR  (AAC with Spectral band replication)
Profil HE-AACv2 (eAAC+) = Codec AAC-LC + SBR + PS (AAC with Spectral band replication and Parametric Stereo)

SBR : https://en.wikipedia.org/wiki/Spectral_band_replication
PS : https://en.wikipedia.org/wiki/Parametric_Stereo

You can use different profil depending bitrate :
- AAC : for hight bitrate
- HE-AAC : for medium bitrate
- HE-AACv2 : for low bitrate

--
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.

-- 
Yoann QUERET
+33.6.62.61.99.40

[Fabien]

Thanks/Merci Yoann :-)

Understand. But if I have a lot of SLS, during the transmission time of the SLS, all the bandwidth will be used? If I take the example in my previous message: during the transmission time of the SLS, there will be a continuous stream of 14,4Kbps for PAD ? And when all PAD is transmitted, audio recover all its bandwidth until the next sending?

[Stefan Pöschel]

Salut Yoann,

Am 12.02.2018 um 22:09 schrieb Yoann QUERET:
> I did tests with the UNIFORM mode today, and it works very well.
>
> 1 new different DLS every 2 second even when an image is sent
> link : https://youtu.be/GSTTyUt6DgA

Great to hear that it works for you!

> Question :
>
> When i run odr-padenc without --remove-dls and have for example 5 files
> in the images direcotry (--dir), you try to send this 5 images files and
> refresh the images files list when you have finish to send it. right ?

Correct; the image file list is refreshed only after the five images
have been transmitted and the next image is going to be sent.

> If i remove an image file, before you refresh the list of images files,
> odr-padenc wait the sleep delay (--sleep) to try to send the next file,
> so is it possible to try to send the next image immedialty rather than
> wait the sleep delay ?

This is an interesting case. I think you're right: In this case, the
next _available_ file should be transmitted, instead of just the next
file - which possibly is not available (which leads to unnecessary delay).
I will modify the encoder as described; it will of course emit a warning
to the user if a file is no longer found.

Regards,
Stefan

[Stefan Pöschel]

Yes, this is correct. The PAD encoder tries to transmit the slide as
fast as possible. Of course in between DLS is inserted as well in
regular intervals (if used).

> --
> 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>.

[Stefan Pöschel]

Hello Yoann,

Am 12.02.2018 um 23:52 schrieb Stefan Pöschel:
>> If i remove an image file, before you refresh the list of images files,
>> odr-padenc wait the sleep delay (--sleep) to try to send the next file,
>> so is it possible to try to send the next image immedialty rather than
>> wait the sleep delay ?
>
> This is an interesting case. I think you're right: In this case, the
> next _available_ file should be transmitted, instead of just the next
> file - which possibly is not available (which leads to unnecessary delay).
> I will modify the encoder as described; it will of course emit a warning
> to the user if a file is no longer found.

This is now implemented in the "next" branch.

Note that the encoder gives up (until the sleep delay expires again)
when a slides dir re-scan doesn't result in any working slide, to
prevent an infinite loop.

Regards,
Stefan

[Fabien]

Hi Stefan,

I think it will solve a problem too: I have several SLS permanently in my SLS folder, and when I play a title that has a cover, I add a JPG with the cover in the SLS folder.
But also, it was necessary to wait for a complete second round of the SLS before seeing the cover to appear. This problem is similar?

How's it going? Before starting the SLS sending cycle, ODR-PadEnc list all files in folder? If yes in which order? ASC Alphabetical?

[Stefan Pöschel]

Hi Fabien,

this is not really related, as the recent change only affects files that
are to be transmitted, but not present. The case you describe is the
opposite: A file is present, but not (i.e. only later) transmitted.

The reason is that a folder is scanned and all found files/slides are
transmitted. If a new slide is added to the folder in between, nothing
happens. Only after all initially found files have been transmitted, the
complete procedure repeats - and only then your new cover is found.

The slides are alphabetically ordered according to their filename.

Regards,
Stefan

[Fabien]

And it would not be possible to have a command to "stop" the broadcast of the current SLS transmitting to "force" a new transmitting?

To avoid, for example, continuing to send the cover of a title that is already finished, because at the moment when the channel of SLS began to send itself, the title was at "the end of broadcast"

[Stefan Pöschel]

This is indeed a problem.

I just pushed a change that introduces the following feature:

When the next slide is going to be encoded and the slides dir contains a
file called "REQUEST_SLIDES_DIR_REREAD", the slides dir is re-read (and
this file deleted). The file can simply be created with:

touch REQUEST_SLIDES_DIR_REREAD

Note that the presence of this file does not interrupt any ongoing slide
transmission.

Regards,
Stefan

P.S.
I just noticed that I was wrong here:

> The slides are alphabetically ordered according to their filename.

The slides are added in alphabetical order to the slides cache. Thereby
they get a slide index assigned which is cached during the whole
ODR-PadEnc session. Newly discovered slides get higher IDs. So a new
slide will get a high ID.
But the transmission itself is done in slide index order, so a new slide
is only transmitted after already known slides (also after a slides dir
re-read).

So maybe it makes sense to change the behaviour to just transmit the
found slides in alphabetical order.
Any opinions on that?

[Matthias Brändli]

Hello all,

one question that should be kept in mind is the definition of
responsibilities of ODR-PadEnc and of the thing that generates the slides.

Up to now, I was thinking of two types of usage:

1) Fixed slides in a carousel (no erase option)
2) Dynamic slides created by an external tool (use erase option)

Now there is a trick to achieve both using this
REQUEST_SLIDES_DIR_REREAD, but I would prefer moving this responsibility
to the external slide generation tool [1]

What's your thought on this?

cheers
mpb

[1]
Does ODR-PadEnc use the same ID for a given slide, even if that slide
gets deleted and created again? What criteria must a slide satisfy to
get the same ID again?

[Fabien]

Thanks Stefan, It seems perfect to me!

Personally I have a PHP script that pushes the cover in the SLS directory as soon as the onair title changes, and at the same time I create in PHP a file "REQUEST_SLIDES_DIR_REREAD"

[Obinna Lex]

Hi Fabien,

Please how did you create a DLS text. Really need your help. Am presently working on a project.

Thanks,
Obinna