Open GoogleCodeExporter opened 9 years ago
Got the same issue on one of my servers I think. We use darkice to stream
MP3-data to a shoutcast-server (at the moment) and after some time, the
bitstream gets corrupted and does not recover! Right now having debian lenny
with darkice 1.0 and libmp3lame installed via apt. Will try to use
libmp3lame-HEAD and darkice-HEAD as soon as I may take down the stream (not
possible right now)
Original comment by kri...@gmail.com
on 1 Nov 2010 at 7:12
forgot: Time after streams gets glitchi varies from 10 minutes to several hours
here. Server is not really busy, CPU-load without darkice is about 10-20%
(total of 2 cores (200% is full load))
Original comment by kri...@gmail.com
on 1 Nov 2010 at 7:13
I'm also running a dual core Linux box, with a similar system load.
In case it matters it an older 3.0ghz AMD Athlon 64 X2 6000+, 2GB RAM.
On darkice, I'm using ALSA with a shoutcast server with 44100/16/2 on the input
settings.
Shoutcast settings are 56k/22050hz CBR MP3 with 1.0 quality.
Original comment by Liberato...@googlemail.com
on 1 Nov 2010 at 7:31
We are streaming from JACK (44.1kHz) to one shoutcast-server (192kbit/s) and
one icecast-server (MP3 192kbit/s, MP3 48kbit/s, Vorbis 128KBit/s, Vorbis
48kbit/s).
After some time, the shoutcast and the icecast MP3 192 start to get glitchi,
all other streams are fine.
Darkice 1.0: Stream gets glitchy and does not recover
Darkice SVN HEAD: Stream gets glitchy and does not recover
Darkice 0.19: Stream gets glitchy but does recover (glitches are hardly notable)
Original comment by kri...@gmail.com
on 3 Nov 2010 at 11:05
I'm not sure if the project is still live, but just in case - I have tried four
different servers, both single and dual core, and AMD and Intel, and using
Darkice 1.0 (ubuntu install) and 1.1 (compiled), 128k & 96k bitrates, icecast
and shoutcast and MP3 quality from 0.8 to 0.4
We are having the same issues - the stream is stable for anything from a couple
of hours up to a couple of days and then it starts glitching, almost as if the
buffer is corrupted. Restarting either darkice or the DNAS will return the
stream to a stable state, until it glitches again.
Original comment by alcham...@googlemail.com
on 20 Apr 2012 at 6:10
I have a similar issue with Raspberry Pi and Darkice 1.2. After Darkice has
expericed one buffer overrun it starts producing them regularly every 20-30
seconds.
It can be reproduced by restricting outbound network traffic in a router for a
moment so that the buffer is filled, and after the first buffer overrun the
restriction can be removed.
To my understanding the problem is not about individual platforms or computing
capacity, but its caused by the flawed healing mechanisms of the buffer.
Original comment by kulon...@gmail.com
on 10 Jan 2014 at 12:24
Original issue reported on code.google.com by
Liberato...@googlemail.com
on 21 Oct 2010 at 1:58