Thanks for the response. I had no idea that doc would make it out your
way, I'm a bit embarrased ;) Allow me to apologize for not being on
consortium@, these days I only get a couple hours of internet a week...
On Mon, 2004-02-02 at 19:19, Christian Fredrik Kalager Schaller wrote:
From: Steve Harris <S.W.Harris(a)ecs.soton.ac.uk>
Date: Mon, 02 Feb 2004 15:18:53 +0000
On Mon, Feb 02, 2004 at 03:59:02 +0100, Christian Fredrik Kalager Schaller wrote:
I just thought I send the list this link to a document written by Andy
Wingo about GStreamer and where we stand in regards to pro-audio.
The doc is a mix of where we are/what we are focusing on.
Interesting, but he doesnt mention the part of gstreamer that truely
problematic for "pro" audio - synchronisation.
I assume you mean synchronization with external clock sources (as
opposed to between different internal streams, like audio and video). I
think, and I could be wrong, that this isn't really a problem. GStreamer
is, as you probably know, a library for data flow _within an
In the simple case (the one I'd use), your GStreamer app can be a Jack
client, and all of the sync is handled in Jack. Transport support (for
informational purposes, or for master purposes) is not yet implemented,
but would be done via a custom clock. The internal clocking
infrastructure would handle the rest.
If you want to do this via the ALSA interface... well you'd have to code
a lot on the alsa plugin. But again, this isn't a GStreamer problem, per
se. It's just for plugins. If we can synchronise audio and video
together and to their respective outputs, the framework has the
generality to do so to any fixed clock.
Does this answer anything, or am I missing the mark? I haven't yet had
the opportunity to test synchronization properly. This inexperience is a
soft spot for GStreamer, but I hope a temporary one :)
I agree that "pro" audio is a horrible term
Any better one? Could you just say "float audio"? Dunno...
Thanks for the comments,
Andy Wingo <wingo(a)pobox.com>