[Icecast] IceCast KH - question

Tue Jun 11 07:29:37 UTC 2013

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 interface

That 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