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