ni2http: generated AAC audio streams playing too slow

[nanosonde]

Hi!

I am using the following command line to generate the live audio streams: ./eti-cmdline-rawfiles -F ./testpipe -O - | ~user/rtlsdr/eti-tools/ni2http -c ~user/rtlsdr/eti-tools/ni2http.conf

The ni2http output is:

Period = 8000
ensemble Radio fuer NRW   detected
program ( 1)     WDR 5                   D395 is in the list
program ( 2)     WDR 3                   D393 is in the list
program ( 3)     1LIVE                   D391 is in the list
program ( 4)     WDR 2                   D392 is in the list
program ( 5)     WDR 4                   D394 is in the list
program ( 6)     1LIVE diGGi             DF91 is in the list
program ( 7)     WDRcosmo                D496 is in the list
program ( 8)     KinderRadioKanal        DF95 is in the list
program ( 9)     VERA                    DF92 is in the list
program (10)     Domradio                109D is in the list
program (11)     WDR Event               DF96 is in the list
there might be a DAB signal here
still at most 10seconds to wait
yes, here we go
Handling ensemble Radio fuer NRW  until you quit
INFO:  channels: 2timated snr:  8, fibquality 100
INFO:  sid[54161]: channel_map[0] = channel[0]
INFO:  Writing to: /tmp/einlive.mp4a
INFO:  sid[54162]: channel_map[414] = channel[6]
INFO:  connecting to: http://localhost:8000/r2
INFO:  2 channels will be streamed
ERROR: DAB+ firecrccheck: ERROR
ERROR: DAB+ firecrccheck: ERROR
ERROR: DAB+ firecrccheck: ERROR
ERROR: DAB+ firecrccheck: ERROR
DAB+ errors: 1  estimated snr:  8, fibquality 100

If I play the above generated file /tmp/einlive.mp4a with VLC, it says 48 kHz sampling rate and AAC with SBR. From the DAB+ radio software "welle.io" I know that at least the sampling rate of 48 kHz is correct for this station. I am not sure about SBR.

Thay playback sounds like it is playing a little bit to slow. Voices and music are deeper in terms of frequencies.

The input raw file of eti-cmdline-rawfiles is a pipe. The pipe is fed by "nc > ./testpipe

The DAB+ radio software "welle.io" plays fine with the same RTL_TCP server.

So do you have any idea what the reason might be for this?

[nanosonde]

Any idea what's wrong? Is the ADTS header wrong and does not match the contained AAC stream?

[ghost]

Hello,

I suspect that it might be an issue with the AAC decoder in VLC rather than ni2http. DAB+ is slightly unusual in that it uses a 960 length transform. Most other applications for AAC use 1024.

You could try to wget the stream and pipe it to the FDK AAC decoder and verify the output from that as it definitely plays nice with 960 FFT.

Best regards,

Rash.

On 25 Sep 2017 18:07, "chrwick" notifications@github.com wrote:

Any idea what's wrong? Is the ADTS https://wiki.multimedia.cx/index.php/ADTS header wrong and does not match the contained AAC stream?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/piratfm/eti-tools/issues/10#issuecomment-331947730, or mute the thread https://github.com/notifications/unsubscribe-auth/AIbPH9yFj6kdlgzLHfqxnFm5GLbNaQGjks5sl93mgaJpZM4PgjHv .

[JvanKatwijk]

See previous comment. What happens when you run qt-dab or dab-cmdline program with that input

[piratfm]

Hi,

ADTS itselve does not provide any logic to inform player that this stream is AAC960. Also, when this tool been created, the players don't accept additional PCE-element that can be used in ADTS stream (to inform that we have 960 samples per frame), so the only way to play DAB+ streams - is to pretend that it's having 1024 samples per frame.

But things changed since 16 July 2017. There is a patch for ffmpeg, which adds AAC960 decoding: https://github.com/FFmpeg/FFmpeg/commit/dbc9a8f21f92d0613142ea23bb836356fc41de38

So we can try now to add PCE element after each ADTS header. So new players, which use fresh libavcodec will decode DAB+ streams properly. But in such case: old applications will not play that streams at all.

[nanosonde]

Hi! Thanks for giving the detailed answers describing the technical issues involved concernig the difference between usual AAC streams and the DAB+ AAC stream.

Meanwhile I have added a class to the console version of dablin which saves the DAB+ AAC stream to a file instead of decoding it. Each AAC frame is put into an ADTS packet similiar to ni2http. The resulting file has the same issue as ni2http: it is playing to slow, voices are slower and deeper. (Tested with VLC-2.2.6)

From your comments above, I understand that there is no way to get old players working with such streams easily or maybe not at all.

My usecase is that I would like to generate the radio stations streams locally for my Sonos setup which I have all around in the house. As my internet connection is sometimes not that stable, it is a pain to listen to internet radio stations with gaps of several seconds.

ni2http would have been the perfect solutions to this, because no transcoding would have been required. It is really a pitty that AAC causes so much trouble here.

@piratfm: concerning "... so the only way to play DAB+ streams - is to pretend that it's having 1024 samples per frame..." Might this be a solution for my problem? Could you please elaborate what needs to be done to pretend this to older players?

[nanosonde]

Just a remark: Sonos is known for having ancient software on the Sonos speakers. So recent activities around FFmpeg will probably not help that much.

[nanosonde]

This ticket also describes the issue very detailed.

[JvanKatwijk]

If you are interested, I'll add an option to the dab-library (i.e. dab-cmdline) to emit aac frames directly. Of course they need an adapted player since - as already mentioned, they give 960 rather than 1024 samples per frame.

[nanosonde]

Ok. I think you can close the issue.

I will just transcode to received AAC stream to MP3:

./eti-cmdline-rawfiles -F ~user/rtlsdr/inputpipe -O - | ~user/rtlsdr/dablin/build/src/dablin -s 0xd392 -p | ffmpeg -f f32le -acodec pcm_f32le -ac 2 -ar 48000 -i pipe:0 -f mp3 -ac 2 -ar 48000 -b:a 320k - |  ezstream -c ~user/ezstream_stdin_mp3.xml

This seems to work very well. I was also able to stream multiple radio stations from one eti-cmdline instance by using the "tee" command to replicate the ETI stream multiple times by using multiple pipes.

JvanKatwijk: Thanks for the offer concerning the option in dab-cmdline, but I will either dab-cmdline or dablin do the work and just use the PCM output to feed FFmpeg.

It is really sad that re-encoding the DAB+ streams is necessary for old players.

[basicmaster]

It is possible to signalling the 960 samples/frame in the LATM/LAOS format of AAC, which is streamable. Since v1.9.0 DABlin supports to output this format, so you could replace -p by -u and get rid of the re-encoding. What this means for ezstream is a different question though.

[antonioag95]

Is there any update about this? I'm experiencing the same issue. Thanks

[JvanKatwijk]

an upload of what?

Op zo 10 jan. 2021 om 20:39 schreef antonioag95 notifications@github.com:

Is there any update about this? I'm experiencing the same issue. Thanks

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/piratfm/eti-tools/issues/10#issuecomment-757531379, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACCPHQAW6R4NPW5JLS5JYXLSZH65JANCNFSM4D4CGHXQ .

-- Jan van Katwijk

[antonioag95]

An update about how to solve this issue. I'm experiencing the same issue on iOS and desktop computers.

[andimik]

Jan, if you login to GitHub you will see the complete history of this issue.

I guess you had no idea what he was talking about ...