Eugenia Loli-Queru hat einen brief [1] an die alsa-entwicker bezüglich der 'sound-problematik' unter linux geschrieben. die meisten ohne eine hw-mixing-fähige soundkarte werden sich schon mit alsa, sound-daemons & co herumgeschlagen haben um mehreren applikation zugriff auf das sound device zu ermöglichen. nun ja, lest selbst:
[1] http://sourceforge.net/mailarchive/foru ... um_id=1752
die linux-audio-hw/sw-mixing problematik
die linux-audio-hw/sw-mixing problematik
[..] Linux is not a code base. Or a distro. Or a kernel. It's an attitude. And it's not about Open Source. It's about a bunch of people who still think vi is a good config UI. - Matt's reply on ESR's cups/ui rant
dämliche sorceforge mls.. kann da auch 'mal ein thread beinander bleiben?
http://sourceforge.net/mailarchive/foru ... um_id=1752
http://sourceforge.net/mailarchive/foru ... um_id=1752
[..] Linux is not a code base. Or a distro. Or a kernel. It's an attitude. And it's not about Open Source. It's about a bunch of people who still think vi is a good config UI. - Matt's reply on ESR's cups/ui rant
- Beowulf666
- Beiträge: 1476
- Registriert: 06.10.2002 14:03:08
- Wohnort: Lübeck
-
Kontaktdaten:
Die Problematik ist natürlich da, aber die Lösung imho auch: Jack ist ne leistungsfähiger Softwaremixer, der auch von immer mehr Programmen unterstützt wird.
Das Problem sind zur Zeit noch die KDE/Gnome internen Mixer, die an Kack nicht herankommen. Daher hat Jack zur Zeit noch keine grosse Verbreitung gefunden. Und wird es auch nicht, solange keine direkt lauffähigen Defaultwerte vorgegeben sind. Ich find die Installation noch nen bisschen aufwendig. Aber wenn das tut, und graphische Konfigtools für Gnome und KDE zur Verfügung stehen, sollte das Problem schon fast gelöst sein.
Ich hab die Diskussion jetzt nicht komplett gelesen, aber ich sehe das Problem nicht. Windows/Mac/MacOSX oder irgendein anderes OS machen das doch nicht anders, oder?
Unter Linux ist nur das "Problem", dass sich ein Tool als Standard nicht etabliert hat.
Das Problem sind zur Zeit noch die KDE/Gnome internen Mixer, die an Kack nicht herankommen. Daher hat Jack zur Zeit noch keine grosse Verbreitung gefunden. Und wird es auch nicht, solange keine direkt lauffähigen Defaultwerte vorgegeben sind. Ich find die Installation noch nen bisschen aufwendig. Aber wenn das tut, und graphische Konfigtools für Gnome und KDE zur Verfügung stehen, sollte das Problem schon fast gelöst sein.
Ich hab die Diskussion jetzt nicht komplett gelesen, aber ich sehe das Problem nicht. Windows/Mac/MacOSX oder irgendein anderes OS machen das doch nicht anders, oder?
Unter Linux ist nur das "Problem", dass sich ein Tool als Standard nicht etabliert hat.
Jetzt auf SID mit Kernel 2.6.16.1 + XOrg + XFCE4.2.3: Noch mehr POWER!!!!
Next Step: Binford 8000 Super Debian
Next Step: Binford 8000 Super Debian
nicht zwangsläufig. imho ist das problem, dass alsa überhaupt irgendeiner applikation exklusiven zugriff auf die h/w gibt. zumindest bei h/w mit einem kanal. wie in der diskussion angesprochen, kann es ja nicht sinn der sache sein, auf userspace-lösungen zu warten. es sollte mehr oder minder völlig egal sein, was meine applikation macht, der sound sollte trotzdem aus den boxen kommen. cedega ist da so ein beispiel. alles andere funktioniert ja recht gut via dmix.
[..] Linux is not a code base. Or a distro. Or a kernel. It's an attitude. And it's not about Open Source. It's about a bunch of people who still think vi is a good config UI. - Matt's reply on ESR's cups/ui rant
- Beowulf666
- Beiträge: 1476
- Registriert: 06.10.2002 14:03:08
- Wohnort: Lübeck
-
Kontaktdaten:
sehe ich ehrlich gesagt anders. Die Hardware stellt in dem grössten Teil aller Fälle nur einen Kanal zur Verfügung, und die einzige Aufgabe des Treibers ist das zur-Verfügung-stellen im Userland.
Und da zählt für mich auch nicht die exclusive Belegung dieser Ressource. Nen Brenner kannst du ja auch nicht multitasking belasten, und das ist auch nen ganz "normaler" Stream von Daten. (Ich gebs zu, ist nen bescheidener Vergleich )
Aber das Mixing ist imho definitiv Softwaresache und gehört nicht in den Kernel. Wenn mehrere Applikationen dadrauf zugreifen sollen, muss es eine Art von Softwaremixing oder Printerqueue geben.
Und da zählt für mich auch nicht die exclusive Belegung dieser Ressource. Nen Brenner kannst du ja auch nicht multitasking belasten, und das ist auch nen ganz "normaler" Stream von Daten. (Ich gebs zu, ist nen bescheidener Vergleich )
Aber das Mixing ist imho definitiv Softwaresache und gehört nicht in den Kernel. Wenn mehrere Applikationen dadrauf zugreifen sollen, muss es eine Art von Softwaremixing oder Printerqueue geben.
Jetzt auf SID mit Kernel 2.6.16.1 + XOrg + XFCE4.2.3: Noch mehr POWER!!!!
Next Step: Binford 8000 Super Debian
Next Step: Binford 8000 Super Debian
Schade, dass sich der Typ nicht mal wirklich mit der Problematik auseinandergesetzt hat, bevor er den Krempel gepostet hat. Unter WIndows zum Bleistift fangen die Probleme wirklich an, wenn man mal etwas "hochwertigere" Soundhardware anschliesst...
Er hat natürlich in sofern Recht, dass die aktuelle Situation sehr unbefriedigend ist. Auf der anderen Seite ist diese Situation aber direkte Folge der Philiosphie hinter ALSA und der Tatsache, dass ALSA keine Sau zu interessieren scheint...
Angenommen man würde bei Karten ohne HW-Mixer direkt Software-Mixing implementieren. Dann könnte man sich direkt von dem Feature der Echtzeit-Applikation verabschieden. Wenn man sieht, dass das ALSA-dmix selbst auf einem Athlon XP mit 2 GHz teilweise nicht hinterherkommt - dann will ich Software-Mixing auf einem kleineren Rechner gar nicht automatisch haben.
Die Tatsache, dass viele Applikationen das ALSA-Default Device nicht unterstützen liegt imho daran, dass der aktuelle ALSA-Code noch buggy ist (was imho daran liegt, dass letztlich nur zwei Leute dran arbeiten) und zum anderen schlicht daran, dass die ALSA-Anbindung meist sehr schlecht (was auch an der mangelhaften ALSA-Doku liegen mag) ist. Wenn diese beiden Punkte behoben werden, kann man ALSA per default zum Software-Mixing überreden. Die Konfiguration wäre dann aber wieder Sache der Distribution (out of the box) und nicht unbedingt der ALSA-Entwickler.
Er hat natürlich in sofern Recht, dass die aktuelle Situation sehr unbefriedigend ist. Auf der anderen Seite ist diese Situation aber direkte Folge der Philiosphie hinter ALSA und der Tatsache, dass ALSA keine Sau zu interessieren scheint...
Angenommen man würde bei Karten ohne HW-Mixer direkt Software-Mixing implementieren. Dann könnte man sich direkt von dem Feature der Echtzeit-Applikation verabschieden. Wenn man sieht, dass das ALSA-dmix selbst auf einem Athlon XP mit 2 GHz teilweise nicht hinterherkommt - dann will ich Software-Mixing auf einem kleineren Rechner gar nicht automatisch haben.
Die Tatsache, dass viele Applikationen das ALSA-Default Device nicht unterstützen liegt imho daran, dass der aktuelle ALSA-Code noch buggy ist (was imho daran liegt, dass letztlich nur zwei Leute dran arbeiten) und zum anderen schlicht daran, dass die ALSA-Anbindung meist sehr schlecht (was auch an der mangelhaften ALSA-Doku liegen mag) ist. Wenn diese beiden Punkte behoben werden, kann man ALSA per default zum Software-Mixing überreden. Die Konfiguration wäre dann aber wieder Sache der Distribution (out of the box) und nicht unbedingt der ALSA-Entwickler.