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

[Andy Baxter]

On Mon, 18 Oct 2004 17:41:59 +0100, Karl Heyes wrote:

> On Mon, 2004-10-18 at 16:06, 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.
> 
> Are you running with realtime privileges, for this you need to start as
> root if you want that. Even with realtime privileges there may be odd
> cases where the scheduling latency is a bit too high, it all depends on
> the drivers and kernel version but the current state is not that bad and
> getting better.

I'm using the realtime-lsm module with the 2.6 kernel, loaded with gid=29,
which is the 'audio' group on my system. This seems to be working OK, but
I'm thinking of switching to the 2.4 patched kernel instead.

>> 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.
> 
> xrun is just when the input thread cannot get scheduled quickly enough,
> this may be resolved enabling realtime.

OK.

>> 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.
> 
> As already mentioned it may be better using a different approach (eg
> jackEQ). The ices package itself will also allow for defining multiple
> input sections, not for mixing but for cascading in a round robin
> fashion (switchable on input ending or USR2 signal).
> 

maybe - if I can get it working, this setup would be good because it means
the sources can be switched under program control. (E.g. switching to a
repeat of the day's shows at the end of every day.) switching on USR2
sounds like a recipe for losing track of where it's got to in the round
robin, unless there's some way to signal it with a definite source name.