Re: System Sounds Through GStreamer

[Thomas Vander Stichele <thomas apestaart org>]

Hi,
> > 
> > Reusing sounds doesn't work ? What bugs do you see ? It happily works in
> > a bunch of apps that have been written.
> 
>   Well, I admit I don't know GStreamer API intimately.  But I remember
> wasting an afternoon trying to reuse a pipeline with filesrc
> "location=xxx ! mad ! osssink", and then changing file position back to
> the start of the file when it finishes to play again.  It never worked.

If by re-using you mean "using the same pipeline with a different file",
then that's probably not the way you would want to do it.

If by re-using you mean "using the same pipeline for one file, and seek
back to start after playing", that works, there are various tests (see
gst-plugins/examples/seeking/seek), and if it doesn't, file a bug.

In both cases, don't waste an afternoon, but file the bug/drop in on IRC
if you're unsure/send a mail.
 
> > Or does it mean that I am not using it correctly ?
> 
>   Point taken, and I agree.  But the issue is that GStreamer programming
> is too complex.  You either know exactly what you're doing, and avoid a
> mine field of bugs to reach your goals, or you don't and trigger a bug,
> or you're doing something wrong and GStreamer silently does nothing.

We appreciate any ideas you have in making things more clear.  One thing
that has been done recently is create a playbin element that you just
give a file and some sinks, and it will do the right thing.  It's
evolving rapidly and being used in totem-gstreamer atm.

As for finding bugs, like any project, PLEASE file them.  There are
enough people that claim something is buggy, and every project doesn't
have enough people actually filing bugs.

>   I don't see anything wrong with replacing esd by GStreamer, as long as
> the GStreamer team provides a simple API like the existing
> gnome_sound_play("xxx.wav") API, with low latency, non-blocking (plays
> in background) and few bugs.  The so called "GstPlay API" does _not_
> qualify for this (fails the 'few bugs' check).

I think you're mixing things here.  It's pretty simple.  The sound
server in question, if it were to be written, would have a simple API
like the existing one.  The sound server itself would be using GStreamer
to provide this.  Whether or not the way it did this would be using
simple API or more complex API is not for you or me to decide, but for
the person who writes the sound server.

In short - why are you shooting an idea down before it's even
implemented ? Where you thinking of actually writing an esound
replacement ? If not, what are you trying to do here ?

>   I'm sorry if I sound inflammatory, but someone has to play this role.

Wrong premise.  Why should someone play this role ? You are allowed to
be constructive, so give it a try.

Thomas

Dave/Dina : future TV today ! - http://www.davedina.org/
<-*- thomas (dot) apestaart (dot) org -*->
When you're on the outside baby and you can't get in
I will show you
you're so much better than you know
<-*- thomas (at) apestaart (dot) org -*->
URGent, best radio on the net - 24/7 ! - http://urgent.fm/