Glad to see much agreement on my description of GStreamer. I'm always
wary of describing someone else's project ;)
>I suspect the best way to support LAAGA's callback api is to write a
>gstLAAGAbin which contains the gstreamer graph inside it and exposes the
>bin's external pads as LAAGA ports. The normal way of supporting this sort
>of thing in GStreamer would be to write a LAAGAsrc and LAAGAsink but I'm not
>sure this would fit with the callback model.
Exactly. This is the crux of the matter when it comes to providing
LAAGA support. But think of it this way: if you wanted to support TDM,
VST, MAS, RTAS, ASIO, DirectX, OS X CoreAudio, BeOS MediaKit and other
plugin/driver/media systems, you'd have to provide the same kind of
callback-based API, so view it as an investment to be amortized over
time. Or not, hopefully :)
Note that I have plans to either twist Abramo's arm (;) or do the work
myself associated with making alsa-lib's "aserver" into a LAAGA
client. That will facilitate running regular ALSA-using apps through
the LAAGA system, just not with sample synchronization.
--p
