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

[Karl Heyes]

On Mon, 2004-11-01 at 03:23, andy wrote:

> 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.

Can you send me the full 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

Thats not emptying data quick enough out of the ring buffer.
...

> 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.

If you have updated the im_jack file as I said privately (from svn) then
a sizing bug is fixed.  Whether that will resolve the problem is hard to
say as I've had little feedback.

>From the sound of it the problem is either this sizing bug (may be it's
above a maximum tolerance for you) or a scheduling one.

> 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.

If the ring buffer becomes full, then it doesn't matter if you try to
continue or not, it will loose audio. At the moment it shuts down the
input on such cases but in theory it could introduce a skip.

karl.