Notes on photo sphere/panoramic EXIF metadata

Posted 2024-04-16 15:04 / Tags: Photo. / link

Linux Intern 03/2009 Interview, ungekürzte Version

In der Zeitschrift liegt nur eine gekürzte Version vor. Als Ergänzung dazu hier der volle Text wie er ursprünglich von mir entsendet wurde.

Originaldatum: 01. März 2009, Gekürzte Segmente sind leicht hervorgehoben.

Wie schätzt Du allgemein die Fähigkeiten von Suse als RT-Betriebsystem für Audio ein?

Generell gibt es keine unnötigen Barrieren, um ein Realtime-System zum Laufen zu bekommen. Ein Teil davon ist der Kernel, der andere sind die Programme. Hier kommt z.B. der Niedriglatenz-Audioserver JACK zum Einsatz. Die Integration von PulseAudio haben Distributionen vergeigt — auch wenn die Situation seit der Diskussion um “Linux Audio: It's a mess” besser geworden sein mag — Benutzer haben zuweilen immer noch Probleme selbst damit.

Ist es besonders schwierig, Deinen Kernel zu integrieren?

Der Endbenutzer braucht lediglich das RPM-Kernelpaket zu installieren, evtl. noch Treiber wie NVIDIA, und kann nach Starten des Kernels schon loslegen. Die Installation kann man mittels `rpm -ihv` (für Vorsichtige), zypper oder yast durchführen, und Webpin biete[t] auch automatisch generierte One-Click-Metadaten an.

Du bietest Dein Repo auch für 64bit an: können Anwendungen wie Jack damit besser laufen, als mit dem 32bit-kern? Beobachtest Du selbst Performance-Vorteile?

Ich muss gestehen, ich verwende JACK selber nicht; da ich nicht professionell im Audio-Bereich arbeite, genügt mir ALSA. Mein täglich verwendeter Desktop ist auch noch eines Baujahrs, wo es die ersten 64bit-Opteron-CPUs nur als “AMD Engineering Sample” (so gesehen in /proc/cpuinfo) gab — 2003. Den 64-bit-Kernel setze ich selber daher bisher leider nur auf Servern ein, alles andere erfahre ich durch Userberichte.

Allerdings bietet ein 64-bit-Kernel die Möglichkeit, ein 64-bit-Userspace zu betreiben, was einige Vorteile bietet. Vorab sei gesagt, dass einige Multimediakomponenten, darunter ffmpeg, handoptimiert sind, und auch im 32-bit-Modus alle CPU-Features ausreizen, dies muss aber nicht bei allen Programmen so sein. Ohne besondere Anweisung nämlich produziert der Compiler im 32-bit-Modus nur Instruktionen, bei denen garantiert ist, dass sie vorhanden sind. Komponenten ohne Handoptimizerung, hier am Beispiel “libvorbis”, verzeichnet einen 17%igen Geschwindigkeitsgewinn durch Kompilierung mit SSE auf 32-bit. Da SSE fester Bestandteil von x86_64 ist, sind 64-bit-Distributionen im Vergleich zu ihrer 32-bit-Variante üblicherweise schneller. OpenSUSE bot darüber hinaus von Anfang an ein reichhaltiges Angebot an 32-bit-Bibliotheken für die x86_64-Releases an — leider traf das nicht auf alle Distributionen zu, und führte wohl mitunter zu dem Mythos, dass es “Probleme” mit 32-bit-Programmen unter 64-bit gäbe. [Schlechte Programmierung ist natürlich immer ein Problem.]

Wie siehst Du Deinen Kernel im Vergleich mit anderen RT-Varianten, etwa dem 64Studio-Kernel für Debian oder dem CCRMA-Kernel für Fedora? Gibt es große Unterschiede?

