Hello Thomas and Karl, thank you for your answer and time. We've tested with several listeners and different connections, using WinAmp and JW Player. For about 15 minutes, everything is ok. After 15-18 minutes, WinAmp starts do blink that "red square" (packet loss or instability), and after about 20 minutes sounds starts to "pop", with small cuts, and then starts to cut a lot. I think the problem is progressive: more time, more cuts. We use SAM Broadcaster to encode AAC+ HE 48k. We're using the latest IceCast KH version, Win32. Other datail: all users have always "Lag: 0" on Admin interface If you want to listen what happens, if you can and have time (very appreciated) the stream is http://mp4.livemix.com.br/livemix - if possible using WinAmp. Wait about 15-20 minutes to see the problem. Any ideas I really appreciate, because we have about 100-200 listeners at same time we really don't know what to do :( Thanks a lot, Rogerio> On 06/06/13 17:13, Live Mix - Arvy wrote: >> Hi there, >> >> we use IceCast KH on our webradio, no commercial. We have an issue that >> we dont know where to look. When listening using WinAmp (but in other >> players too like JW Player), after 70 or 90 minutes, we realize that the >> "green square" on top of WinAmp becomes a "red square". About 60 minutes >> after start, sometimes the "red square" blinks, and then more >> frequently. It happens with different internet connections and >> providers. Until 60 minutes, the broadcast is perfect. >> >> Can you give me an idea where to look or solve this issue? It's related >> to Icecast, or encoder, or internet connection, etc? > > My initial guess would be the encoder sending rate being mismatched > with the samplerate. When a player reports an issue it needs to be > clear on what it is relating to, but I suspect it will be down to a > starvation of the incoming data. > > Any issue within icecst here would should as an increased lag value > for that listener on the admin page, icecast will send a lot faster > than the source but is still subject to certain limits like CPU or may > be a per-mount limit (limit-rate is set). > > If it is affecting multiple listeners at different locations at a > consistent offset into the stream then the sending rate from the > source is suspect. May be a 44k/48k mismatch or a bad clock on the > source client. > > karl. > >Live Mix www.livemix.com.br
Hi, On 06/10/2013 04:43 PM, Live Mix - Arvy wrote:> Hello Thomas and Karl, thank you for your answer and time. > [?] > We use SAM Broadcaster to encode AAC+ HE 48k. We're using the latest > IceCast KH version, Win32.As I'm neither familiar with the KH version, nor with SAM I won't be of much help.> Other datail: all users have always "Lag: 0" on Admin interfaceThat doesn't need to be a problem, but without full understanding it's hard to say.> If you want to listen what happens, if you can and have time (very > appreciated) the stream is http://mp4.livemix.com.br/livemix - if > possible using WinAmp. Wait about 15-20 minutes to see the problem.I've had this stream now running for about 1800s and have observed one peculiar thing, the cache-fill went constantly down from an initial 20% to now about 3%. I let it run a bit longer and this is what I get: Cache empty, {?} A:1938.8 (32:18.8) of 0.0 (unknown) 1.4% 0% I suspect that Winamp is signalling a low buffer by that red square. So, yes, that's why the players drop, the bitrate is a tiny bit lower than the playback rate. This means that over time a player will deplete the cache and inevitably either rebuffer or start to stutter. You can also force this to happen immediately if you disable buffering completely. As to the root cause I can only speculate it could be some KH specific feature or it can be that your source client has a problem. I can only repeat that it would be beneficial to try (maybe not on your production system) against vanilla Icecast. This would help narrow down the source of your problem. There is a windows build available of 2.4 beta3: http://downloads.xiph.org/releases/icecast/icecast_win32_2.4_beta3.zip For further information, see here: http://lists.xiph.org/pipermail/icecast-dev/2013-April/002157.html> Any ideas I really appreciate, because we have about 100-200 listeners > at same time we really don't know what to do :(Personally I'd recommend to look at gradually switching to streaming Opus, it is at least as efficient as AAC+ and it can be also played back natively in Firefox and Opera using the <audio> HTML tag. Also /please/ subscribe to the mailing list. http://lists.xiph.org/mailman/listinfo/icecast Cheers Thomas> >> On 06/06/13 17:13, Live Mix - Arvy wrote: >>> Hi there, >>> >>> we use IceCast KH on our webradio, no commercial. We have an issue that >>> we dont know where to look. When listening using WinAmp (but in other >>> players too like JW Player), after 70 or 90 minutes, we realize that the >>> "green square" on top of WinAmp becomes a "red square". About 60 minutes >>> after start, sometimes the "red square" blinks, and then more >>> frequently. It happens with different internet connections and >>> providers. Until 60 minutes, the broadcast is perfect. >>> >>> Can you give me an idea where to look or solve this issue? It's related >>> to Icecast, or encoder, or internet connection, etc? >> My initial guess would be the encoder sending rate being mismatched >> with the samplerate. When a player reports an issue it needs to be >> clear on what it is relating to, but I suspect it will be down to a >> starvation of the incoming data. >> >> Any issue within icecst here would should as an increased lag value >> for that listener on the admin page, icecast will send a lot faster >> than the source but is still subject to certain limits like CPU or may >> be a per-mount limit (limit-rate is set). >> >> If it is affecting multiple listeners at different locations at a >> consistent offset into the stream then the sending rate from the >> source is suspect. May be a 44k/48k mismatch or a bad clock on the >> source client. >> >> karl. >> >> > Live Mix > www.livemix.com.br > > _______________________________________________ > Icecast mailing list > Icecast at xiph.org > http://lists.xiph.org/mailman/listinfo/icecast >
If this occurs with multiple listeners on different computers then I would also suspect the problem is with the playback speed of the soundcard, which in your case dictates the encoding speed. Each soundcard often utilizes a crystal to obtain a frequency for determining playback speed, and no crystal can be cut exactly the same so there will be slight variances in speeds, usually undetectable to the human ear. Your tracks are likely playing slightly slower on your automation PC, perhaps losing 200ms every minute for example. But your listeners are playing back at normal speed or whatever there soundcard determines. The listeners playback buffer in their player will be slowly depleting at 200ms per minute until after some time the buffer is empty and it needs to pre-buffer more audio which usually causes a pause in playback. The reverse can also be true where the encoding PC is encoding slightly faster than 44100 samples per second and the playback PC buffer will over-fill causing it to discard some audio every so often. Ideally the stream playback software should detect where the buffer is depleting or increasing steadily and resample the audio to playback at a slower or faster speed. I'm not aware of any that do that. We have done something similar in our radio broadcasting software when sending the audio to 2 soundcards, as we found the same issue with 2 soundcards playing at different speeds. Regards, Ross Levis StationPlaylist.com -----Original Message----- From: icecast-bounces at xiph.org [mailto:icecast-bounces at xiph.org] On Behalf Of Live Mix - Arvy Sent: Tuesday, 11 June 2013 4:43 AM To: Karl Heyes Cc: icecast at xiph.org Subject: Re: [Icecast] IceCast KH - question Hello Thomas and Karl, thank you for your answer and time. We've tested with several listeners and different connections, using WinAmp and JW Player. For about 15 minutes, everything is ok. After 15-18 minutes, WinAmp starts do blink that "red square" (packet loss or instability), and after about 20 minutes sounds starts to "pop", with small cuts, and then starts to cut a lot. I think the problem is progressive: more time, more cuts. We use SAM Broadcaster to encode AAC+ HE 48k. We're using the latest IceCast KH version, Win32. Other datail: all users have always "Lag: 0" on Admin interface If you want to listen what happens, if you can and have time (very appreciated) the stream is http://mp4.livemix.com.br/livemix - if possible using WinAmp. Wait about 15-20 minutes to see the problem. Any ideas I really appreciate, because we have about 100-200 listeners at same time we really don't know what to do :( Thanks a lot, Rogerio> On 06/06/13 17:13, Live Mix - Arvy wrote: >> Hi there, >> >> we use IceCast KH on our webradio, no commercial. We have an issue >> that we dont know where to look. When listening using WinAmp (but in >> other players too like JW Player), after 70 or 90 minutes, we realize >> that the "green square" on top of WinAmp becomes a "red square". >> About 60 minutes after start, sometimes the "red square" blinks, and >> then more frequently. It happens with different internet connections >> and providers. Until 60 minutes, the broadcast is perfect. >> >> Can you give me an idea where to look or solve this issue? It's >> related to Icecast, or encoder, or internet connection, etc? > > My initial guess would be the encoder sending rate being mismatched > with the samplerate. When a player reports an issue it needs to be > clear on what it is relating to, but I suspect it will be down to a > starvation of the incoming data. > > Any issue within icecst here would should as an increased lag value > for that listener on the admin page, icecast will send a lot faster > than the source but is still subject to certain limits like CPU or may > be a per-mount limit (limit-rate is set). > > If it is affecting multiple listeners at different locations at a > consistent offset into the stream then the sending rate from the > source is suspect. May be a 44k/48k mismatch or a bad clock on the > source client. > > karl. > >Live Mix www.livemix.com.br _______________________________________________ Icecast mailing list Icecast at xiph.org http://lists.xiph.org/mailman/listinfo/icecast
This is not a problem with SAM or the KH builds. I recently replied to a similar question. It has everything to do with "the man with two clicks doesn't know what time it is." I will find the reply and reply again with it if you want. -Greg. Orban Sent from Apple iTelePhone 5 StreamS HiFi Radio iPhone App High Performance HE-AAC On Jun 10, 2013, at 23:43, Live Mix - Arvy <arvy2013 at livemix.com.br> wrote:> Hello Thomas and Karl, thank you for your answer and time. > > We've tested with several listeners and different connections, using > WinAmp and JW Player. For about 15 minutes, everything is ok. After > 15-18 minutes, WinAmp starts do blink that "red square" (packet loss or > instability), and after about 20 minutes sounds starts to "pop", with > small cuts, and then starts to cut a lot. I think the problem is > progressive: more time, more cuts. > > We use SAM Broadcaster to encode AAC+ HE 48k. We're using the latest > IceCast KH version, Win32. > > Other datail: all users have always "Lag: 0" on Admin interface > > If you want to listen what happens, if you can and have time (very > appreciated) the stream is http://mp4.livemix.com.br/livemix - if > possible using WinAmp. Wait about 15-20 minutes to see the problem. > > Any ideas I really appreciate, because we have about 100-200 listeners > at same time we really don't know what to do :( > > Thanks a lot, > Rogerio > > > >> On 06/06/13 17:13, Live Mix - Arvy wrote: >>> Hi there, >>> >>> we use IceCast KH on our webradio, no commercial. We have an issue that >>> we dont know where to look. When listening using WinAmp (but in other >>> players too like JW Player), after 70 or 90 minutes, we realize that the >>> "green square" on top of WinAmp becomes a "red square". About 60 minutes >>> after start, sometimes the "red square" blinks, and then more >>> frequently. It happens with different internet connections and >>> providers. Until 60 minutes, the broadcast is perfect. >>> >>> Can you give me an idea where to look or solve this issue? It's related >>> to Icecast, or encoder, or internet connection, etc? >> >> My initial guess would be the encoder sending rate being mismatched >> with the samplerate. When a player reports an issue it needs to be >> clear on what it is relating to, but I suspect it will be down to a >> starvation of the incoming data. >> >> Any issue within icecst here would should as an increased lag value >> for that listener on the admin page, icecast will send a lot faster >> than the source but is still subject to certain limits like CPU or may >> be a per-mount limit (limit-rate is set). >> >> If it is affecting multiple listeners at different locations at a >> consistent offset into the stream then the sending rate from the >> source is suspect. May be a 44k/48k mismatch or a bad clock on the >> source client. >> >> karl. > > Live Mix > www.livemix.com.br > > _______________________________________________ > Icecast mailing list > Icecast at xiph.org > http://lists.xiph.org/mailman/listinfo/icecast >
Simple streaming is fundamentally flawed this way. "The man with two clocks, does not know what time it is." Your source is clocked from one crystal in your source sound card, and played back on the basis of the clock crystal in the client sound card. There is nothing to say or keep these crystals locked to the same exact frequency, which is REQUIRED to maintain no clock drift. Unless the player software specifically deals with modulating a sample-rate converter, which most, if any, players do not, sooner or later, the stream will either over or under buffer and cause unpredictable results. The amount of time it will take for this problem to actually occur will be determined by the difference in clock frequency between the source and client clocks. So, "your mileage will vary." There is currently no way to send synchro clock in a SHOUTcast or Icecast2 stream that I am aware of. Even if there was, the client player would need to support this specifically. The easiest way to deal with this with the current architecture, is write a player that can approximate clock recovery. This will only be an approximation, but better than nothing at all. -greg. Orban -----Original Message----- From: icecast-bounces at xiph.org [mailto:icecast-bounces at xiph.org] On Behalf Of "Thomas B. R?cker" Sent: Monday, June 10, 2013 23:17 To: icecast at xiph.org Cc: Live Mix - Arvy Subject: Re: [Icecast] IceCast KH - question Hi, On 06/10/2013 04:43 PM, Live Mix - Arvy wrote:> Hello Thomas and Karl, thank you for your answer and time. > []> We use SAM Broadcaster to encode AAC+ HE 48k. We're using the latest > IceCast KH version, Win32.As I'm neither familiar with the KH version, nor with SAM I won't be of much help.> Other datail: all users have always "Lag: 0" on Admin interfaceThat doesn't need to be a problem, but without full understanding it's hard to say.> If you want to listen what happens, if you can and have time (very > appreciated) the stream is http://mp4.livemix.com.br/livemix - if > possible using WinAmp. Wait about 15-20 minutes to see the problem.I've had this stream now running for about 1800s and have observed one peculiar thing, the cache-fill went constantly down from an initial 20% to now about 3%. I let it run a bit longer and this is what I get: Cache empty, { } A:1938.8 (32:18.8) of 0.0 (unknown) 1.4% 0% I suspect that Winamp is signalling a low buffer by that red square. So, yes, that's why the players drop, the bitrate is a tiny bit lower than the playback rate. This means that over time a player will deplete the cache and inevitably either rebuffer or start to stutter. You can also force this to happen immediately if you disable buffering completely. As to the root cause I can only speculate it could be some KH specific feature or it can be that your source client has a problem. I can only repeat that it would be beneficial to try (maybe not on your production system) against vanilla Icecast. This would help narrow down the source of your problem. There is a windows build available of 2.4 beta3: http://downloads.xiph.org/releases/icecast/icecast_win32_2.4_beta3.zip For further information, see here: http://lists.xiph.org/pipermail/icecast-dev/2013-April/002157.html> Any ideas I really appreciate, because we have about 100-200 listeners > at same time we really don't know what to do :(Personally I'd recommend to look at gradually switching to streaming Opus, it is at least as efficient as AAC+ and it can be also played back natively in Firefox and Opera using the <audio> HTML tag. Also /please/ subscribe to the mailing list. http://lists.xiph.org/mailman/listinfo/icecast Cheers Thomas> >> On 06/06/13 17:13, Live Mix - Arvy wrote: >>> Hi there, >>> >>> we use IceCast KH on our webradio, no commercial. We have an issue >>> that we dont know where to look. When listening using WinAmp (but in >>> other players too like JW Player), after 70 or 90 minutes, we >>> realize that the "green square" on top of WinAmp becomes a "red >>> square". About 60 minutes after start, sometimes the "red square" >>> blinks, and then more frequently. It happens with different internet >>> connections and providers. Until 60 minutes, the broadcast is perfect. >>> >>> Can you give me an idea where to look or solve this issue? It's >>> related to Icecast, or encoder, or internet connection, etc? >> My initial guess would be the encoder sending rate being mismatched >> with the samplerate. When a player reports an issue it needs to be >> clear on what it is relating to, but I suspect it will be down to a >> starvation of the incoming data. >> >> Any issue within icecst here would should as an increased lag value >> for that listener on the admin page, icecast will send a lot faster >> than the source but is still subject to certain limits like CPU or >> may be a per-mount limit (limit-rate is set). >> >> If it is affecting multiple listeners at different locations at a >> consistent offset into the stream then the sending rate from the >> source is suspect. May be a 44k/48k mismatch or a bad clock on the >> source client. >> >> karl. >> >> > Live Mix > www.livemix.com.br > > _______________________________________________ > Icecast mailing list > Icecast at xiph.org > http://lists.xiph.org/mailman/listinfo/icecast >_______________________________________________ Icecast mailing list Icecast at xiph.org http://lists.xiph.org/mailman/listinfo/icecast
On 11/06/13 07:16, "Thomas B. R?cker" wrote:> Hi,>> Other datail: all users have always "Lag: 0" on Admin interface > > That doesn't need to be a problem, but without full understanding it's > hard to say.that is just the difference between the latest source offset and client offset, at 0, just like on the main trunk, the listener is at the latest point on the queue. Simply means that there is no lag on the icecast to listener link> I've had this stream now running for about 1800s and have observed one > peculiar thing, the cache-fill went constantly down from an initial 20% > to now about 3%. > I let it run a bit longer and this is what I get: > > Cache empty, {?} > A:1938.8 (32:18.8) of 0.0 (unknown) 1.4% 0% > > I suspect that Winamp is signalling a low buffer by that red square. > So, yes, that's why the players drop, the bitrate is a tiny bit lower > than the playback rate. This means that over time a player will deplete > the cache and inevitably either rebuffer or start to stutter. You can > also force this to happen immediately if you disable buffering completely. > As to the root cause I can only speculate it could be some KH specific > feature or it can be that your source client has a problem.saw exactly the same thing yesterday and the stats for the incoming bitrate indicate a slightly lower than expected bitrate Just for completeness, the sam is apparently transcoding from files, not live input and is also within virtualbox, the icecast is on not within a VM. While I don't know for sure, I suspect sam is probably using the VB clock for regulating the stream and if there is some issue on drift then that would account for it. karl.