[Icecast] Re: ices-kh dropping jack ports unexpectedly

[andy]

On Sun, 31 Oct 2004 22:32:17 +0000, andy wrote:

> On Mon, 18 Oct 2004 16:06:00 +0100, Andy Baxter wrote:
> 
>> I've been having a problem where ices-kh (the jack'ified version)
>> disconnects from its jack input source unexpectedly. This happens mainly
>> while other jack clients are being started/stopped, or
>> connected/disconnected, but also at other times (e.g. switching between
>> different X sessions). I'm planning to do a bit more work on tuning up the
>> jack setup to see if I can get rid of the problem that way, but it would
>> be good to know in the meantime if this is a known bug, and whether there
>> is anything I can do about it.
>> 
>> It happened just now when I connected two other jack sources. There were
>> two xruns at the same time, of 0.8 and 1.8 msecs, so I'm guessing this
>> happens when there is an xrun. I've tried increasing the client timeout to
>> 1000 msec, but this doesn't help. I can't increase the buffer size any
>> more - it's at 2048 and increasing it to 4096 stops ices from starting at
>> all.
>> 
>> The setup I'm working with is an ecasound session relaying audio between
>> its input and output ports, with its output connected to all the ices
>> clients for the different streams we're running. Then I'm
>> switching the ecasound input between different stream sources (line in,
>> recorded audio, http relay etc.) I want to be able to do this switching
>> without breaking the stream, which is why I've set things up this way.
> 
> I've been testing this some more and the ices logs are showing a
> ringbuffer full error at the time the port drops. I looked through the
> source and the 'sleep time' parameter seems to have something to do with
> setting the ring buffer size. I've tried recompiling the im_jack module
> with the line:
> 
> rb_size=(size_t)((s->sleep / 2000.0 ) * ......
> 
> changed to ... s->sleep / 1000.0
> 
> I'm running another test at the moment, but it would be good to know
> whether this is actually likely to help, and if it's going to have any
> other effects on the way ices works (apart from increasing the stream
> latency.)
> 
> I'll let you know how the test goes.

I just had a look at it and it's still dropping ports - I set a test
running which has ices-kh running from an ecasound process which is
connected to a new source every 10 minutes, and after about 3 hours it had
lost the jack port connection to ecasound.

this is the bit from the log:

2004-11-01  01:28:09] DBUG stream/_output_oggpacket seen new stream, better get headers
[2004-11-01  01:28:09] DBUG stream/_output_oggpacket Clearing output info/comment settings
[2004-11-01  01:28:09] DBUG stream/_output_oggpacket samplerate is 44100, channels is 2
[2004-11-01  01:28:09] DBUG om_shout/output_ogg_shout initialising output stream
[2004-11-01  01:44:05] EROR input-jack/jack_callback_process ringbuffer full
[2004-11-01  01:44:05] INFO input/input_loop Closing input module
[2004-11-01
  01:44:05] DBUG input-jack/jack_close_module closing JACK module
[2004-11-01  01:44:05] DBUG input/open_next_input_module checking module 1
[2004-11-01  01:44:05] INFO input-jack/jack_open_module Registering as ices64:in_1,ices64:in_2

[2004-11-01  01:44:05] DBUG input-jack/jack_open_module creating 2 ringbuffers, one per channel, of 81920 bytes each
[2004-11-01  01:44:05] INFO input-jack/jack_open_module Channels 2 / Samplerate 48000
[2004-11-01  01:44:05] DBUG input-jack/jack_read metadata updates flagged
[2004-11-01  01:44:05] INFO metadata/metadata_thread_signal Updating metadata with 9 comments

I think the problem is that ices is losing the jack connection because of
an xrun, trying to recover by recreating the jack port, but then ices
doesn't know which other clients were connected to it, so when the new
port is created it has no connections.  I could get round this by using
jack_lsp to monitor the ports and reconnect ices when it drops, but I
would rather not do that if there's a better way to do it. Another way
might be to be able to tell the ices jack client which ports it should
connect to on startup, and then have it
reconnect itself when it makes the new port? If you have any idea why ices
is more sensitive to xruns than the other jack programs I'm using, that
would be a help as well.

I've just tried rewriting the im-jack module so it doesn't shutdown when
the ringbuffer fills up (but still logs the error), which ought to solve
the problem (I'd rather have occasional breaks in the audio than lose
the connection altogether) but maybe isn't the best way to do things.