OSS — das freie Soundsystem für freie Betriebssysteme

OSS Vs ALSA ist ein oft gehörter Flameware, der wohl eher ob der Politik als denn ob tatsächlich technischer Relevanz in der Linux-Welt zumindest beendet wurde. Aber es existieren immer zwei Seiten einer Medallie, so auch hier. Wobei die andere Seite außer urban legends oft nicht viel zu bieten hatte bzw. hat. Wie dem auch sei, vor einiger Zeit ging man dazu über das Soundsystem unter drei Lizenzen anzubieten, Suns CDDL, GPL und die BSDL — passend für jedes System. Viele machten sich darüber lustig, ob der Belanglosigkeit (aka FUD) bzw. dem Zwang dies jetzt zu tun. Nun auch IBM wäre lieber das frühere furchteinflößende big blue und Novell würde wohl nur allzu gerne wie einst zu Netware-Zeiten den Beherrscher der Netzwerk-Gefilde mimen. Die Zeit änderte sich jedoch und man mußte sich anpassen, um nicht in der Versenkung zu verschwinden. Vor kurzem machte sich auch AMD/ATI auf die Welt des Opensource zu beglücken, teils aus ähnlichen Gründen. Die Kommerzwelt betrachtet Opensource also recht pragmatisch, warum auch nicht — bis zu einem gewissen Punkt?

OSS nun bietet Support für eine Masse an Soundkarten, darunter viele Legacy-Karten, aber auch völlig neue Systeme wie z.B. Creative Labs X-FI bzw. Asus Xonar (CMI8778). Gerade X-FI ist dabei auffällig, da die Treiber von Creative Labs selbst (nur für Linux) kaum qualitativ überzeugen können. Freedom of choice also, das Credo von Opensource. Solange nicht künstliche Hürden errichtet werden, kann man OSS auf nahezu jedem BSD, Solaris und natürlich auch Linux nutzen :)

