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