[gst-devel] JACK and GStreamer, from the horse's mouth

[Kai Vehmanen]

Hello,

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 
over networks.

> 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
    virtual devices.

-- 
  links, my public keys, etc at http://eca.cx/kv