desktop and multimedia as an afterthought?
I'm not a kernel developer. I don't watch this mailing list too often. I use Linux for pretty much everything, and especially for multimedia (capture, process and edit video, music and sound processing, MIDI, etc.).
I'm interested in anything that could make my system work better for my multimedia apps. I used the Con Kolivas patches very early on, and i'm also watching with interest the recent preemption patch posted by Ingo Molnar.
I could be wrong, but it seems to me that at least a part of the kernel development team has the desktop and multimedia issues very low on the priority list.
The CK patches floated around as separate patches for a long time, even though they brought significant improvements to the kernel w.r.t. desktop and media.
Now the stock 2.6 kernel has a pretty bad problem with the latency. Also, there seems to be a reluctance in accepting the autoregulated swappiness patch, even though it markedly improves the overall behaviour of the system as a desktop.
I am not familiar with the intricate technicalities of the Linux kernel, so there might be purely technical reasons for keeping multimedia improvements at an arm's length.
But on the other hand, there are many Linux users, myself included, that repeatedly noticed how bad the stock Linux kernel is from a multimedia perspective and how big are the improvements brought by these seldom-if-at-all-included patches.
The CK patches have devouted "cult followers".
Projects such as PlanetCCRMA, which attempt to build a multimedia-ready Linux distribution, are running kernels patched with the CK patches by default.
On the Linux multimedia mailing lists and forums, one can often hear advices in the vein of "use such-and-such patch if you want your system to do any serious multimedia work, the vanilla kernel sucks." And rightly so. If i reboot my computer into Windows and perform the same multimedia tasks, there are fewer chances of it skipping frames or otherwise behaving improperly for multimedia work than on Linux running the vanilla kernel.
I mean, go read the forums. No one in the multimedia community uses the vanilla kernel. They could be all wrong, sure, but there's lots of them. :-)
There's a feature of the human brain to see patterns everywhere - i think i see a pattern here. :-) It's like the desktop in general and multimedia in particular matter a whole lot less than anything else on Linux.
It seems like there's a split-brain situation within the Linux community, with the core kernel developers sitting on one side of the rift, and the multimedia people on the other side.
Now, i remember someone saying, a while ago, that the server stuff is pretty much done, and the interesting things are going to happen on the desktop. That sounds plausible, but if the kernel has poor support for typical desktop scenarios, how are those big desktop improvements going to take place?
I'm not saying that the whole thing happens on purpose. I'm just saying that perhaps the latency and swappines issues and all might deserve a bit more attention.
Thank you, and i'm looking forward to constructive criticism.
Signature · 3 lines
Florin Andrei http://florin.myip.org/
Quoted 3 lines
I could be wrong, but it seems to me that at least a part of the kernel development team has the desktop and multimedia issues very low on the priority list.
no, that implies that desktop/media is somehow opposed to other development. that's the real issue: is there some reason to believe that this opposition exists, that tuning for desktop/media is tuning away from other serverish uses? people like Linus want to push the agenda that the same kernel can do both, until there's some definitive proof otherwise.
Quoted 3 lines
The CK patches floated around as separate patches for a long time, even though they brought significant improvements to the kernel w.r.t. desktop and media.
how do you show this? measured how, under what load, with what benefits?
Quoted 2 lines
And rightly so. If i reboot my computer into Windows and perform the same multimedia tasks, there are fewer chances of it skipping frames or
this normally shows only that windows drivers are better.
Quoted 9 lines
Quoted 3 lines
I could be wrong, but it seems to me that at least a part of the kernel development team has the desktop and multimedia issues very low on the priority list.
no, that implies that desktop/media is somehow opposed to other development. that's the real issue: is there some reason to believe that this opposition exists, that tuning for desktop/media is tuning away from other serverish uses? people like Linus want to push the agenda that the same kernel can do both, until there's some definitive proof otherwise.
there's no definitive proof, but one can say up front that the demands have long been recognized as fairly different, and that tends to leads to different design strategies which in turn can compromise the response to the demands.
the key characteristic of multimedia work, audio and video in particular (realtime 3d postscript-driven sculpture devices are still rare at this point) is that it needs to satisfy pseudo-hard realtime deadlines. i say pseudo only because nobody dies if the deadlines are missed. you miss the deadline for an audio device just once, and the entire group of people listening to the output can hear it loud and clear.
the serverish space never has this requirement. the main requirement there is stability and throughput, where throughput generally considers of delivery varying-sized chunks of data to a network interface as a result of various types of network-delivered requests. a server has only one catastrophic condition: failure to serve requests. degradation in performance is expected as load rises, and although tweaks may change the curve, its considered OK for a machine to perform variably as a server depending on the load.
the focus on the second of these two quite different sets of performance requirements tends to push the kernel in one direction, with occasional major concessions to the other. more abstractly, the tension tends to be characterized as between throughput and response ("latency"), but this is excessively simplistic. audio work (and to some extent video as well) requires deadline satisfaction, serverish work requires predictable degradation in response to workload. these are not inherently opposed to each other, but measuring the behaviour of one rarely touches the behaviour of the other.
Quoted 6 lines
Quoted 3 lines
The CK patches floated around as separate patches for a long time, even though they brought significant improvements to the kernel w.r.t. desktop and media.
how do you show this? measured how, under what load, with what
Quoted 1 line
benefits?
the classic example is benno sennoner's latencytest, which has been cited in all the reports here on latency issues, along with andrew mortons schedlat utilities like realfeel.
at the RMLL/LSM in bordeaux last week, takashi iwai of the alsa project demonstrated very convincingly that the isochronous scheduler (for example) is of major benefit to non-SCHED_{FIFO,RR} media applications. this is just for stuff like people running xmms and its cousins while doing other work.
there really is no room for disagreement here: every linux developer and user who does serious audio work runs a patched kernel and sees clearly measurable (and in some cases, absolutely required) benefits.
Quoted 4 lines
Quoted 2 lines
And rightly so. If i reboot my computer into Windows and perform the same multimedia tasks, there are fewer chances of it skipping frames or
this normally shows only that windows drivers are better.
this is an absurd claim. i suppose that beos' outstanding performance with media, or the excellent performance of osx simply shows that their drivers are better? when JACK was ported to OSX, it somewhat embarassingly performed better on OSX than it does on Linux. thats not because of device drivers, its because the Mach part of Darwin has superb facilities to support the kind of stuff that JACK needs.
--p
Quoted 5 lines · Mark Hahn
Quoted 3 lines
The CK patches floated around as separate patches for a long time, even though they brought significant improvements to the kernel w.r.t. desktop and media.
how do you show this? measured how, under what load, with what benefits?
Run the vanilla kernel. Run Ardour to do the digital audio work, plus a sequencer (Rosegarden, Muse, Seq24) to drive the MIDI gear. Do a multitrack record.
If you fiddle too much with Mozilla and/or Evolution, GIMP, gThumb, OpenOffice while doing the record session, Ardour will skip parts of the tracks.
Repeat everything, using a CK kernel instead (or the kernel provided by PlanetCCRMA). No amounts of Mozilla/Evolution/etc normal usage will make Ardour skip anything.
Want numbers?
0 skips if running the CK/PlanetCCRMA kernel.
Quoted 1 line
0 skips if running vanilla kernel.
Anything more than 0 is not acceptable for this type of usage.
System is:
AthlonXP/1800, 512MB RAM, NForce1 mobo, Audigy2, ALSA, Fedora 2 and various flavours of Linux-2.6 (similar results with Red Hat 9 and Linux-2.4)
Similar results reported by almost anyone doing sound studio type of work with Linux, on a large variety of hardware.
Quoted 4 lines
Quoted 2 lines
And rightly so. If i reboot my computer into Windows and perform the same multimedia tasks, there are fewer chances of it skipping frames or
this normally shows only that windows drivers are better.
Which drivers? Sound card?
The same issues manifest when doing an all-internal record.
E.g.: run a softsynth (a software that generates sound, such as Specimen, AlsaModularSynth or ZynAddSubFX) and route the output to JACK. Run some LADSPA effects (reverb, chorus, flanger) on top of the JACK pipe for good measure. At the other end of the JACK pipe run Ardour, Audacity or any other DAW (digital audio workstation) software. Add a few more softsynth instances, and drive them via a sequencer. All sound is routed inside the computer. It never touches the sound card. Any driver that's involved is the IDE or SCSI driver (because the DAW dumps the audio tracks onto the hard-drive). Even if the driver was defective, it wouldn't probably matter, because of the multiple levels of caching that are involved.
Yet the exact same problems happen (skipping parts of the tracks if system is only marginally used by other apps), with the exact same solution (apply the CK patches to the kernel).
Signature · 3 lines
Florin Andrei http://florin.myip.org/