I'm running an icecast server (2.4.3) and experiencing a very long "time to first byte". It's strange because this does not seem to be occurring from players (like mplayer), but only when using HTML5 audio. It takes anywhere from 30 seconds to 120 seconds to start playing the audio.
I'm thinking it's not a buffering issue because I don't seem to be getting ANY bytes back during this time. For instance, if I run a curl command with the verbose flag:
~ben ~: curl http://radio.example.com:8000/radio.mp3 -v
* Trying XX.XX.XX.XXX...
* TCP_NODELAY set
* Connected to radio.example.com (XX.XX.XX.XXX) port 8000 (#0)
> GET /radio.mp3 HTTP/1.1
> Host: radio.example.com:8000
> User-Agent: curl/7.51.0
> Accept: */*
>
It will sit like this for at minimum 28 seconds before I see any bytes coming in. Conversely, if I run mplayer:
~ben ~: mplayer http://radio.example.com:8000/radio.mp3
MPlayer 1.3.0-4.2.1 (C) 2000-2016 MPlayer Team
Can't init Apple Remote.
Playing http://radio.example.com:8000/radio.mp3.
Resolving radio.example.com for AF_INET6...
Couldn't resolve name for AF_INET6: radio.example.com
Resolving radio.example.com for AF_INET...
Connecting to server radio.example.com[XX.XX.XX.XXX]: 8000...
Cache size set to 320 KBytes
Cache fill: 0.00% (0 bytes)
ICY Info: StreamTitle='';
Cache fill: 5.00% (16384 bytes)
ICY Info: StreamTitle='';
Cache fill: 10.00% (32768 bytes)
ICY Info: StreamTitle='';
Cache fill: 15.00% (49152 bytes)
ICY Info: StreamTitle='';
ICY Info: StreamTitle='';
Audio only file format detected.
==========================================================================
Requested audio codec family [mpg123] (afm=mpg123) not available.
Enable it at compilation.
Opening audio decoder: [ffmpeg] FFmpeg/libavcodec audio decoders
libavcodec version 57.24.102 (internal)
AUDIO: 44100 Hz, 2 ch, floatle, 128.0 kbit/4.54% (ratio: 16000->352800)
Selected audio codec: [ffmp3float] afm: ffmpeg (FFmpeg MPEG layer-3 audio)
==========================================================================
AO: [coreaudio] 44100Hz 2ch floatle (4 bytes per sample)
Video: no video
Starting playback...
It buffers and starts playing within a couple seconds.
Here are what I think are the relevant configs
<icecast>
<limits>
<clients>100</clients>
<sources>2</sources>
<queue-size>102400</queue-size>
<client-timeout>30</client-timeout>
<header-timeout>15</header-timeout>
<source-timeout>1</source-timeout>
<burst-size>943718</burst-size>
<mp3-metadata-interval>4096</mp3-metadata-interval>
</limits>
<mount>
<mount-name>/radio.mp3</mount-name>
<password>*****************</password>
<bitrate>128</bitrate>
<type>audio/mpeg</type>
<subtype>mp3</subtype>
<hidden>0</hidden>
<fallback-mount>/whitenoise.mp3</fallback-mount>
<fallback-override>1</fallback-override>
</mount>
</icecast>
I've tried this on a few different versions including 2.3.3, 2.3.3-kh-11, 2.4.0-kh4. I've gotten this to work properly with a kh branch in the past but I was not able to get the fallback mounts to work with the kh branch. I might just give up and try to go down that rabbit hole instead. I've also tried fiddling with all the of the burst and buffer configs but this problem doesn't seem to be related to those.
After exhausting my options on this, I just attempted to stream from another computer and noticed the problem was not happening. I asked some others to try it and they confirmed they were not seeing this problem on the stream. This led me to believe that the problem is somewhere on my computer (the streaming client in this case). I suspect that it's trying to upgrade the connection to TLS encrypted connection (this has happened with this domain before) but not sure. Either way, it's not a problem with icecast.