The need for a Multimedia Distribution

Posted Feb 27, 2003 15:48 UTC (Thu) by yohahn (guest, #4107)
In reply to: The need for a Multimedia Distribution by NAR
Parent article: The State of Multimedia Linux

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.
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).

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] (1 responses)

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)