similar to: ices-kh dropping jack ports unexpectedly

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

On Mon, 18 Oct 2004 16:15:44 +0100, EvilOverlord wrote: >> 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

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

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

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

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

I'm running ices-kh to stream from jack at 64kbps, and also using oggenc (with ecasound via jack) to record the audio to disk at the same time. This is also running at 64kbps. ices is using virtually no cpu (0.0%), but oggenc is using 15-16%. I can't see why there should be such a difference - both are recording the same audio stream in real time at the same bitrate. oggenc is getting its

I'm running ices-kh to stream from jack at 64kbps, and also using oggenc (with ecasound via jack) to record the audio to disk at the same time. This is also running at 64kbps. ices is using virtually no cpu (0.0%), but oggenc is using 15-16%. I can't see why there should be such a difference - both are recording the same audio stream in real time at the same bitrate. oggenc is getting its

hello, I've just got ices-kh60 running with jack. It's working OK apart from a problem where the latency on the stream creeps up from about 15-20 secs to around 7 minutes. The stream plays OK, but the audio coming out is 7 minutes behind what goes in. I'm not sure how this can be happening, seeing as I don't think there are any buffers that long in the system, but it is.

Hi everybody, I'm in charge of an ices2 setup that's broadcasting a local radio station on the Net, and I'm currently under fire because one of our streams has been down twice in two days, forcing me to restart ices2 on each occasion. Our client is understandably unhappy about this. OUR SETUP: I've got ices2 installed on a local machine, broadcasting to an icecast server across

Hello, I will take your last version, but I have fresher news about the bug that occurs every mornings in fact... I think this is ntpdate which is causing the problem, as the time of the machine change for more than one second. Here is all the info: 09:46:17 up 1 day, 1:22, 2 users, load average: 0.60, 0.71, 0.68 86 processes: 84 sleeping, 2 running, 0 zombie, 0 stopped CPU states: 10.4%

hello, I just downloaded libshout from http://svn.xiph.org/icecast/branches/kh/ices and tried to follow the instructions for compiling it. When I run ./autogen.sh, I get the following: monkey:/usr/local/src/libshout-kh# ./autogen.sh Checking for automake version found automake-1.6 found aclocal-1.6 Generating configuration files for libshout, please wait.... aclocal-1.6 -I m4 aclocal:

hi, i am desperately trying to get this version of ices up and running on debian etch. i used the apt repository at http://www.fbriere.net/debian/ices2/ but i found this also affects the "official" source package at http://mediacast1.com/~karl/ when i try to run an edited version of either the example file provided with the source package or the deb at /usr/share/doc/ices2-kh/ i

Karl Heyes <karl@xiph.org> writes: > On Mon, 2004-10-18 at 18:27, Jack O'Quin wrote: > > Karl Heyes <karl@xiph.org> writes: > > > > > 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

Karl Heyes <karl@xiph.org> writes: > 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. There are several ways to

>I can't really comment on jackd itself, as I haven't looked that much >into it. If running jackd as root requires client apps to also run as >root then that is a pretty bad issue. I would of thought that running >jackd as a realtime process (whether root or not) would be an important >consideration. jackd (realtime) requires various resources which it shares with its

Is something broken here? I'm trying to do a test of relaying between two servers running kh-57. Master-slave relaying fails: the connection fails on the master with: [2004-11-01 17:05:32] DBUG admin/admin_handle_request Got command (streamlist.txt) [2004-11-01 17:05:32] INFO admin/admin_handle_request Bad or missing password on admin command request (command: streamlist.txt) As far as

Hi, I searched the Internet to find an answers, but I didn't find anything useful, so I'm turning to you, maybe someone has the answer. I want to make a realtime broadcast from a Linux box. The source is the soundcard's line-in, and it sends the stream to an Icecast server. I would like to have realtime compressor/limiter functionalities on this Linux box, so the outgoing signal

On Mon, 2004-10-18 at 21:04, Jack O'Quin wrote: > > > > > > There are several ways to gain realtime privileges. Running as root > > > is the simplest, but perhaps the worst solution. > > > > Just to be clear, with ices, you can drop to a nominated user after the > > realtime scheduler is selected. Running as root after that is not > >

On Mon, 2004-10-18 at 22:14, Paul Davis wrote: > jackd (realtime) requires various resources which it shares with its > clients: > > realtime scheduling > mlock-ability > shared memory segments > FIFOs (or Mach ports on OS X) > > we consider it *more* of a security risk to allow jackd-as-root to > share these with non-root processes. YMMV.