KDE4 MM, a view from usability and general application development

[Christian Fredrik Kalager Schaller]

On Wed, 2004-09-08 at 14:20, Arnold Krille wrote:
> On Wednesday 08 September 2004 09:19, Christian Fredrik Kalager Schaller 
> wrote:
> > This is not true, the GStreamer pipeline was designed taking real-time
> > concerns into special consideration (pipeline introduce no overhead in
> > itself) as the original author (Erik Walthinsen) main goal was to use it
> > in a real-time application he was making.
> 
> So, if GStreamer is that good with realtime, you have a big promotional 
> problem, since almost every professional audio user uses Jack and Ardour for 
> recording multitrack.
True we have a promotional issue in regards to getting more ´pro-audio´
hackers to use GStreamer. That said if you want to do a pro-audio app
with GStreamer you would probably need to write it for GStreamer from
scratch like for instance soundscrape. Jack has the advantage that it is
probably easier to ´port' and existing application to use it. 

> Can GStreamer do 5ms latency?
Yes	
>  With a desktop running in the back?
Yes
>  With a full-featured desktop like kde in the back?
Yes, but KDE isn´t full featured until it uses the services offered by
GStreamer ;)

It is worth nothing that if you use GStreamer as your toolkit for making
a ´pro-audio´ app there is a good chance you would still decide to use
Jack using our Jack plugins. Of course due to the way Jack works (and
need to work) you would have to design your application in GStreamer
with Jack in mind. 

> If the answer is yes, then you probably don't have all the decoding and 
> video-to-sound-synchronising features kde needs...
I think you probably need to stop making assumptions based on some 
beliefs you acquired somewhere along the line about what is possible and
what is not possible and instead investigate the issue. Wingo did
investigate it and so has others, and all agree that there is nothing in
the GStreamer design that hinders pro-audio aka low-latency apps from
being made using GStreamer, or which makes GStreamer an inherently bad
choice for doing so. The issue is however as Wingo pointed it out that
we would need to have some low-latency stress testing done to make sure
rgw plugins and core actually do handle it as well as we the design
allows, but that is an issue of bugfixing and development work not an
issue of what is possible or not.

> I am not against GStreamer, I am all for it being supported. I just want to 
> say that professional audio and a framework suitable for normal desktop usage 
> are different pairs of shoes.
I think you should start to look upon GStreamer as the street you walk
upon with different pairs of shoes instead of seeing it as a pair of
shoes :) 

Christian