[gst-devel] JACK and GStreamer, from the horse's mouth
kvehmanen at eca.cx
Thu Nov 30 00:03:17 CET 2006
On Wed, 29 Nov 2006, Lennart Poettering wrote:
> However, at both occasions our discussion suffered by the fact that
> noone of us had a "pro audio" background.
and please remember the real-time network apps as well. Their requirements
are much more like the ones of JACK than reqs of apps for streaming audio
> Just think of a voip app on top of a pull-model sound server like
> JACK. One thread would deal with incoming network packets and
> decode/decompress the audio data, which might be quite CPU
> intensive. The pull callback would be executed from a second
> thread. So, somehow the two threads need to communicate, i.e. the
> network thread needs to pass the audio data to the cb thread. How's
> that done? With an asynchronous, thread-safe queue. The cb thread now
Having been involved in hacking various different VoIP stacks, I can say
pull model is definitely better. First, the sender and receiver will have
different clocks, so you just can't blindly push data to the soundcard.
You also want to separate the network and audio subsystems, as the two
have very different operation rates (aside sending media within a LAN, you
generally don't want to send audio in small (<5ms) chunks over packet
networks as the the header overhead would become ridiculous). You do want
to run the soundcard with high interrupt frequency to achieve low latency.
And last, you usually want to wait for the very last possible moment for
incoming data, before changing into error concealment mode of operation,
and pull-based model fills this need much better.
Now you _can_ do VoIP stuff with push-model (and there are some clever
hacks out there on how this can be optimized), but my personal experience
from implementing this stuff (with both approaches) is that pull-based
model is the superior approach.
>> But you're right. gstreamer-devel is probably not the right place for us
>> to be having this discussion. Problem is ... where?
> Dunno. Perhaps on a new cleanup-linux-audio-jumble-discuss ML? ;-)
Oopps :) -- my apologies to the innocent bystanders!
PS Still one last note, my ++votes go to standarding on ALSA as the base,
and having multiple "middlewares" like gstreamer, pulseaudio and
JACK on top of it. What's really hurting us is the OSS kernel
API which, which doesn't provide ALSA style hooks for plugging in
links, my public keys, etc at http://eca.cx/kv
More information about the gstreamer-devel