Re: Jackit-devel Digest, - Question of Jack Setup

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

Re: Jackit-devel Digest, - Question of Jack Setup

Mario Vano
  On Wed, 2006-07-05 at 10:48 -0700, Christopher Thielen wrote:
 >> >> Hello,
 >> >> I'm very new to the Jack audio system and have a few simple
 >> >> questions about what I think would be it's perfect application to an
 >> >> audio problem I'm having.
 >> >> I work for the KDVS radio station in Sacramento, which does
 >> >> terrestrial broadcasts as well as Internet broadcasts, and we have an
 >> >> analog audio line out coming off our main broadcast board into a 160
 >> >> MHz computer, which is connected via a 10Mb/s connection to a much
 >> >> faster, brand new Dell PowerEdge server, which has a much bigger
 >> >> connection to the Internet to do our MP3,Vorbis,and Real streams.
 >> >> My problem however, is trying to get the audio line in from the slow
 >> >> computer, through the 10Mb/s network, up to the much faster PowerEdge
 >> >> server's line in. I believe this is what Jack can do, right?

I'm currently running a similar setup and have been for several years
for KFAI-FM in Minneapolis and I have a couple of comments I think might
be helpful....

1. I believe that there is at present no way to get live audio into any
current Real Encoder for stream encoding other than by letting it read
the port itself directly from OSS. It's a major nuisance. The encoder
builtin routines read directly from an OSS interface or from a wave
file. The wave file reader insists on knowing the size of the wave file
before starting (which limits that input to 2Gb!). Only the OSS input
can stream continuously (with longer than 2Gb of input data). It has no
limit at all.

2. There IS a well documented plugin scheme supported by the encoder
that allows new input driver's to be dynamically linked. In theory, this
would allow writing a special input plugin for any realtime source you
want. Unfortunately, the source files for the SDK were so badly
maintained that the plugin libraries haven't been buildable under any
modern release of Linux for several years.

3. In the past 6 months, an updated SDK has been made available from the
"open" helix community server that seems able to build plugins again. I
haven't had time to get back to the project, but I think that an open
source plugin (which is well within the terms of the licenses) is what
needs to be written to solve a NUMBER of interface problems. (I for one
would really like to be able to use unix pipes to feed audio into the
encoder for non-real time encoding from our automated multi-tier
archiving system, as well as feeding the live encoder from our jack
stack.) At the moment our real time streams and off-line archives are
fed from applications running from jack WITH THE EXCEPTION of the real
encoder which is running from it's own interface. (there are TWO in the
machines). The inability to encode from anything but a wave file creates
some real problems for our automated archiving system (especially since
we have some programs as long as 8 hours long).

4. The easiest solution is to wait till I or someone else gets around to
writing a jack plugin for the Real Encoder. In the meantime, I suggest
just using two interfaces. The biggest problem is that most servers
(e.g.Dell Poweredge series). No longer support ordinary PCI cards! They
only support PCI-X cards. There are very few audio interfaces available
in this format. We use M-Audio Delta cards which work very well and DO
support 3.3v PCI-X use. Dedicating one card to real audio is an
inexpensive solution.

5. There's no reason why you should be getting audio interference from
the servers if you use a professional tuner and audio cards and cable
things properly. We use bogen tuners and the aforementioned M-Audio
Delta card and have no problems of this type at all with our Dell 1650s
and 1750s.

6. There are a couple of good reasons why taking the signal off the air
may be a better choice than taking it off your board. We ourselves ran
into a show stopper here when we tried to take a direct signal.

Like many FM stations, our station relies heavily on an Optimod audio
processor for final gain riding and audio balancing.

Modern Optimod's typically don't generate an easily accessible audio
output of the processed signal. Ours generates a composite stereo signal
which is sent directly to the transmitter modulator. This means that the
only easy way to get an identically processed signal to the one we
transmit is via an off the air monitor.

Over the years, our programmers and technical staff have grown to rely
heavily on the Optimod for gain riding. Ahead of our Optimod, our levels
are typically all over the place and not very pleasant to listen to.

Before we gave up and switched to using the off air signal, we actually
had to use a second older analog Optimod that did support audio output
to condition the program signal in order to duplicate the work the main
digital Optimod was doing and produce a conditioned analog signal for

7. If you're still planning to split things up separated by a 10mb
ethernet, by FAR the easiest and most reliable way to do it is to encode
at the near end stream at the far end. A $400 computer running Linux
will handle the streams nicely. We ran this way for three years, but we
were using a T1 between the encoders and the colocation site. Life got
much simpler and more reliable when we moved the encoders to the other
end, however....

8. I'd be glad to move any further discussion of this kind of thing off
the list, since Jack is not centrally involved. I do not work directly
for KFAI (It's a community radio station with only 6 employees), but I
do run a small consulting firm that does this kind of work and would be
glad to exchange some information with you (or better yet, do some work
for you if you need some help).

To summarize:

1) I too would like to see a better interface between Jack and the Real
Encoder, but the project was stalled for about two years by the broken
SDK. It may be possible to get some work going on that again, especially
if someone else with Linux C++ experience has some time to donate. I'd
be glad to explain what I know about the process. It would be a useful
"hack" for a lot of other reasons. 2) I suggest taking off-air signals
if possible. They can actually be higher quality. 3) We couldn't run
KFAI's site without Jack. It multiplexes our live Darkice encoder with
some monitoring processes and with our real time spooler that feeds the
archives. It's been running that way 24-7 for many months at and servers thousands of listeners a day!

Mario Vano
Vano Associates
[hidden email]

Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
Jackit-devel mailing list
[hidden email]