We've been running Rivendell + Jack + Icecast + USB 16-Channel sound
device on an old P4 computer for a few years now without problems. In
fact the whole audio playback / routing thing has been incredibly stable.
Oh and I'm really giving Jack a workout as I'm actually feeding three
different stream decoders, looping in and out of a simple software based
audio processor (Jack Rack) configured to be a simple 1-band AGC for one
of the streams, as well as looping out of the multi channel sound device
to an emergency broadcast box + BT audio switcher, then back in before
it is sent to the transmitter stream, plus I have all kinds of routing
and switching going on to put other devices on the air like a Telos
ZIP/one CODEC, analog phone line, Skype, and VLC (with jack support)
playing network streams, with a bunch of buttons on Rivendell that have
ISB-Talkback funtions to remote broadcast sources and routing to Cue
channels and all kinds of fun stuff like that. All on this P4 that is
also busy at time doing importing from rdcatch or rdlibrary and/or
creating logs at the same time!
Here are things I am doing however:
1) I'm using a "real time" kernel (Debian's 3.2.0-3-rt-686-pae to be
exact).
2) Appear to have the real time parameters configured correctly (needed
even if you don't use a real time kernel I believe). Its the stuff
found in /etc/security/limits.d, Instructions found elsewhere (hint,
something like: @rivendell - rtprio 99, @rivendell - memlock 450000,
@rivendell - nice -10).
3) I'm using the "Darkice" stream encoder with Jack support (currently a
"binary" from a Ubuntu distro)
4) My jack settings are currently set to 512 frames/period and 4 periods
per buffer, and jack is running in realtime priority. This gives me a
46ms latency. This much latency setting seems to be mostly due to the
USB sound device as our backup Rivendell doesn't have one and is able to
run at 256 frames/period and only 2 periods/buffer, giving only 11.6 ms
of latency, but it is also a faster machine too but resides in a
different city and get used for other purposes as well.
5) I am NOT doing any of the tricky bonding of two or more sound cards
together like you can do in ALSA. This is normally a bad idea because
the clocks on each of these can drift independently of each other and
can cause lots of xruns.
6) Your problem could easily be that your sound device is simply not
stable enough for Jack operation. I experimented with Jack on a
Raspberry Pi and found it's "built-in" sound output device to be very
unstable, a cheap USB dongle sound device to be better, but still bad,
but the same model of USB sound device we are using for our normal On
Air computer (Presounus Audiobox 1818vsl) ran with reasonable stability
(but with very high latency). Try installing another sound device and
bonding Jack to it if you can. If you don't need Jack to be bonded to a
physical (real) audio device, perhaps you can use a fake virtual device
for it to clock-sync to.
_______________________________________________
Rivendell-dev mailing list
[email protected]
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