5 Antworten zu “OSS — das freie Soundsystem für freie Betriebssysteme”

  1. blub sagt:

    Freie Software unterstützt ALSA doch schon seit etlichen Jahren. Probleme machen mal wieder nur die Programme ohne offenen Quelltext.. z.b Spiele wie Quake3, Unreal Tournament, usw., aber auch Tools wie Flash, Skype, Teamspeak.. Das hat sich in den letzten Jahren allerdings stark verbessert. Man erinnere sich nur an Krücken wie artsd oder esd die nur existieren, weil OSS kein gescheites Mixing hinbekommen hat..

    Natürlich hast du bezogen auf ALSA auch nicht ganz unrecht, dass will ich garnicht abstreiten. Wenn es out-of-the-box funktioniert hat man selten Probleme, aber wehe wenn nicht.. das manuelle Setup kann teilweise eine Zumutung sein.

    Dafür hat ALSA auch einige Vorteile, z.b von Anfang an MPSAFE. Wie ist das mit dem Soundsystem in FreeBSD, läuft das nicht noch immer unterm Giant?

    Und der ALSA-API.. die benutzt man doch in den wenigsten Fällen direkt (GERADE WEIL MAN AUCH ANDERE UNICSE UNTERSTÜTZEN WILL). Für Spiele nimmt man meistens SDL, oder für Audio-/Videoplayer sowas wie Gstreamer, Phonon, usw.. Die X11-API ist auch derbe scheisse, interessiert aber keinen (außer den Toolkit Designern 😉

    Um also zum Ende zu kommen.. ja, ALSA ist kein Allheilmittel und nein, ganz so schlecht wie sein Ruf ist es auch nicht.

    Wie immer also wenns um Flamewars in der Open Source Scene ist.. ein Fünkchen Wahrheit ist immer dabei, aber es geht oft am Essentiellen vorbei und vieles wird heißer gekocht, als es im Endeffekt gegessen wird :-)

  2. Oliver sagt:

    >Freie Software unterstützt ALSA doch schon seit etlichen Jahren.

    Linux. Ich schrieb für freie Betriebssysteme und ALSA ist nun einmal Linux und nicht *BSD, Solaris, $OS.

    >weil OSS kein gescheites Mixing hinbekommen hat

    Olle Kamellen. Was schon seit _einigen_ Jahren nicht zutrifft, ganz im Gegenteil.

    >Und der ALSA-API.. die benutzt man doch in den wenigsten Fällen direkt

    Und dennoch wird damit als Vorteil gegenüber OSS geworben — recht paradox.

    >Wie ist das mit dem Soundsystem in FreeBSD, läuft das nicht noch immer unterm Giant?

    4front OSS ist schon lange MP-tauglich und _nicht_ gleich OSS in FreeBSD. Zudem ist Linux bekannt dafür Dinge vorschnell zu tun, ohne über die Konsequenzen nachzudenken — fixen kann man es ja bei auftretenden Problemen immer noch. $BSD geht da anders vor. Beim neuen CFS schraubte man auch in puncto peak Performance zurück, zugunsten von mehr Qualität.

    Beim Sound-System ist es seit FBSD 6.x der Fall.

  3. blub sagt:

    CFS hat nen langen Weg hinter sich, Ingo Molnar hat vor ein paar Tagen erst die letzten Patches veröffentlicht.

    http://people.redhat.com/.….-rc6.jpg

    Mit –rc7, der in ca. einer Woche kommt wird das nochmal ne Ecke schneller, siehe http://lkml.org/lkml/2008.….3/19/432

    Man ist also Performancemäßig weiter als mit dem alten Scheduler und dazu hat man erheblich mehr Qualität auf dem Desktop :-)

    Vergleich das mal mit dem aktuellen ULE, http://people.freebsd.org.….lona.png

    Auf dem Bild von Ingo kommen ältere Opterons zum Einsatz (8×8), bei Kris sind es neuere Barcelonas (4×4), von daher auch ~2.000 Punkte mehr Peak.

    Vergleich mal wie stabil Linux auch auf mehrere hundert Threads ist und wie schnell FreeBSD einbricht..

  4. Oliver sagt:

    >CFS hat nen langen Weg hinter sich

    Das sollte kein flame per se sein, sondern nur ein Beispiel wie es auch gehen kann und *fertig* ist ein Scheduler nie wirklich.

    >und dazu hat man erheblich mehr Qualität auf dem Desktop

    Ich habe die Diskussion um ck und CFS auch verfolgt — bezüglich Desktop und Server und viele auf der LKML waren wohl nicht der Meinung, man könnte von einer «geteilten» Meinung sprechen. Und auf dem Desktop selbst sehe ich hier auch keine Vorteile bei Slack 12 plus 24er Kernel. Natürlich kann jetzt eine RC mit einem marginalen Plus protzen und der nächste Fix macht die «finale» Version wieder marginal langsamer 😉

    >Vergleich mal wie stabil Linux auch auf mehrere hundert Threads ist und wie schnell FreeBSD einbricht..

    In der Realität ist es genau umgekehrt und bewegt auch kleine Firmen wie Juniper, Cisco, Yahoo, Nokia und gar auch zum Teil Google entweder FreeBSD ausschließlich oder in einer mehr oder weniger heterogenen Umgebung einzusetzen.

    Ich denke mal du vergleichst hier auch gerade Äpfel mit Birnen, nämlich Postgres zum einen mit Sysbench (primär Mysql und wohl auch hier Mysql).

    Kurzum bei FreeBSD habe ich Beständigkeit und weiß auch das die Performance «morgen» noch gegeben ist :) Sprich die Benchmarks von Developer Systemen interessieren mich im Moment nur sekundär. Interessant ist es wenn 8.0 die Bauarbeiten in puncto ULE 3.0 (CPUSET etc., just begonnen mit Nokias Hilfe) beendet hat, ein Teil davon für 7.1 MFCed wird und wenn der 25er Linux Kernel fertig ist und in aktuellen, primären Server-Systemen auch zum Einsatz kommt in produktiven Umgebungen. Und da finde ich in der Regel FBSD 5.x, 6.x und nun auch recht viel 7.0, sowie Linux mit Kerneln von .18 bis .20-.22. Selbst .23 setzt noch kaum einer produktiv ein — ich frage mich jetzt nur warum? Nein auch hier wäre ein Vergleich zwischen 7.0R und einem .24er Kernel, ein Vergleich zwischen Äpfeln und Birnen. Auf dem Desktop setze ich gerne den 24er ein, auf dem Server allenfalls eine Generation später, sprich wenn .25 «stable» ist bzw. wenn der 24er mehr als drei Updates (wie im Moment) erfahren hat. Aber selbst dann wäre es noch ein heißes Eisen. D.h. erst einmal wäre mit dem Advent von .25 wohl .23 auf dem Server vertretbar — große Firmen sind aus Erfahrung her noch vorsichtiger. Den «Beta-Test» als Release zu verkaufen brachte Linux zwar mehr Momentum als zu früheren Zeiten, als man noch zwischen *Stable* und Developer-Kernel zu trennen wußte, aber zu welchem Preis? Ich genoß seit Mitte der 90er die Linux-Community und auch die Qualität die damit einher ging, bis zu jenem Zeitpunkt als Features mehr und mehr dominierten über Qualität — sprich hauptsächlich Quantität. Mit FBSD 5.x migrierte ich dann primär zu eben diesem System und beschäftige mich nur noch Sekundär mit Linux, da vor allem mit Slack und teils auch noch Debian.

  5. blub sagt:

    Nunja, wie ja immer wieder gerne (besonders aus der BSD Ecke) betont wird ist Linux ja eigentlich nur der Kernel. Worauf will ich jetzt hinaus…

    FreeBSD 7 ist jetzt knapp einen Monat draussen. FreeBSD wird wohl in knapp 2 Jahren fertig sein. Alle 6–9 Monate kommt ein neues .x Release, aber nicht alle Verbesserungen aus CURRENT fließen zurück. Ich finde das kann man ganz gut mit den «Enterprise» Distributionen wie Debian oder Redhat vergleichen. Bei Debian gibt es ja an sich nur Sicherheitsupdates und kleine Korrekturen. Redhat liefert schon etwas mehr, wie z.B. neue Treiber.

    Der Vergleich, den du bezüglich Qualität bringst vergleicht das FreeBSD OS mit dem Linux Kernel. Natürlich kann 2.6.25 nie im Leben so stabil wie z.b 2.6.18, der meines Wissens sowohl in RHEL als auch in Debian zum Einsatz kommt. Wenn ich jetzt also FreeBSD mit Debian vergleiche kommen wir uns in Punkto qualität schon näher, wobei ich bei Linux einen entscheidenden Vorteil sehe… Da der Kernel und der Rest des Systems unabhängig entwickelt werden habe ich mehr Auswahl, d.h wenn ich die neuesten Treiber, Performansupdates und sonstige Features brauche, installiere ich mir einfach einen neuen Kernel aber behalte im Gegenzug das stabile Restsystem. Was mache ich da bei FreeBSD? Ich kann CURRENT benutzen, aber da ist nicht nur der Kernel, sondern auch das komplette Userland experimentell.

    Daher schadet das neue Entwicklungsmodell Linux meiner Meinung nach kein Stück. Leute die einfach eine Kiste haben wollen die rennt und denen es egal ist ob der neue Kernel 2% schneller ist oder Hardware xy unterstützt benutzen einfach Debian, RHEL, CentOS, usw.. Der Rest hat die freie Wahl.

    Man sieht es sehr gut am kommenden Debian Lenny. Wahrscheinlich ende 2008 verfügbar wird es wohl mit 2.6.24 oder 2.6.25 auskommen. D.h 9 oder mehr Monate Zeit zum Testen. FreeBSD lässt sich ähnlich viel Zeit zwischen Feature Freeze und Release.

    Bei den Firmen die BSD einsetzen.. ist das jetzt in-house, also für die Server in der Firma oder auf den Geräten? Soweit ich weiß basiert doch das OS von Juniper auf FreeBSD. Google läuft komplett auf Linux, wäre mir neu wenn die da was ändern wollen, zumal auch ne Menge Kernelhacker bei Google arbeiten.

RSS-Feed abonnieren