The need for a Multimedia Distribution
The need for a Multimedia Distribution
Posted Feb 27, 2003 14:44 UTC (Thu) by NAR (subscriber, #1313)Parent article: The State of Multimedia Linux
If Linux is going to make any kind of dent in Microsoft's share on the desktop, we'll definitely need multimedia applications that can compete with the commercial counterparts for Windows and the Mac OS.
You're certanly right, but why should this imply the need for a "Multimedia distribution"? IMHO when a "killer app" surfaces, it is quickly integrated into the major distributions (e.g I've seen mplayer in SuSE and Mandrake, and it was (or is) in Debian too), so I think, we don't really need yet an other distribution.
Posted Feb 27, 2003 15:48 UTC (Thu)
by yohahn (guest, #4107)
[Link] (2 responses)
I know a bit about the audio perpective, so that's what i'll comment on. When you are playing back audio, frequently you use large buffers to keep from having dropouts in audio when another task is busy with the processor, and you are unable to send more data to the audio card. XMMS and the like all provide this capability, I imagine that video uses a similar method. This is very different from what happens when you wish to do multi-track recording. When you are playing a track and trying to record on another audio track (listen to the background while singing the lead), you want as little latency as possible. This means you cannot use large audio buffers as they add latency. Thus for high-end audio recording on a Linux box different frameworks are used. Where esd or aRts or the Gstreamer frameworks would be used on playback, JACK (jackit) is used when recording. Even a specially compiled kernel (with low-latency patches) must be used. (the code is in 2.5, but a patch is required under 2.4) Even on windows a different driver framework is used for high-end recording: ASIO drivers (amoung others). These high-end frameworks are quite different from their playback siblings. Add to this the problems with C++ libraries. Since Multimedia uses alot of complex structures (and usually a complex UI to manipulate it) but needs good speed, frequenly C++ is used. The problem is that the standard for dynamic linking to C++ based libraries has been in alot of flux, leading to frequent dynamic linking problems as g++ versions change. This has lead one of the nicer Multitrack recording programs, Ardour, to make some really strange decisions. They only allow static linking to multiple libraries, including libgtk+ and libgtk--. What's even stranger, because the rate at which these libraries were changing, they decided to include GTK+ and GTK-- right into the source code. You compile the GUI interface right into the app. Trying to get something like this included with debian would probably create quite a flame war (a few flareups have happened on the Ardour mailing list before) On the other hand lots of good things have occured on the audio front. LADSPA seems to be catching on, and there is a good rallying area for linux audio projects (http://www.linuxdj.com/). I can understand the difficulties that a multimedia distro has in front of it. The challenge should be embraced, but people need to understand the difficulties involved. (Disclaimer: I'm not involved in any of these projects, I've simply been a long time interested observer. If I've gotten something wrong, please correct me)
Posted Feb 27, 2003 17:28 UTC (Thu)
by iabervon (subscriber, #722)
[Link] (1 responses)
For production, it does make sense to have different settings, but this still doesn't require a separate distribution. It would probably make most sense to have a different runlevel to avoid running programs that are generally useful but which could interfere with your editing (you don't want to run updatedb while in this mode, since it will cause a huge amount of disk load). But the same package management, configuration, and (provided the associated software is tracked properly) updating mechanisms as are used by a general-purpose distribution should be appropriate. (As far as the kernel, you do need a low-latency kernel for multimedia production, but you actually seem to want a low-latency kernel for everything, it seems).
Posted Feb 27, 2003 19:59 UTC (Thu)
by yohahn (guest, #4107)
[Link]
As to having everything in one distro. I agree with your assessment than a different run level could do the trick. This is a good plan for the long run On the other hand, right now, I think it's a bit overly complex to expect it to fit right in, right away. Currently, low-latency is a custom kernel, ALSA is a custom kernel, and c++ libraries don't all work together for dynamic linking. I think a separate distro now, could help lead to packages that fit right in, later. (this model fits right into debian, I think)
Posted Mar 7, 2003 0:23 UTC (Fri)
by mmarq (guest, #2332)
[Link]
IMHO, if Linux dosent make a significant dent on the desktop, then it 'll gonna be dead on the desktop after a very few years, and dead as a worldwide movement and in tight control of giants like IBM or HP. I think even Linus would eventually "get off" if he only receives patches from IBM or HP boys and the like, or if the only machines that Linux would run where IBM or HP servers. "If Linux is dead on the desktop, then is dead period"... it's a Linus statement! I dont know if it takes a "killer-app" or if its only a matter of drivers or toolkits, but i think its always of good taste to warn (almost a moral imperative) all developers, users and followers. WE NEED DESKTOP
The problem with the "just included with the distro" idea is that multimedia authoring has very different requirements than multimedia listening. (at least on the more professional side)The need for a Multimedia Distribution
My understanding is that the design is quite different and porting one audio app to use the other framework is not easy (I have no experience here.. I believe it's a matter of using a callback function in the higher end frameworks). This has lead to a rather fragmented developement of programs using different libraries. (Two of the nicer interfaces, Sweep and Audacity, use the oss interface directly. Other apps use JACK and alsa exclusively. These inflexabilities are rather annoying).
I would guess that the multimedia applications required to compete with MicroSoft on the desktop are listening, not production, applications, since desktop users generally don't do much multitrack audio production (a bit of editing, perhaps, but not realtime).The need for a Multimedia Distribution
I would say there is a big market in the desktop for production. More in homes than in business. I would use the sales of DVD cameras, DVD+-RW drives, CD-RW drives, and video capture cards to support my claim.The need for a Multimedia Distribution
The home multimedia authoring market is just going to get bigger as the home user gets more savy. (I think they will also start using it in church and school stuff, more and more.)
>If Linux is going to make any kind of dent in Microsoft's share on the desktop, we'll definitely need multimedia applications that can compete with the commercial counterparts for Windows and the Mac OS<.The need for a Multimedia Distribution
"And the brilliant analisys: http://www.aaxnet.com/editor/edit029.html"