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

Christian F.K. Schaller christian at fluendo.com
Wed Nov 29 11:47:47 CET 2006

On Tue, 2006-11-28 at 22:14 +0100, Lennart Poettering wrote:
> It's not clear to me what the OSDL tries to achieve with the DAM
> multimedia meetings? Is the plan to define a new abstracted sound API?
> That would be a very difficult thing - and a very questionable one as
> well - since there are so many APIs around already. I wonder who's the
> intended target group for this new API? Pro-Audio people? Game
> developers?  Networked Audio people? "desktop" application
> programmers? all of them?
> Anyway, I can't afford attending the DAM conference, and I haven't
> been invited. (which surprises me actually, since PulseAudio is slowly
> become the standard audio system on Linux, given that both Ubuntu and
> Redhat seem to support it nowadays) I'd have a lot to say about audio
> APIs and standardizing on them, though. But mabye gstreamer-devel is
> not the proper place for this.
> Lennart

Well I was at DAM-2 in Mainz and that was my greatest criticism of their
effort, that they didn't know what they wanted to achieve.

OSDL as an organization sorta have picked up that some vendors moving or
looking at Linux feel that the multimedia stack is lacking. Problem is
that they haven't gotten a clear image about what these vendors are
missing (probably cause their number is still small and their problems
highly varied). At DAM-2 I felt the discussion was kinda lost from the
beginning as there was no clear idea on what wanted to be accomplished.
The opinions there seemed to range from wanting to create some standard
audio only API's not tied to a specific implementation to my own view of
pushing for looking at a complete solution to match the Windows Direct*/
Apple Quicktime stacks (as that is the room we see ourselves filling
with GStreamer).

I do fear that the discussion at DAM-3 might end up just as unfruitful
unless OSDL have figured out what problem they feel needs addressing as
there are still a gigantic host of them we need to tackle at some point.
Having a discussion about 'problems with linux multimedia' tends to be a
waste of time in the sense that everyone have different idea about what
the most important problems are and what the 'real' problem is.

Just to list some examples of problems/issues I got from Fluendo
customers and partners:

ALSA API's are not nice
Automated handling of hardware is not good
Lack of drivers
Immature Firewire and bluetooth stacks
Lack of legal codec support
ESD sucks
KDE and GNOME seems to be splintering on this issue
Codecs are difficult to install
To many high level playback API's
Free Software licensing and multimedia is painful due to patents
Developers of project XYZ is hard to work with
No legal DVD support
Hard to integrate DRM systems
ALSA and V4L drivers not implemented in a consistent way
What can I assume will be available on all distro's
What sound server to use or just use ALSA

There where also a lot of GStreamer specific things we have gotten over
the last year (and which we have tried to resolve):

- No specified way to do trick modes
- No components for doing VoIP
- No support for RTSP streams
- Plugin XYZ misses feature XYZ
- Plugin ZYZ is needed
- I need GStreamer to work on Solaris or MacOSX or Windows

Anyone of these issues could probably be the topic of a discussion in
themselves and the people reporting each of them will often have wildly
different situations they are struggling with. Like the people reporting
the need for trick modes in GStreamer to us where at a stage where most
of the items in the first list where either taken care of or irrelevant
to them, while for the people who reported issues with the lack of
drivers didn't get very comforted when we got trick modes in GStreamer

So I fear that unless OSDL decides who's problem they want to solve they
are not solving anyone's problem and these meetings will be mostly about
getting some nice sandwiches for free.


More information about the gstreamer-devel mailing list