From kde-multimedia Wed Sep 08 13:58:14 2004 From: Christian Fredrik Kalager Schaller Date: Wed, 08 Sep 2004 13:58:14 +0000 To: kde-multimedia Subject: Re: KDE4 MM, a view from usability and general application Message-Id: <1094651894.628.61.camel () cschalle ! fluendo ! com> X-MARC-Message: https://marc.info/?l=kde-multimedia&m=109465194507901 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 _______________________________________________ kde-multimedia mailing list kde-multimedia@kde.org https://mail.kde.org/mailman/listinfo/kde-multimedia