Otazka je jestli se to vubec podari dostat do kernelu. Jeste pred par lety platilo v Linux pravidlo, ze: "Pokud HW neco neumi, tak ho ovladat NESMI emulovat". To se tyka i HW smesovani signalu. To byl taky jeden z duvodu pro pod Linexem poradne nikdy nefungovaly ruzne softwarove emulovane modemy.
V Linuxu neni zadna alternativa k Windowsim VxD. Pokud je alespon teoreticka sance, ze to bide fungovat v userspace, tak to nepatri do kernelu.
Treba volume manager EVMS, delal z userspace skoro vsechno, protoze se jeho autorum nepodarilo protlacit svuj kod do kernelu.
Nedostane sa to nikam. Nikto nebude prerabat desiatky existujucich ALSA driverov a stovky aplikacii. Ak chce nieco zmenit, tak moze diskutovat s vyvojarmi ALSA.
BTW: SW modemy funguju - v kerneli je maly driver a vsetko ostatne (softverove spracovanie signalu) robi demon v userspace. Problem je, ze je to vsetko uzavrety kod.
Souhlasím, že to nikam nepovede. Všechny zde uvedené problémy s alsou (kromě změny pořadí zvukovek, ale to se řeší konfigurací) jsou způsobené mrakem různých a hlavně zabugovaných konfigurací IntelHDA pro daný stroj/výrobní sérii i jednoho modelu, které se postupně po nahlášení do konference alsa-devel dostávají do nových jader. Přesun userspace kódu do kernelu nic z toho nevyřeší, ani nemůže. Ve windows to funguje, protože sám výrobce daného zařízení buď rovnou instaluje ovladač přímo šitý pro jeho paskvilí konfiguraci IntelHDA, nebo to dá microsoftu pro začlenění do dalších verzí (service packů?).
Blaa, bla, bla. V linuxu hlavne plati pravidlo, ze to, co je ucelne se tam dostane. Zadna dogmata. KLANG rozhodne ucelny je, nekteri holt potrebujeme realtime audio; jack prinasi problemy. Pokud je i ciste implementovany, neni vazne zadny problem (a nikdy nebyl).
Rychlost je dobry duvod, napr. FUSE funguje v userspace krasne - ale pomalu. Tak jsou filesystemy v kernelu, co je na tom spatnyho, ze.
Na kod v kernelu jsou vysoke kvalitativni pozadavky. Vyvojari EVMS, get used to it!