Hi Gary,
GStreamer shouldn't cause any more overhead than Xine for instance. Only
reason why I think you can have gotten that impression is that our alsa
output plugin did used to make ALSA flush all buffers on the soundcard
when you switch/stop playback causing the content of your hardware
buffers to always be played out before the sound stops. This issue was
resolved quite a few months ago so a recent GStreamer release shouldn't
have this problem.

But if there are other problems please let me know and we will try
looking into it. Also remember that when playing back audio using for
instance playbin there are some buffering being done, mostly targeted at
resolving issues with network play etc. These buffers can through the
API be made smaller in order to optimize responsiveness. I know the
Jokosher team is currently doing this for instance.

Sincerely,
Christian

On Sat, 2006-05-27 at 18:20 -0400, Gary Cramblitt wrote:
> The reason why I'm asking for a separate category for Accessibility follows.
> 
> TTS requires that speech be heard as soon as possible when requested, and stop 
> immediately when told to stop.  So while one might use a "heavier" backend 
> such as GStreamer for music playback, a "lighter" more responsive backend 
> would be appropriate for TTS.


_______________________________________________
kde-multimedia mailing list
kde-multimedia@kde.org
https://mail.kde.org/mailman/listinfo/kde-multimedia