Re: System Sounds Through GStreamer

Ter, 2004-10-12 às 16:22 +0200, Thomas Vander Stichele escreveu:
> Hi,
> > > That said, using GStreamer (and more specifically, gst-gconf
> > > accompanying library) gives you bonus point in flexibility, since
> > > changing default output method is as easy as setting appropriate key in
> > > GConf. But that still doesn't invalidate need for sound server on
> > > machines with lower-end cards.
> > 
> >   No no no, don't go down this road.  If people complain about esd
> > latency now, just try replacing it with GStreamer and you'll soon find
> > out what latency really means.
> Hi Gustavo,
> this is nothing personal, but that's just FUD.  First of all, there are
> two latency-related things esd has problems with.  One is "time between
> asking to play something and actually playing something".  The second is
> "an application using esd doesn't know how big this latency is"
> The first is important for ding sounds and accessibility (think
> text-to-speech of selected widgets).  The second is important for
> synchronizing multiple audio programs/channels, or audio with video.
> >   I don't want to leave vague statements.  Simply put, building
> > GStreamer pipelines is too slow, and reusing/caching sound effects in
> > GStreamer doesn't work because it is too buggy.
> You didn't want to leave vague statements, but you did.  Building
> pipelines is too slow for what ? In what condition ? We have lots of
> apps that create pipelines on the fly and do it very quickly.
> 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.

> >   As an example, look at the crappy sound in monkey-bubble to see what I
> > mean.  [Disclaimer: I think monkey-bubble is a great program, I'm not
> > blaming its author]
> We should probably look at monkey-bubble then.  How certain are you that
> the author is using GStreamer correctly ? Since there are lots of little
> small apps that test speed of pipeline construction, and reusing sounds,
> I'd be surprised if it wouldn't work correctly when done correctly.
> Corrolary to your meaningless statement:  if I write a GTK app that
> creates lots of unnecessary widgets in my main window and lots of
> resizes, taking 5 secs to start up, does that mean GTK is slow ? If I
> then do all these things from five different threads I create without
> grabbing thread locks, and it crashes, does that mean GTK is buggy ?
> 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.

  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'm sorry if I sound inflammatory, but someone has to play this role.

  Best regards.

Gustavo J. A. M. Carneiro
<gjc inescporto pt> <gustavo users sourceforge net>
The universe is always one step beyond logic.

Attachment: smime.p7s
Description: S/MIME cryptographic signature

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]