Der offensichtlichste Unterschied ist zunächst mal die Versionsnummer. Bis zum Erscheinen von 2.6.29-rt Ende Februar 2009 bot ich nur 2.6.25(-rt) an, während andere schon auf 2.6.26-rt gewechselt waren. Darüberhinaus versuche ich, meinen Kernel auf den von openSUSE aufzubauen — das muss aber nicht immer so sein, z.B. wenn Novell noch keinen neueren bereitstellt —, um von deren Patches Gebrauch zu machen. Bei anderen Distributionen finden sich hingegen viel öfter Vanilla-Kernel.

In den letzten Monaten hatten Entwickler von Audio/MIDI-Software massive Probleme mit der Kernelentwicklung. Paul Davis bezeichnete Version 2.6.27 als unbrauchbar für Audio, wie schätzt Du die Entwicklung ein — werden solche Probleme irgendwann ganz verschwinden?

2008 und Anfang 2009 gab es RT-Updates lange Zeit nur für Kernel 2.6.26. Nachfolgend hatten einige Interessenten, darunter das Kernelteam von Novell, versucht, die Patches auf 2.6.27 zu portieren, hatten damit aber nicht sonderlich viel Glück — mein erster und einziger Versuch eines Test-RPM-Paketes endete mit einem Panic beim Booten. Ich schließe daraus, dass es nur wenige Entwickler gibt, die sich mit RT-Code genügend auskennen, um die RT-Patches auf neuere Versionen aufzusetzen. Begabtere Endanwender versuchen derweil, mittels “Full Preemption”, also eine Stufe unter “Real-Time”, auszukommen, und mögen dabei wohl über audiophile Grenzen, wie z.B. Latenz treten, die für ihre Tätigkeit nicht mehr hinnehmbar ist.

Ende Februar ist dann RT für 2.6.29-rc erschienen, und nach den Worten Gleixners[3][4] sollen die RT-Patches einen hören Stellenwert bekommen, indem sie in das Repository der Entwickler eingepflegt werden sollen. So besteht die Hoffnung, dass die Patches fortschreiten und “mitgeschoben” werden, wenn das RT-Team ihren Entwicklerbaum mit dem von Linus Torvalds synchronisiert. In der Zukunft sollen die Patches dann auch mal nach Mainline übernommen werden. Man mag abwarten.

Wie “offiziell” ist Dein Repo? Wird es eher als interessantes Nischenprodukt geduldet oder als wichtiger Beitrag gefördert? Zeigen NOVELL oder OpenSuse Interesse an einem offiziellen RT-Kernel in offiziellen Suse-Repos?

Ein Nischendasein scheint es zu führen, bedingt durch eine Reihe von Faktoren. Die meisten Paketmanager entscheiden allein aufgrund einer höheren Versionsnummer, ob ein Paket upgradebar ist, und das hat Endbenutzer, insbesondere solchen mit Upgradewahn, oft Pakete eingespielt die sie gar nicht wollten — zurückzuführen darauf, dass sie mal das Repository hinzugefügt hatten, um an ein eigentlich anderes Paket heranzukommen. Naja, so hatte ich automatisch eine Gruppe (un)freiwilliger Kerneltestern ;-) Leider hat das Spuren hinterlassen, und man darf heute eigentlich nur froh darüber sein, dass es mit Zypper einen Paketmanager gibt, der standardmäßig keine Upgrades über Repositorygrenzen hinweg macht.

Novell hat bereits mit openSUSE 10.3 einen RT-Kernel auf Basis 2.6.22 herausgebracht. Da ich schon länger Kernels mit meinen eigenen Patches erweitere, war RT damals eher ein Nebenprodukt der Build-Software. Erst mit 2.6.23, wo der Scheduler im Kernel durch CFS ausgetauscht wurde, gingen mir die Latenzen bei der einfach Audiowiedergabe auf einem Kernel mit 10 ms Scheduling-Granularität (also HZ=100) durch die Decke und ich wechselte auf RT.

Posted 2009-08-01 19:08 / Tags: Articles, Magazines. / link