[linux-audio-dev] ac3jack - realtime AC3 stream encoder for JACK

Jesse Chappell jesse at essej.net
Tue Dec 30 21:06:28 UTC 2003


Benno Senoner wrote on Wed, 31-Dec-2003:

 > 1)
 > on your page you say that on some soundcards jack blocks the SPDIF out 
 > thus you need
 > to have two cards to use jack and AC3 out.
 > Would it make sense to add AC3 support directly to jack ?
 > Basically integrating ac3dec's SPDIF out within jack.
 > That way the user could use the capure audio ports and AC3 at the same time
 > (with jack exposing the 5.1 ports).
 
Well, it might be a good idea to add some features to JACK's alsa
driver to optionally access the SPDIF for passthrough mode. It
might involve a new port type to be created so clients can connect
and send raw data through it.  I am skeptical about integrating
any AC3 specific code in JACK... 

 > 2)
 > is the quality of the encoder you are using at par/comparable with 
 > commercial
 >  windows AC3 encoders ?
 > how much CPU is used for full realtime 5.1 encoding -> AC3 spdif out on 
 > let's
 > say a 2GHz box (or give figures on your own box please).
 
The encoder is supplied by FFMPEG's libavcodec.  I have not done
any real quality tests at all.  According to some documents from
Dolby, encoding with decent quality is not too hard/complex at
the higher bitrates, but can get difficult at lower bitrates.
I looked briefly at the source for libavcodecs' ac3 encoding but
haven't tried to analyze it.  The one thing that does suck, is
that libavcodec is limited to 16bit audio input (an API limitation)
although in theory the AC3 encoding can be done from higher bit-depth
source.  Right now, I am not dithering the jack input, but that
is easy to add.

On my 1.8G P4, a 448kbit/s 5.1 stream encoding takes around 10%
CPU.  I'll note that the blocksize/buffersize i'm using could
be better optimized to match the JACK buffersize.  Also, i'm doing
the encoding/streamin in another thread (not the realtime process thread),
which might become a realtime performance problem on heavily loaded systems.
Turn up the buffering (-B) if upon exit it tells you overruns
occurred. 

 > 3)
 > Any idea what the latency figures look like when you pipe in a realtime 
 > audio signal into
 > jack-ac3 and the audio gettting out via SPDIF ?
 > Does ac3 encoding similar framesizes to mp3 (which means a minimum of 
 > 50msec delay).
 > In short, with these virtual "AC3 jack ports", would it be possible to 
 > attach a jack-capable softsynth
 > and play it lively ? (I guess not).

I haven't quantified them, but there is buffering going on in
my app and in ac3dec, so i don't think that live instrument playing
is going to be very useful at all.  The framesize of AC3 represents
a time interval of 1536 PCM samples (31ms at 48k), and i'm sure
the latency of ac3jack | ac3dec is a good bit more than this :)

I haven't done much realtime testing of the streaming yet, so
I'm sure some software updates might be in order once I get some
feedback from people (and myself).

jlc



More information about the Linux-audio-dev mailing list