Author Topic: ICEcast and AAC streaming results in playback buffering (choppy audio)  (Read 537 times)

GTHvidsten

  • Posts: 23
When playing back an AAC stream streamed from the Un4seen.Bass.Misc.ICEcast class, the player starts buffering after a short while (1-10 minutes). This causes the audio to take very short pauses every 2-10 seconds making the playback unlistenable. Tested in Winamo, VLC, and Chrome.

Streaming MP3 to the same ICEcast server has no buffering/playback issues even after a long time (1 hour).

Both the Un4seen.Bass.Misc.EncoderFHGAACplus and Bass.Misc.EncoderCMDLN (with FFMPEG) encoders experience the same buffering/playback issues.
If I change to MP3 using Un4seen.Bass.Misc.EncoderLAME or Bass.Misc.EncoderCMDLN (still with FFMPEG), playback works just fine.

Seeing as this is an issue with multiple AAC encoders, and it's not an issue when using MP3 even with the same EncoderCMDLN (FFMPEG) I suspect there's something wrong with AAC in combination with ICEcast, but I can't for the life of me figure out what.

Any help would be appreciated.

BASS Version: 2.4.16.7
BASS Enc Version: 2.4.16.1
BASS Mixer Version: 2.4.11.1

Ian @ un4seen

  • Administrator
  • Posts: 24589
Have you set the AAC encoder to use a constant (rather than variable) bitrate? If not, try that. If that doesn't help, you could also try increasing the buffer length ("queue-size") in the Icecast config. Details on that and other config options are available here:

   https://icecast.org/docs/icecast-latest/config-file.html

You could also try playing other AAC Icecast streams with the same software for comparison (ie. see if they're affected too). A list of streams is available here (right-click the "Play" buttons to copy the URLs):

   http://dir.xiph.org/codecs/AAC
   http://dir.xiph.org/codecs/AAC+

GTHvidsten

  • Posts: 23
I can already play other AAC streams just fine.
I even have completely different software (SAMBC) that can stream AAC to the same Icecast server without any problems.
Seeing as other software can stream AAC streams to my Icecast server just fine, but the "ICEcast" class can't, I'm still inclined to blame "ICEcast" and not the server.

Ian @ un4seen

  • Administrator
  • Posts: 24589
OK. To help narrow down where the problem is, here's a version of the CAST example from the BASSenc package modified to use the BASSenc_AAC add-on:

   www.un4seen.com/stuff/cast-aac.exe

You can get the BASSenc_AAC add-on here:

   www.un4seen.com/stuff/bassenc_aac.zip

Please see if you can reproduce the problem when using them as the Icecast source.

GTHvidsten

  • Posts: 23
I'm sorry, but I don't know much about the CAST example. When I've downloaded the correct DLLs and try to start the application I get an error saying:

Quote
The application was unable to start correctly (0xc000007b).

When I try to run it from command prompt, nothing happens.

I used the x64 versions of bass.dll, bassenc.dll and bassenc_aac.dll
« Last Edit: 4 Aug '22 - 13:53 by GTHvidsten »

Ian @ un4seen

  • Administrator
  • Posts: 24589
The posted CAST-AAC.EXE is 32-bit, so please try again with the 32-bit DLLs.

GTHvidsten

  • Posts: 23
I got it working with 32-bit DLLs, and I don't experience any of the buffering issues when streaming to my Icecast server.
You might be onto something about VBR.
Both FFMPEG and EncoderFHGAACplus gives out VBR, even when specifying that it should be CBR. I can see the bitrate indicator in Winamp change when using both of these (with CBR settings). I couldn't see it when the application you posted streamed to the server, and I can't see it when streaming from SAMBC.

I tried changing to MP3 with VBR, and I haven't encountered any buffering issues there, so it might only be a problem with AAC

Still, I would expect the ICEcast class to be able to handle VBR AAC's, though.

Ian @ un4seen

  • Administrator
  • Posts: 24589
I think it's more likely to be the Icecast server or client that has issues with VBR data, as it changes their buffer durations. To eliminate it being client-specific, please try playing your stream with the precompiled NETRADIO.EXE example from the BASS package (C\BIN folder) and see if that's affected too.

Also check that you have the ICEcast class "UseBASS" property set to true. That should make it use BASSenc's casting support (like the CAST example does) rather than its own.

   www.bass.radio42.com/help/html/d32d5240-397e-3e64-a0a4-0ebd3176f929.htm

GTHvidsten

  • Posts: 23
As I mentioned in the original post I've already tried alternatives to Winamp, and they all suffered the buffering issue.

Also, the "UseBASS" property is already set to true.

Ian @ un4seen

  • Administrator
  • Posts: 24589
If you would like to try eliminating the ICEcast class and using BASSenc directly instead, you can do so by calling BASS_Encode_CastInit with the encoder handle (EncoderHandle). Please see the BASS_Encode_CastInit documentation for details on it.

GTHvidsten

  • Posts: 23
Of course, now that I'm debugging hard, I've hardly been able to recreate this issue. But out of the many runs I've had, the ICEcast class has had the problem 1-2 times, and BASS_Encode_CastInit has never had the problem. So it does seem more stable, and provides a bit cleaner code, so I'm keeping this.

Thanks for pointing me in that direction :)

I'll keep you updated if the issue appears with BASS_Encode_CastInit as well.

GTHvidsten

  • Posts: 23
And now it just happened with BASS_Encode_CastInit as well. To make matters worse, it also happened with CBR MP3 :(
« Last Edit: 7 Aug '22 - 19:11 by GTHvidsten »

Ian @ un4seen

  • Administrator
  • Posts: 24589
How are you feeding the encoder, eg. what are you using in the EncoderCMDLN constructor? If it's a recording channel, can you eventually reproduce the problem with the pre-compiled CAST example too?

GTHvidsten

  • Posts: 23
I'm feeding it with a Mixer that sequentially plays Flac channels.
I've turned on regular audio output (Initialize with -1) and when Icecast starts having this issue, playback is still perfectly fine from the speakers.

The last time it happened it helped to restart the Icecast service, but it mostly also helps to restart the application I'm developing that's using BASS... yet, as I've mentioned before, I've never experienced this issue using SAMBC with the same server, which makes me think there's SomethingTM happening in combination with BASS and Icecast. What, though, seems to be extremely hard to debug.

Ian @ un4seen

  • Administrator
  • Posts: 24589
Perhaps there are sometimes delays between the FLAC files being started, where nothing is being mixed/encoded/sent, eventually resulting in a buffer underrun? If you set a BASS_SYNC_STALL sync on the mixer (via BASS_ChannelSetSync), does it ever get triggered? And can you still reproduce the problem if you just loop a single FLAC file, ie. with the BASS_SAMPLE_LOOP flag set?