On Wed, 2004-09-08 at 14:20, Arnold Krille wrote: > Can GStreamer do 5ms latency? With a desktop running in the back? With a > full-featured desktop like kde in the back? > If the answer is yes, then you probably don't have all the decoding and > video-to-sound-synchronising features kde needs... In addition to what Christian just mailed ("yes"), I'd like to technically explain why. GStreamer uses pipeline states, which means that a pipeline can be switched between multiple states of readiness. Our basic state is NULL and the elementary state is READY, in between which memory setup and resource allocation is being done. Between READY and PAUSED, all stream initialization is done. Between PAUSED and PLAYING, *nothing* is done except the fact that actual data is now streaming. This means that with correct pipeline scheduling, the step from PAUSED to PLAYING is as small as a simple state iteration. Totem Reports a latency of 0,0018 (or maybe 0,018 seconds, I forgot) from PAUSED back to PLAYING. Synchronization is completely unrelated to this, however. If you try to go into the discussion that you started using those question, you ought to know what you're talking about. Latency is a time difference between an action and a reaction. Synchronization is an effect between two actions that *are already in motion*. In GStreamer, synchronization is an implicit part of pipeline data flow, and pipeline data flow is something that comes *after* pipeline state (and thus latency). Therefore, synchronization and responsiveness do not interfere. Ronald -- Ronald S. Bultje _______________________________________________ kde-multimedia mailing list kde-multimedia@kde.org https://mail.kde.org/mailman/listinfo/kde-multimedia