| |||||||||||||
|
| |||||||||||||
The need for a Multimedia DistributionThe need for a Multimedia DistributionPosted 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.
(Log in to post comments)
The need for a Multimedia Distribution Posted Feb 27, 2003 15:48 UTC (Thu) by yohahn (guest, #4107) [Link] 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)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)
The need for a Multimedia Distribution Posted Feb 27, 2003 17:28 UTC (Thu) by iabervon (subscriber, #722) [Link] 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).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).
The need for a Multimedia Distribution Posted Feb 27, 2003 19:59 UTC (Thu) by yohahn (guest, #4107) [Link] 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 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.) 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)
The need for a Multimedia Distribution Posted Mar 7, 2003 0:23 UTC (Fri) by mmarq (guest, #2332) [Link] >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<.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
|
|
||||||||||||