Also, ich finde das Vorgehen, die OSS- Treiber aus dem Kernel zu nehmen reichlich verfrueht. Viele Anwendungen setyen noch auf OSS und die OSS-Emulation von Alsa laesst sehr zu wuenschen uebrig. Solange die Alsa OSS-Emulation nicht einwandfrei funktioniert sollte man OSS im kernel belassen!
Durch den Wegfall von OSS wird aber auch der Druck auf die Entwickler erhöht, sowohl das sie ihre Projekte auf ALSA portieren wie auch das der Emulator verbessert wird.
Zum einen kannst du ja ohne Probleme bei einem älteren Kernel bleiben. Zum anderen ist die Frage warum das bis heute so ist (ALSA ist jetzt schon lange genug im stabilen Kernel), lässt wohl leider vermuten, dass sich daran auch nichts mehr ändern wird...
Von zettberlin am Mo, 20. November 2006 um 10:01 #
>wobei die qualität bei der soundblaster live unter alsa schlechter ist als unter oss
Du meinst, alsa kann die vom chip angebotene Samplingrate/Auflösung nicht umsetzen?
Mal ehrlich: das glaube ich nun wirklich nicht. Digitalsound ist lediglich von technischen Spezifikationen abhängig, zwei völlig verschiedene Soundchips mit völlig verschiedenen Treibern klingen absolut unterschiedslos gleich, wenn sie 44100Hz/16bit wiedergeben und die gleichen DA/AD-Wandler benutzen. Unterschiede gibt es auf digitaler/Treiber Ebene lediglich bei der Latenz. Also entweder, ein Treiber funktioniert normal (dann ist die Art des Treibers für den Klang gleichgültig), oder gar nicht.
Hörbare Unterschiede können nur entstehen, indem die Wandler unterschiedlich angesteuert werden, das lässt sich dann im Mixer nachregeln.
>Du meinst, alsa kann die vom chip angebotene Samplingrate/Auflösung nicht umsetzen?
Glaub ich net er meint es wirklich subjektiv.
>Digitalsound ist lediglich von technischen Spezifikationen abhängig, zwei völlig verschiedene Soundchips mit völlig verschiedenen Treibern klingen absolut unterschiedslos gleich
Quatsch, wenn z.B. der DA wandler als R2R Netwerk ausgeführt ist, kommt es darauf an dass alle Widerstände gleichmäßig im Betrieb erwärmt werden damit die "analoge Pegel" der Wertigkeit der gewandelten Bits linear entsprechen. Bsp. Binar 01 ergibt 0,5 V Binär 10 ergibt 1V. Bei ungleichmäßiger Erwärmung des Wandlers könnte es z.B. dazu kommen 01 - 0,6V 10 -1,4V. Dies wird als "Qualitätsverlust" Wahrgenommen kann aber von nicht Technikern nur schwer "umschrieben" werden.
>Unterschiede gibt es auf digitaler/Treiber Ebene lediglich bei der Latenz.
Nein das ist definitiv falsch. Siehe Oben, der Treinber kann einfluss während der Ruhezeiten auf die Erwärmung nehmen, z.B. alle bits setzen damit fleißig gebrutzelt wird ........
> Also entweder, ein Treiber funktioniert normal
Was ist den "normal" ????
>Hörbare Unterschiede können nur entstehen, indem die Wandler unterschiedlich angesteuert werden, das lässt sich dann im Mixer nachregeln.
Meinetwegen wird er Druck auf irgendwelche Entwickler erhöht. Aber es wird auch der Druck auf Anwender erhöht, wieder zu Windows zu wechseln, weil wieder Mal irgend etwas nicht mehr geht.
ob es dann für vista entsprechende treiber für altgeräte noch geben wird, ist zu bezweifeln. also entweder alte windowskiste oder nicht ganz so alte linuxkiste oder selbst von hand einbauen.
Find ich aber bescheiden. Das Schöne an der OSS API ist doch, daß die Anwendungen eben nicht nur unter einem Unix-Derivat, in Eurem (ALSA) Fall GNU/Linux, laufen, sondern auch auf anderen. Die BSDs zum Beispiel haben eine Linux-Binärkompati- bilität, und während die nativen Sound- funktionen sunaudio sind, ist OSS mit nur einem Wrapper um die Funktion ioctl() trivial nachbildbar. Anwendungen, die ALSA verwenden, müssen hingegen auf an- deren Betriebssystemkernen ohne Sound auskommen.
nimmst du sdl, mußt du dir um den Sound keine Gedanken machen Alsa bei Linux, oss überall sonst ...
Davon abgesehen ist vieles einfach nicht mit oss machbar. Vielleicht sollten andere einfach auf den Alsazug aufspringen, statt an überholter Technik festzuhalten?
Genau. Am besten fangen wir unter Linux auch noch an, Jahrzehnte lang Altlasten mit uns herumzuschleppen und alles für den Fall der Fälle einfach mal im Kernel zu belassen, statt einfach mal einen Schlussstrich zu ziehen, wenn das Ende der Fahnenstange de facto erreicht ist.
Von zettberlin am Mo, 20. November 2006 um 10:08 #
>einfach mal einen Schlussstrich zu ziehen,
sehe ich genauso. OSS must die!! Es war technisch nicht schlecht und hatte durchaus auch Vorteile verglichen mit alsa aber alsa ist von vornherein zukunftsorientiert konzipiert und OSS eben nicht. Also Schluss damit! Wem die Anpassung seiner/ihrer Software für alsa zu schwierig ist (das ist es - OSS war schon einfacher in der Hinsicht), kann ja eine vergleichsweise einfache jackd-Schnittstelle einbauen - Musiksoftware benutzte jackd sowieso als Quasistandard.
Nur weil 01,% der User evtl noch so ein OSS Modul benötigt muss man es doch nciht mehr im Kernel lassen, man kann sie ja zusatzlich als Paket verfügbar machen es macht auf keinen Fall mehr Sinn das für die Masse anzubieten, vor allem weil die wahrscheinlich eh niemand mehr wartet. Ich benutze schon seit Jahren kein OSS mehr und war immer absolut zufrieden mit alsa.
Du kannst weiterhin ja Opensound.com nutzen, das ehemals kommerzielle oss von 4front ist ja seit einiger Zeit frei! Da hast du alle Treiber selbst für aktuellere Karten. Ich habe es selbst eine Weile benutzt da es stabiler und performanter als Alsa war/ist. Wenn du also das echte OSS benötigst, deaktiviere einfach ALSA im Kernel und installiere dir OpenSound.com.
Ansonsten reichen doch für die meisten Dinge die OSS-Emulation von Alsa aus. Im Kernel benötigt man wirklich das alte OSS nicht mehr an dem sowieso nichts mehr gemacht worden ist.
Nur zur zusätzlichen Info: Der Patch wurde bereits am 29. Juni in der LKML gepostet und in den Test-Tree von Andrew Morton aufgenommen. Nach für jedermann zugänglichen Tests wurde am 04. Oktober in Linus Kernel-Tree integriert (für die kommende Version 2.6.19).
Der Commit-Kommentar: [PATCH] The scheduled removal of some OSS drivers
This patch contains the scheduled removal of OSS drivers that: - have ALSA drivers for the same hardware without known regressions and - whose Kconfig options have been removed in 2.6.17.
Wer von den Krach schlagenden Postern hat sich denn inzwischen gemeldet (womöglich gar konstruktiv)? Es war monatelang Zeit...
Von Manfred Tremmel am Mo, 20. November 2006 um 13:54 #
Also ich setzte seit frühen alsa 0.5er Zeiten ausschließlich alsa Treiber ein, mir sind bis heute keine Probleme mit der OSS-Emulation aufgefallen. Ich kann jetzt auch nicht sagen, dass die Qualität bei der Soundblaster Live! zwischen OSS und Alsa unterscheiden würden.
1. Bei mir geht Quake4 nur mit OSS. 2. Ständig wechselnde APIs sind unter Linux ein absolutes Ärgernis. Unternehmen kaufen Software, die sie 5 bis 10 Jahre nutzen. Unter Linux kann man fast sicher sein, daß sie nach einem OS-Update nicht mehr laufen, es sei denn man kompiliert neu!
Ja, nach 6 Monaten musst du halt eine neue Version einspielen, dann geht es für Privatnutzer wieder gratis weiter. Die Treiber selbst sind übrigens erstklassig, ich habe mir vor Jahren mal eine Vollversion geholt. Mittlerweile kann ich ALSA nutzen und brauche OSS nicht mehr, aber damals wie gesagt Preis/Leistungsmäßig völlig in Ordnung.
> Ständig wechselnde APIs sind > unter Linux ein absolutes Ärgernis Stimmt.
Nur, kleiner Schönheitsfehler: In diesem beschriebenen Falle haben sich meines Erachtens ausgerechnet die APIs nicht geändert.
Aber ich lasse mich gerne eines Besseren belehren: Welche Kernel-API soll sich denn geändert haben, Dennis?
(Hint: Schon mal das Interface der existierenden OSS-Emulation in ALSA angeschaut? Die bleibt nämlich im Kernel erhalten. Es wird ein Treiber entfernt, nur ändert das nichts am "Application Programming Interface")
Also: Entweder Karten (sprich Infos) auf den Tisch, und auf technisch-sachlicher Ebene weiterreden. Oder vorsichtiger formulieren, lernen, und inhaltlich-konstruktiv etwas beitragen.
> Ständig wechselnde APIs sind unter Linux ein absolutes Ärgernis. > Unternehmen kaufen Software, die sie 5 bis 10 Jahre nutzen.
natürlich sind "Ständig wechselnde APIs" nicht gut, doch bei OSS -> alsa kann man wohl nicht davon sprechen. OSS ist an die technischen grenzen angestoßen, alsa wird seit jahren entwickelt, und es ist schon lange klar dass alas OSS ablösen wird. es ist auf keinen fall eine änderung der vollkommen unerwartet gekommen ist. das software 5 - 10 jahre genutzt wird kann sein, doch solche software - egal auf welchem system sie läuft - muss noch weiter gewartet werden. nicht mehr gewartete software ist per definition tote software. mit alsa ist sogar zu OSS applikationen kompatibel. wenn also software wegen der umstellung OSS -> alsa nicht mehr läuft, dann sollte man sich einfach mal an den softwarehersteller wenden.
> Unter Linux kann man fast sicher sein, daß sie nach einem > OS-Update nicht mehr laufen, es sei denn man kompiliert neu!
wie? was genau soll nicht mehr laufen?
> Bei mir geht Quake4 nur mit OSS.
dann sollte man versuchen das problem mit alsa zu beheben, statt an einer alten api festzuhängen.
Von Anonymous Coward am Di, 21. November 2006 um 00:46 #
1. Quake IV ist auch in der Lage, mit ALSA umzugehen. Wenn es bei Dir nicht funktioniert ist das ein Bug, aber wahrscheinlich nicht in ALSA sondern eher in Quake IV. 2. Die User Space-APIs sind unter Linux mindestens so stabil wie unter Windows. Schließlich kann man ALSA bis heute auch über den OSS-Wrapper ansprechen, und seit ALSA 1.0 ist auch dessen API stabil. Problematisch ist eher, dass das ABI des g++ lange Zeit immer wieder geändert wurde (2.95 -> 3.0 -> 3.1 -> 3.2 -> 3.4), aber damit hat es nun hoffentlich erstmal ein Ende.
Ihr schreibt u.a. "Treiber aus dem Kernel entfernt" sowie "ab dem kommenden Kernel 2.6.19".
Vielleicht habt Ihr ja einen speziellen Draht zu Linus Torvalds persönlich, aber ich glaube NICHT, dass in 2.6.19 diese Änderungen einfliessen werden (kleine Wette gefällig?).
Per jetzt (20.11.06, 13:00 MEZ) sind diese Änderungen NICHT in den offiziellen Kern von Linus eingeflossen (zu überprüfen unter http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=summary)
Wenn Ihr die LKML lest, stellt ihr fest, dass der Patch für den mm-Branch von Andrew Morton ist. Schon in der von Euch referenzierten Meldung steht bereits in der Überschrift (!) "[mm-sources]".
Der 2.6.19 befindet sich bereits beim Release Candidate 6.
Beim letzten Fade-Out eines OSS-Drivers brauchte es (siehe ein Posting von mir weiter oben) über drei Monate, bevor nach Ankündigung eines solchen Patches er auch Einzug in den offiziellen Kernel fand.
Bitte: präziser berichten!
Sonst regen sich die ahnunglosen Trolle hier noch viel zu sehr auf.
Der Wortlaut meiner Meldung wurde vor der Veröffentlichung verändert und ist dabei etwas verrutscht. Der Link zeigt ja auf das von mir betreute Blog zu den mm-sources, es sollte "Entwickler-Kernel" und "möglicherweise im kommenden Kernel 2.6.19 nur noch mit ALSA" heißen. Ich hab z.B. auch nicht "Opensound" geschrieben.
Ja, so etwas ist mir vor langer Zeit als ich mal eine Meldung für Pro-Linux schrieb auch passiert. Irgendwie glauben manche der Redakteure, sie wüssten auf jeden Fall mehr als der Autor
Von Matthias Popp am Mo, 20. November 2006 um 20:37 #
Bislang ist von Alsa noch garnichts rausgegflogen. In Sourcecode ist im OSS Code der Emu10K1 Teiber immer noch enthalten. 2.6.19-rc6 Warum bitteschön soll der Treiber erst jetzt rausfliegen. Nach RC1 tut sich nichts mehr gravierendes, bis auf Fehlerbereinigung. Ok, EXT4 war ne Ausnaheme. Heise und Golem muß man auch nicht alles glauben.
Von Matthias Popp am Di, 21. November 2006 um 14:56 #
Sorry ich hatte mich vertan, ich meinte natürlich OSS ist noch nicht komplett rausgeflogen. Ausßrdem habe ich den Sourcecode des 2.6.19-rc6 Kernels gerade vor mir liegen. Und da ist noch ein Großteil von OSS drinne enthalten Auch zum Beispiel der emu10k1 . Treiber. wenn du mir sagts um welche Soundkarte (lspci) es denn geht dann wäre es leichter einen passenden Alsa Treiber dafür zu finden. Außerdem was bis zum RC1 eines Kernels nicht geändert wurde , wird nachher auch nicht geändert, bis aufs fixen von Bugs. Und EXT4 war ne Ausnahme. Manchesmal wäre es ganz hilfreich man stöbert mal in der Kerneldoku ,obwohl die mancher Verbesserungen bedarf, und der Sourcecode selbst ist auch noch da. Und man muß nicht alles für Bare Münze nehmen was Golem und Co. absondern.
Zum anderen ist die Frage warum das bis heute so ist (ALSA ist jetzt schon lange genug im stabilen Kernel), lässt wohl leider vermuten, dass sich daran auch nichts mehr ändern wird...
Du meinst, alsa kann die vom chip angebotene Samplingrate/Auflösung nicht umsetzen?
Mal ehrlich: das glaube ich nun wirklich nicht. Digitalsound ist lediglich von technischen Spezifikationen abhängig, zwei völlig verschiedene Soundchips mit völlig verschiedenen Treibern klingen absolut unterschiedslos gleich, wenn sie 44100Hz/16bit wiedergeben und die gleichen DA/AD-Wandler benutzen. Unterschiede gibt es auf digitaler/Treiber Ebene lediglich bei der Latenz. Also entweder, ein Treiber funktioniert normal (dann ist die Art des Treibers für den Klang gleichgültig), oder gar nicht.
Hörbare Unterschiede können nur entstehen, indem die Wandler unterschiedlich angesteuert werden, das lässt sich dann im Mixer nachregeln.
Glaub ich net er meint es wirklich subjektiv.
>Digitalsound ist lediglich von technischen Spezifikationen abhängig, zwei völlig verschiedene Soundchips mit völlig verschiedenen Treibern klingen absolut unterschiedslos gleich
Quatsch, wenn z.B. der DA wandler als R2R Netwerk ausgeführt ist, kommt es darauf an dass alle Widerstände gleichmäßig im Betrieb erwärmt werden damit die "analoge Pegel" der Wertigkeit der gewandelten Bits linear entsprechen. Bsp. Binar 01 ergibt 0,5 V Binär 10 ergibt 1V. Bei ungleichmäßiger Erwärmung des Wandlers könnte es z.B. dazu kommen 01 - 0,6V 10 -1,4V. Dies wird als "Qualitätsverlust" Wahrgenommen kann aber von nicht Technikern nur schwer "umschrieben" werden.
>Unterschiede gibt es auf digitaler/Treiber Ebene lediglich bei der Latenz.
Nein das ist definitiv falsch. Siehe Oben, der Treinber kann einfluss während der Ruhezeiten auf die Erwärmung nehmen, z.B. alle bits setzen damit fleißig gebrutzelt wird ........
> Also entweder, ein Treiber funktioniert normal
Was ist den "normal" ????
>Hörbare Unterschiede können nur entstehen, indem die Wandler unterschiedlich angesteuert werden, das lässt sich dann im Mixer nachregeln.
Nein der mixer Reicht nicht aus siehe oben.
> nicht mehr geht.
Konkret: WAS soll nicht mehr gehen? Welcher Bug in der Emulation ist noch offen?
Ohne diese Angabe bleibt die Assage leeres Geblubber.
der OSS API ist doch, daß die Anwendungen
eben nicht nur unter einem Unix-Derivat,
in Eurem (ALSA) Fall GNU/Linux, laufen,
sondern auch auf anderen. Die BSDs zum
Beispiel haben eine Linux-Binärkompati-
bilität, und während die nativen Sound-
funktionen sunaudio sind, ist OSS mit
nur einem Wrapper um die Funktion ioctl()
trivial nachbildbar. Anwendungen, die
ALSA verwenden, müssen hingegen auf an-
deren Betriebssystemkernen ohne Sound
auskommen.
Davon abgesehen ist vieles einfach nicht mit oss machbar. Vielleicht sollten andere einfach auf den Alsazug aufspringen, statt an überholter Technik festzuhalten?
sehe ich genauso. OSS must die!! Es war technisch nicht schlecht und hatte durchaus auch Vorteile verglichen mit alsa aber alsa ist von vornherein zukunftsorientiert konzipiert und OSS eben nicht. Also Schluss damit! Wem die Anpassung seiner/ihrer Software für alsa zu schwierig ist (das ist es - OSS war schon einfacher in der Hinsicht), kann ja eine vergleichsweise einfache jackd-Schnittstelle einbauen - Musiksoftware benutzte jackd sowieso als Quasistandard.
Wenn du also das echte OSS benötigst, deaktiviere einfach ALSA im Kernel und installiere dir OpenSound.com.
Ansonsten reichen doch für die meisten Dinge die OSS-Emulation von Alsa aus. Im Kernel benötigt man wirklich das alte OSS nicht mehr an dem sowieso nichts mehr gemacht worden ist.
> laesst sehr zu wuenschen uebrig.
Inwieweit?
Hast Du die Probleme beschrieben, und ALSA einen entsprechenden Fehlerbericht zukommen lassen?
Falls ja, auf welchen beziehst Du Dich?
Falls nein, waum nicht?
Der Patch wurde bereits am 29. Juni in der LKML gepostet und in den Test-Tree von Andrew Morton aufgenommen. Nach für jedermann zugänglichen Tests wurde am 04. Oktober in Linus Kernel-Tree integriert (für die kommende Version 2.6.19).
Der Commit-Kommentar:
[PATCH] The scheduled removal of some OSS drivers
This patch contains the scheduled removal of OSS drivers that:
- have ALSA drivers for the same hardware without known regressions and
- whose Kconfig options have been removed in 2.6.17.
Wer von den Krach schlagenden Postern hat sich denn inzwischen gemeldet (womöglich gar konstruktiv)? Es war monatelang Zeit...
1. aoss
2. die oss-compat im (alsa)kernel
2. Ständig wechselnde APIs sind unter Linux ein absolutes Ärgernis. Unternehmen kaufen Software, die sie 5 bis 10 Jahre nutzen. Unter Linux kann man fast sicher sein, daß sie nach einem OS-Update nicht mehr laufen, es sei denn man kompiliert neu!
Man kann nur hoffen, das das die Hersteller von kommerzieller Software endlich dazu bringt, den Stand der Technik zur Kenntnis zu nehmen.
Bei mir läuft Quake4 mit ALSA, per default unter Slack und Ubuntu!!!
http://opensound.com/
Tolles Prog. Würden die Herren "normale" Preise verlangen, könnte man darüber reden. Aber für einen "Gerätetreiber" Mondpreise zu verlangen....
Egal - es gibt Alternativen zu dieser "Alternative".
> Unternehmen kaufen Software,
> die sie 5 bis 10 Jahre nutzen
Genau. Zum Quake spielen.
> unter Linux ein absolutes Ärgernis
Stimmt.
Nur, kleiner Schönheitsfehler: In diesem beschriebenen Falle haben sich meines Erachtens ausgerechnet die APIs nicht geändert.
Aber ich lasse mich gerne eines Besseren belehren: Welche Kernel-API soll sich denn geändert haben, Dennis?
(Hint: Schon mal das Interface der existierenden OSS-Emulation in ALSA angeschaut? Die bleibt nämlich im Kernel erhalten. Es wird ein Treiber entfernt, nur ändert das nichts am "Application Programming Interface")
Also: Entweder Karten (sprich Infos) auf den Tisch, und auf technisch-sachlicher Ebene weiterreden. Oder vorsichtiger formulieren, lernen, und inhaltlich-konstruktiv etwas beitragen.
Oder Windows nutzen.
> Unternehmen kaufen Software, die sie 5 bis 10 Jahre nutzen.
natürlich sind "Ständig wechselnde APIs" nicht gut, doch bei OSS -> alsa kann man wohl nicht davon sprechen. OSS ist an die technischen grenzen angestoßen, alsa wird seit jahren entwickelt, und es ist schon lange klar dass alas OSS ablösen wird. es ist auf keinen fall eine änderung der vollkommen unerwartet gekommen ist.
das software 5 - 10 jahre genutzt wird kann sein, doch solche software - egal auf welchem system sie läuft - muss noch weiter gewartet werden. nicht mehr gewartete software ist per definition tote software. mit alsa ist sogar zu OSS applikationen kompatibel. wenn also software wegen der umstellung OSS -> alsa nicht mehr läuft, dann sollte man sich einfach mal an den softwarehersteller wenden.
> Unter Linux kann man fast sicher sein, daß sie nach einem
> OS-Update nicht mehr laufen, es sei denn man kompiliert neu!
wie? was genau soll nicht mehr laufen?
> Bei mir geht Quake4 nur mit OSS.
dann sollte man versuchen das problem mit alsa zu beheben, statt an einer alten api festzuhängen.
2. Die User Space-APIs sind unter Linux mindestens so stabil wie unter Windows. Schließlich kann man ALSA bis heute auch über den OSS-Wrapper ansprechen, und seit ALSA 1.0 ist auch dessen API stabil. Problematisch ist eher, dass das ABI des g++ lange Zeit immer wieder geändert wurde (2.95 -> 3.0 -> 3.1 -> 3.2 -> 3.4), aber damit hat es nun hoffentlich erstmal ein Ende.
Ihr schreibt u.a. "Treiber aus dem Kernel entfernt" sowie "ab dem kommenden Kernel 2.6.19".
Vielleicht habt Ihr ja einen speziellen Draht zu Linus Torvalds persönlich, aber ich glaube NICHT, dass in 2.6.19 diese Änderungen einfliessen werden (kleine Wette gefällig?).
Per jetzt (20.11.06, 13:00 MEZ) sind diese Änderungen NICHT in den offiziellen Kern von Linus eingeflossen (zu überprüfen unter http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=summary)
Wenn Ihr die LKML lest, stellt ihr fest, dass der Patch für den mm-Branch von Andrew Morton ist. Schon in der von Euch referenzierten Meldung steht bereits in der Überschrift (!) "[mm-sources]".
Der 2.6.19 befindet sich bereits beim Release Candidate 6.
Beim letzten Fade-Out eines OSS-Drivers brauchte es (siehe ein Posting von mir weiter oben) über drei Monate, bevor nach Ankündigung eines solchen Patches er auch Einzug in den offiziellen Kernel fand.
Bitte: präziser berichten!
Sonst regen sich die ahnunglosen Trolle hier noch viel zu sehr auf.