PulseAudio kontratakuje
- Dodano: 23 lutego 2008
- Wprowadził: kocio
- Komentarze: 74
Twórca PulseAudio, Lennart Poettering, stwierdził, że sytuacja z API dźwięku pod Linuksem wygląda kiepsko i nawet samo PA nie jest dobrym rozwiązaniem. Dlatego od ponad roku pracuje nad API o nazwie libsydney.
Libsydney ma być w przyszłości jedynym rdzennym API PulseAudio. Jego wejście na linuksową scenę ma być o tyle łatwiejsze, że pakiety PA stały się już częścią wielu dużych dystrybucji, więc formalnie będzie to tylko zmiana numeru wersji.
To jednak na razie pieśń przyszłości: libsydney zostało naszkicowane rok temu w Sydney w ramach zlotu FOMS 2007 (Foundations of Open Media Software) i do dziś pozostaje „właściwie Duke Nukem Forever wśród API dźwięku”. Niemniej powstała lista dyskusyjna projektu, a komunikat z tegorocznego FOMS oficjalnie o nim wspomina.
Szczegółowe wyjaśnienia na temat powodów, które doprowadziły do powstania libsydney, oraz cele stawiane przed nowym API, Poettering zamieścił na swoim blogu. Ma być naprawdę międzyplatformowe, oferować natychmiastową reakcję na działania użytkownika nawet przy dużych buforach (stosowanych często przy transmisjach sieciowych), świetnie się skalować i być łatwe w użyciu dla programistów.
Więcej informacji: http://0pointer.de/blog/projects/foms-lc...recap.html
Znalazłeś literówkę? Zgłoś ją używając formularza!
Jeśli uważasz, że ten nius jest nieobiektywny, przedstawia nieprawdziwe wydarzenie, jest spamem lub nie spełnia standardów serwisu, napisz raport.
Niusy na podobny temat:
Komentarze są prywatnymi opiniami dodających je osób. Prosimy o zachowanie kultury wypowiedzi. Komentarze obraźliwe oraz obniżające poziom serwisu będą usuwane. Więcej w regulaminie komentowania.
74 komentarzy
Wszystkie autorskie niusy w serwisie publikowane są na licencji Creative Commons Uznanie autorstwa 2.5 Polska.
Heh, super. Kolejna biblioteka do obsługi dźwięku. Starsze programy i tak zostaną przy ALSA, jeszcze starsze przy OSS, a są i takie (głównie gnomowe) co używają od 6 lat nierozwijanego EsounD…
Ja rozumiem tą wolność wyboru itp. ale system obsługi dźwięku jest naprawdę czymś, co powinno być jedno – jak kernel i glibc
. Potrzebna jest współpraca i stworzenie jednolitego interfejsu, bo za pół roku ktoś dojdzie do wniosku, że ma lepszy pomysł i dorzuci cegiełkę do istniejącego bałaganu…
No przecież już jest OSS4 – pracuje na wszystkich platformach od windows przez posixy takie jak solaris freebsd haiku macosx kończąc na linuksie. Czy może być coś piękniejszego? Wiele uprzędzeń ludzi do OSS wzięło się ze starej wersji OSS3 a że ludzi lubią żyć stereotypami.. to dalej się dystansują do niego mimo, że jest o wiele lepszy niż ALSA i łatwiejszy w implementacji.
Może – u mnie nie działa, mam za starą kartę dźwiękową (którą jednak alsa obługuje bez problemu, ale ma inne wady).
Yylko coś z jego siłą przebicia nie tak… – ja jestem za tym by był jeden dobry sound driver.
W ogóle albo czegoś ja tu nie rozumiem, albo cała dyskusja o OSS4 jest NIE NA TEMAT – bo w temacie nie ma mowy o sterowniku do dźwięku (jak OSS3/4, ALSA) tylko o API do dżwięku, czyli coś poziom abstrakcji wyżej (jak GStreamer, ESounD, wspomniane PulseAudio, aRts czy JACK, OpenAL też?). Oczywiście sterowniki udostępniają prymitywne API (OSS way via /dev/dsp czy też ALSA way) – a to, że programy używają właśnie tego API sterowników jest wyłącznie wynikiem burdelu w bibliotekach i zbyt dużej ilość tych wysokopoziomowych API, stąd dla większej kompatybilności (zamiast pisać wtyczki do JACK, Gstreamera i Bóg wie tam czego) autorzy oprogramowania (jak skype, czy developerzy gier) idą po najbardziej kompatybilnej linii oporu – za co nie można ich absolutnie winić.
podsumowując – "rozstrzelać" twórców alternatywnych API do dźwięku i wybrać JEDNO najlepsze (niech sobie będą alternatywne implementacje bibliotek, byle jeden interfejs – API) – podobnie w przypadku sound drivers. Tutaj od przybytku głowa BOLI.
Oczywiście sterowniki udostępniają prymitywne API (OSS way via /dev/dsp czy też ALSA way)
I już sam sobie odpowiedziałeś odnośnie tego, czy dyskusja jest na temat.
które jednakże jest na tyle prymitywne, że wciąż jakoś powstają "bzdurne" pomysły żeby tworzyć PulseAudio, GStreamery, ESoundy i inne zwierzaki powodujące zamęt
OSS4 nie jest rewelacyjnym rozwiązaniem, mam głośniki w układzie 5.1 i co prawda OSS4 je wszystkie widzi na portach (sprawdzałem pod osstest) to jednak nie ma wirtualnej duplikacji kanałów i dodatkowo żaden program nie umie emulować 5.1 pod OSS4 (jak mp3 jest 2kanałowe to grają tylko 2 głośniki, w filmach 5.1 nie ma tego problemu). W KDE4 nie działa w ogóle (może coś się zmieniło pod 4.0.1 testowałem na 4.0.0), na alsie moja karta dźwiękowa jest widziana jako dwukanałowa (2.0), tylne głośniki i center/subwoofer w ogóle nie działają, próbowałem wszystkich możliwych rozwiązań dostępnych na forach i pod różnymi dystrybucjami i nic, jedynie w Sabayonie 3.3 minicd działały pod starą wersją ALSA.
Jak ktoś wie jak przekierować te porty pod OSS4, darmowym/otwartym programem (jest oss3d ale jest płatny) to proszę pisać na maila linnvv@gmail.com. Na windowsie nigdy nie miałem problemów z nie wykrywaniem głośników a wszystkie potrzebne sterowniki były za darmo.
na stronie 4Front Technologies, wszystko znajdziesz było to wałowane wielokrotnie
Ileż razy można powtarzać: esd, arts, pulseaudio itp. to co innego niż ALSA i OSS. Nie ta warstwa.
Natomiast bibliotek w wyższych warstwach zaczyna się rzeczywiście mnożyć niepotrzebnie dużo.
Nie rozumiem Twoich zastrzeżeń. Ja osobiście cieszę się, że powstaje nowa biblioteka – wszak możliwość wyboru jest dobra! Martwi mnie tylko monopolizacja rynku linuksowego przez X Window System. To w najwyższym stopniu niepokojące! Należy podjąć kolektywny wysiłek syworzenia co najmniej sześciu alternatywnych systemów obsługi grafiki, aby każdy mógł wybrać coś dla siebie. Można zacząć od wskrzeszenia projektu – jak o nię nazywał – Berlin?
Żałosna prowokacja.
Czy ja wiem, czy taka znowu "żałosna"… ten wątek przypomina mi nieco wymianę zdań odnośnie formatu pakietów, gdzie też zachwalana była "konkurencja", na zasadzie: "bo tak". Ot: "konkurencja dla samej konkurencji".
Bezrefleksyjnym fanatykom "konkurencji" zalecam rozważenie hipotetycznej sytuacji, w której np. zlikwidowanoby Polskie Normy – a śrubki w sklepie z żelazem można byłoby sobie wybierać spośród tuzina "konkurencyjnych" skoków gwintu (przy jednej, i tej samej średnicy). Oczywiście: "ku zadowoleniu klienta, i żeby miał wybór". Żeby go już "nigdy więcej nie zmuszano" do gwintu znormalizowanego.
Otóż: konkurencja NIE JEST celem "samym w sobie"; konkurencja jest jedynie ŚRODKIEM do tego, aby "wygrało najlepsze". Jeśli na dzień dzisiejszy (podobno) najlepszy jest OSS4 – to konkurencję (na dziś) zasadniczo można uznać za zakończoną, i ogłosić zwycięzcę. A za jakiś czas może ktoś wymyśli coś lepszego.
Najlepszym powyższego dowodem jest choćby "wygryzienie" z kernela "starego" OSS, gdy uznano, że jest zbędny (malejąca ilość starych kart w użyciu), a w ogóle to oferuje mniej, niż ALSA. Czyli gdy uznano, że konkurencja OSS3 i ALSA została ZAKOŃCZONA wygraną ALSA-y.
Uwaga końcowa: jak widać, wielu osobom konkurencja najwyraźniej miesza się z brakiem standaryzacji. Tymczasem konkurować można także w ramach jednego i tego samego standardu, czy przyjętego rozwiązania. Czyżby normalizacja wymiarów gwintów miała oznaczać, że nie może być wielu konkurujących ze sobą producentów śrubek? To jakieś kompletne pomylenie, o co właściwie w tej konkurencji chodzi, i czarowanie oponentów sugestiami: "jak nie lubisz konkurencji, to jesteś komuch". Taka skrajna, posunięta do absurdu "konkurencja" ma przecież swoją nazwę: nazywa się anarchią. Wtedy wszyscy "konkurują" ze wszystkimi, w każdej możliwej dziedzinie.
Pewnie nie zauważyłeś, ale w tym wątku NIKT jak dotąd nie wychwalał konkurencji dla samej konkurencji. Nikt, poza mk, który wykorzystał to w ironiczny sposób aby wzniecić flejma. Dlatego jego prowokacja jest żałosna.
…to widzę, że nie ja jeden na niniejszym forum (niekoniecznie akurat w tym wątku) zauważyłem, iż wielu produkujących się tutaj piewców konkurencji tak naprawdę nie za bardzo wie, "co to ta konkurencja jest, i do czego służy".
wolne żarty – ktoś tu nie rozróżnia prowokacji od ironii (skądinąd bardzo na miejscu)
Ironia byłaby na miejscu, gdyby rzeczywiście pojawili się 'piewcy konkurencji'…
@Z
Otóż to – nie w tym wątku! To po grzyba o tym pisać, skoro nie ma nic wspólnego ani z tematem, ani z tokiem dyskusji? Prowokacja i tyle.
No przecież już się (co najmniej) jeden pojawił; popatrz na wpis niejakiego "jr".
@Z:
To chyba ze mną dyskutowałeś
To jest standard i jak najbardziej powinien być jeden. Mam na myśli to, że tam nie ma wiele do wymyślenia i to czy śrubki się mierzy w calach czy w centymetrach nic nie zmienia a wprowadza niepotrzebny bałagan. Jestem jak najbardziej za ustandaryzowanym API dźwięku (nie wiem czy to jest w ogóle realne do wykonania). Jestem również za konkurencyjnymi implementacjami tego API.
Oczywiście. Tylko nie bardzo rozumiem dlaczego chcesz ograniczać tą konkurencję.
Zgodnie z twoim rozumowaniem OSS nie miałby szans wygrać tej rywalizacji. Już raz był gorszy od alsy i powinien zostać porzucony. Konkurencja to proces ciągły i nie można uznawać jej za zakończoną. Po zakończeniu konkurencji przestaje ona działać i jakość danego wyrobu spada.
…no i został przecież porzucony…
…a teraz powraca jako OSS4. Jeśli faktycznie ma przewagi – będzie miał okazję na "drugie rozdanie". Jeśli ALSA jest gorsza: przegra w tej konkurencji, i znowu na jakiś czas ona się zakończy. Taki jest jest jedyny sens: wyłonienie zwycięzcy.
Natomiast sztuczne "podtrzymywanie konkurencji" jakoś "w imieniu różnorodności" to już czysta, oderwana od życia ideologia. Tobie najwyraźniej się zdaje, że "nie chodzi o to, żeby złapać króliczka – lecz by gonić go". Ja jestem innego zdania.
A co do "wyrobu":
1. Jego jakość dopiero spadnie, jak developerzy dadzą sobie z nim spokój, nie mając ochoty mordować się z tuzinem API "do dźwięku", bo nigdy nie wiadomo, co tam może sobie wybrać końcowy użytkownik.
2. Ustawicznie mieszają Ci się "wyroby" ze standardami.
Przerzucanie się z jednego standardu na niezgodny z nim drugi średnio co 2 – 3 lata jest równie fatalnym rozwiązaniem co utrzymywanie obu naraz.
Zapewne – ale, o ile dobrze pamiętam, to chyba główną przyczyną "przerzutki" było to, że OSS3 "zastygł w rozwoju", OSS4 był produktem komercyjnym, a ALSA – jaka jest, taka jest – ale jest darmowa i rozwijana. Nie robiono tego chyba jedynie po to, "żeby było inaczej".
Z drugiej strony: skoro OSS4 został "uwolniony" – a faktycznie oferuje znacznie więcej, niż ALSA, to – biorąc pod uwagę, że byłoby to wspólne API dla dźwięku także w przypadku systemów xBSD – summa summarum sugeruje to wysoką "opłacalność" takiego kroku. Znaczy: kłopoty będą – ale przejściowe, a potem to już "sama uciecha".
Nie bardzo rozumiem skąd to wziąłeś. Kto chce sztucznie podtrzymywać konkurencję? Przecież ta konkurencja powstała naturalnie. To ty byś chciał sztucznie wyłonić zwycięzcę.
Przecież napisałem, że samo API powinno być ustandaryzowane (o ile to możliwe). Wtedy ALSA i OSS byłyby ze sobą kompatybilne.
Ale przecież ALSA i OSS to są wyroby.
Och, rozumiem. Przecież OSS3 był produktem o zamkniętym kodzie, w dodatku obwarowanym patentami, więc Społeczność absolutnie nie miała możliwości kontynuować jego rozwoju, co jest przecież tak szeroko opiewaną zaletą Open Source. W zamian została zmuszona do porzucenia tego zamkniętego rozwiązania na rzecz niekompatybilnego.
Wcale przecież nie jest tak, że Społeczność jako taka ma w głębokim poważaniu użytkowników swoich wytworów i zajmuje się jedynie udowadnianiem sobie nawzajem kto ma większego.
Przepraszam, chciałem napisać większe-ego.
Nie wiem – nie śledziłem tego aż tak uważnie – dla żywotnie zainteresowanych szczegółami decyzji o porzuceniu OSS3 na rzecz ALSA są Google, i przepastne archiwa Sieci. Tam na pewno będzie więcej informacji na ten temat, niż w niniejszym wąteczku.
Ja w każdym razie nie miałem "możliwości kontynuować jego rozwoju", bo w programowaniu dźwięku, póki-co, "nie siedzę". Z tego, co w swoim czasie czytałem, wynikałoby, że najwięcej na ten temat do powiedzenia miał niejaki Tomasz Kłoczko – więc można jego wypytać, jeśli komu zależy.
O ile mi wiadomo, nie jest to możliwe – więc po co to bicie piany.
Ale przecież ALSA i OSS to są wyroby
ALSA i OSS to są narzędzia – a "wyroby" to są dopiero XMMS, MP3blaster i inne takie. Zaś API ALSA/OSS to właśnie można umownie określić jako pewien standard.
Innymi słowy: śrubki to są wyroby, a PN określają standardy. I likwidacja PN "w imię różnorodności i konkurencji" spowoduje więcej szkód i oczywistej niewygody, niż jakiegokolwiek pożytku dla kogokolwiek. No, oprócz jednego "jr" – ucieszonego, że tak pięknie konkurencja kwitnie.
Co to znaczy pewien standard? Twierdzisz, że nie da się ustandaryzować API. W takim razie należy stworzyć oddzielną warstwę abstrakcji i dla niej napisać standardowe API. Bardzo możliwe, że właśnie PulseAudio wprowadzi taki standard.
Czyli twierdzisz, że sterowniki sprzętu to odpowiednik PN? E tam.
…to stwórz – i napisz, skoro lepiej wiesz, co "trzeba".
W pewnym – przenośnym – sensie: śrubki (wyroby) muszą "być kompatybilne z PN", zaś XMMS czy inny Amarok (też wyrób) – musi umieć korzystać ze sterowników.
To jak z tymi śrubkami? Pozbywamy się PN w imię niczym nie skrępowanej (nawet normami) konkurencji?
To że wiem lepiej nie oznacza, że mam odpowiednie umiejętności i chęci żeby to zrobić. Z resztą możliwe, że właśnie PulseAudio wypełni tę niszę.
Proszę czytaj uważniej. Wiele razy już mówiłem, że API powinno być standardowe, natomiast implementacja tegoż nie powinna być jedyna. W ogóle ALSY nie można uznać za standard np. dla tego, że jest unikalna dla Linuksa, czyli nie spełnia podstawowego zadania standardu – zwiększania interoperacyjności.
Jak na razie, to "wiele razy mówiłeś, że mówiłeś" – a rzekomego "oświadczenia pierwotnego", na które się tak gorliwie powołujesz, nijak nie można się doszukać. :]
…w ogóle to z niejaką rozpaczą czepiłeś się słówka "standard", którego użyłem w znaczeniu przenośnym. Zastąp je sobie słówkiem "rozwiązanie techniczne", jak Ci ten "standard" tak przeszkadza, i daj już spokój z tym wekslowaniem "w stronę terminologii".
Trochę mi głupio, że cytuję sam siebie, ale jeśli Ci się nie chce poszukać to proszę:
.
W takim razie Cię nie zrozumiałem. Moim zdaniem rozwiązania techniczne powinny się rządzić prawami konkurencji.
Myślę, że wypada zrobić EOT, bo poziom merytoryczny dyskusji spada.
To napisałeś dopiero o 16:17 – a jeszcze o 15:29 byłeś za "konkurencją". Czyli w poście pierwotnym nic o tym nie było.
…no więc się rządzą – a rozwiązania, które są słabsze, znikają z tegoż rynku – przez co konkurencja (na jakiś czas przynamniej) zostaje ograniczona, lub na stałe wyeliminowana. A tutaj co poniektórzy jojczą, że Alsę to trzeba utrzymać koniecznie, żeby konkurencja była.
Tyle, że cały czas – z braku argumentów – z uporem czepiasz się słówek (bardzo to "adwokackie"): bowiem "rozwiązanie techniczne", którym jest ALSA, ma przecież konkretny wpływ na pracę programistów "tych od dźwięku" – i im wcale nie jest obojętne, "czy ci Linuksiarze wreszcie się na coś zdecydują", czy też trzeba będzie brać pod uwagę tuzin "konkurencyjnych rozwiązań" jednocześnie.
No, zwykle tak jest, kiedy ktoś nie umie powiedzieć "nie miałem racji" – tylko "idzie w zaparte"… możemy zatem zEOTować.
Tak, tylko nie bardzo rozumiem gdzie widzisz sprzeczność. Jestem za konkurencją w implementacji standardów. Przy czym chodzi mi o prawdziwe standardy, a nie o to żeby wybrać jakiekolwiek rozwiązanie i stwierdzić, że jest ono od dziś standardowe.
No popatrz. I się okazało, że mamy dokładnie ten sam pogląd.
Jeśli wydaje Ci się, że chcę sztucznie podtrzymywać konkurencję, tylko po to żeby istniała to się mylisz. Ja po prostu uważam, że konkurencji nie powinno się sztucznie ograniczać.
To są problemy przejściowe, które powinny zostać rozwiązane w ciągu kilku najbliższych lat. Gdyby ALSA była rozwiązaniem wystarczającym, to by nie było tego bałaganu. Te wszystkie rozwiązania powstały z jakiegoś powodu i nie było to widzimisię autorów. Jeśli narzucimy ludziom używanie jedynie ALSY to krótkoterminowo będzie lepiej, ale problemy zaczną się gdy się okaże, że ALSA już nie wystarcza a innych rozwiązań brak – nie powstały bo wszyscy używali standardowej ALSY.
Wiesz, mało mnie obchodzi czy to warstwa wyższa, niższa czy środkowa. Wiem z autopsji, że się gryzą, i tyle.
Nie ta warstwa ale tylko w przypadku ALSY, OSS4 pracuje na dwóch warstwach. PulseAudio powstało tylko po to by ułatwić obsługę dzwieku kiedy korzysta się z ALSY..
@Thar:
A ja jestem za jak największą różnorodnością. Open source rozwija się ewolucyjnie, a ewolucja wręcz wymaga "bałaganu", ślepych ścieżek i "zmarnowanego" wysiłku. Jeśli spojrzysz na open source trochę szerzej, to jądro Linuksa nie jest jedyne. Jest BSD, Hurd, Solaris i na wszystkim działa ten sam soft. To, że Linux ma najwięcej użytkowników, to oznaka, że się najlepiej przystosował. Zresztą git, niemal prowokuje do robienia forków i Linus jakoś się tego nie boi. Ja osobiście byłbym bardzo szczęśliwy, gdyby glibc się dorobiło jakiejś konkurencji.
Wiec zgodnie z logika ewolucji Open Source może kiedyś zniknąć z rynku. Na przykład, z braku wykrystalizowania się powszechnie używanych standardów w ramach OS.
A co tam Open Source – kiedy przecież "wygra różnorodność"…
No cóż. To akurat skutek uboczny, z którym ja się godzę a Ty nie. Postulujesz, żeby całe BSD wyrzucić na śmietnik a jego developerzy zajęli się jakąś produktywną pracą przy kernelu linuksa?
Gdzie postuluję? Każdy może sobie pisać własny system operacyjny (a nawet kilka) – jeśli tylko ma na to ochotę. Nawet, jeśli rzeczony autor będzie jedynym użytkownikiem swego (wspaniałego, znakomitego…) systemu operacyjnego.
Oczywiście, ale buńczuczne zapowiedzi, że wzmiankowany system już tuż-tuż, najdalej za pół roku osiągnie niebywały sukces i zagości na biurku przeciętnego Kowalskiego można co najwyżej skwitować pogardliwym wzruszeniem ramion.
uclibc – dobra konkurencja glibc w embedded zastosowaniach… od lat…
Od kiedy jest jeden kernel? I od kiedy glibc się buduje na wszystkim? Esound dawał przynajmniej jakieś podwaliny do tego, żeby na różnych platformach i implementacjach obsługi dźwięku można było zawsze tak samo pisać aplikację używającą dźwięku. A wiele aplikacji obsługuje esound, dlaczego by jego nie rozwijać (np. jego znaczy).
OSS4 ma swoje wady już była o tym dyskusja i radzę nie wychwalać czegoś co jest optymalizowane a nie optymalne. ALSA ma swoje wady, ale zalet ma jeszcze więcej tylko dobra wola developerów by wykorzystać ten potencjał. Ciekawe kiedy doczekamy się obsługi efektów 3D, bo o tym w OSS można zapomnieć.
od wersji OSS3,5 obsługuje już 5.1 ;]
Nie mówię o obsłudze dźwięku przestrzennego jako takiego, ale efektach dodatkowych. Kolega słyszał kiedyś Aural Vortex 2 w działaniu? Mówię o pełnym interaktywnym wykorzystaniu możliwości kierowania źródłem dżwięku, to co obecnie mamy to namiastka. OSS tego natywnie nie daje, o obsłudze tego w ALSA programiści co jakiś czs przebąkują, a efektów brak. OSS ma jedną i tylko jedną zaletę, ładnie udokumentowane API reszta podobna lub nawet gorsza od rozwiązania przyjętego przez twórców Linuksa.
PulseAudio próbuje wypromować siebie jako Linuksowy standard, ale wolał bym bardziej skupić się na OpenAL zaimplementowanym w Windows i MAC OSX. Wiem, że to co pisze może wydawać się dziwne, lecz przez te ciągłe wojenki opóźnia się standaryzacja i niekompatybilność aplikacji.
Nie mówię o obsłudze dźwięku przestrzennego jako takiego, ale efektach dodatkowych. Kolega słyszał kiedyś Aural Vortex 2 w działaniu? Mówię o pełnym interaktywnym wykorzystaniu możliwości kierowania źródłem dźwięku, to co obecnie mamy to namiastka. OSS tego natywnie nie daje, o obsłudze tego w ALSA programiści co jakiś czas przebąkują, a efektów brak. OSS ma jedną i tylko jedną zaletę, ładnie udokumentowane API reszta podobna lub nawet gorsza od rozwiązania przyjętego przez twórców Linuksa.
PulseAudio próbuje wypromować siebie jako Linuksowy standard, ale wolał bym bardziej skupić się na OpenAL zaimplementowanym w Windows i MAC OSX. Wiem, że to co pisze może wydawać się dziwne, lecz przez te ciągłe wojenki opóźnia się standaryzacja i niekompatybilność aplikacji.
OSS ma jeszcze trzy istotne zalety – przenosnosc (ALSA jest proprietarna, nieprzenosna na nic poza Linuksem), dokumentacje oraz sensowne, nieprzebajerzone API.
racja, a tak nawiasem co myslicie o takich projektach jak SALSA – ALSA Library Emulation
aargh, zwymiotowałem na klawiaturę. To już szczyt, przeboleję autentykacje, autoryzacje, ale to już przegięcie!
BTW. To, że coś jest dostępne na jedną platformę, nie znaczy, że jest "własnościowe" (czytaj: http://en.wikipedia.org/wiki/Proprietary_software….
BTW. Inne systemy mają nieprznośne systemy dźwięku i im z tym dobrze.
Linux też ma nieprzenośne podsystemy i też mu z nimi dobrze.
@el.pescado: "Autentykacji" i tym podobnych ode mnie nie uslyszysz. Problem ze slowem "proprietary" to to, ze tlumaczenie – "wlasnosciowe" – niespecjalnie mi sie podoba. W razie watpliwosci wole uzyc wlasciwego slowa w obcym jezyka niz ryzykowac niespecjalnie przekonujacym odpowiednikiem.
-
Owszem, samo w sobie moze nie znaczyc. Jednak ALSA spelnia warunki – licencja uniemozliwia wlaczenie do innych systemow itd.
Od kiedy GPL-2/LGPL-2.1 jest licencją własnościową?
I od kiedy uniemożliwia włączenie do innych systemów?
(No chyba że wracamy do starej dyskusji BSD vs. GPL i Open vs. Free).
Przed dalszą dyskusją radzę zapoznać się ze stroną OSI
@uzytkownik: GPL "licencja wlasnosciowa" nie jest, ale ALSA jest rozwiazaniem proprietarnym – z niczym nie kompatybilnym, z nikim nie przedyskutowanym, w dodatku nieudokumentowanym.
-
GPL uniemozliwia wlaczanie do systemow na licencji innej niz GPL, czyli de facto do czegokolwiek poza Linuksem, bo innych sensownych systemow na GPL nie ma.
-
Przed dalsza dyskusja radze zapoznac sie z GPL FAQ.
Będzie piętnaście API do dźwięku i ani jednej porządnej gry która by je wykorzystywała
na gry przyjdzie kiedys czas, wpierw linux musi stworzyc podstawy do tego zeby to czego w tej chwili nie ma na tej platformie, kiedys moglo chodzic bez problemow.
Tak jest! I kiedy wreszcie Linux osiągnie ultymatywny poziom zaawansowania, tzn będzie do wyboru 15 rozmaitych API i bibliotek do obsługi każdej pierdółki, to producenci oprogramowania rzucą się do sprawdzania, która kombinacja tych bibliotek gryzie się najmniej i która z 15 bibliotek akurat zawiera tak przynajmniej z 90% wymaganej funkcjonalności.
bo jedynym rozsądnym API dzwieku do gier jest OpenAL
a co zlego w poczciwej Alsie
- jest tylko pod linuksem
- korzysta z jednego rzeczywistego kanałau (nie które drivery wiecej)
- brak dokumentacji dla deweloperów
- większe opóźnienia niż w przypadku OSS4 (OSS mixuje na poziomie jądra, a ALSA aplikacji/modułu)
- brak vmix
- limitu “idiosyncrasies” (OSS4 go nie ma)
- nie zawsze działa fullduplex
- dla wielu aplikacji koniecznosc stosowania pluginu OSS-ALSA, bo programistom nie chce się pisać kodu tylko dla linuksa jak moga na wszystkie posixy..
master, naucz się, że słowo "korzysta" nie piszemy przez "ż"
http://so.pwn.pl/lista.php?co=korzysta%E6
oraz pisowni partykuły 'nie' z różnymi częściami mowy
A na liscie majlingowej ALSY takie coś;
If the developers of ALSA made a nuclear reactor, it would have five
different control panels for controlling the rods in the reactor core, and
each would do something different and not what the documentation said.
Actually, I lied about that. It wouldn't have any usable documentation.
But, there would be a hidden feature that you could sound the overload
alarm by pulling out the stapler in the control office. Useful feature,
that.
Enter your search termsSubmit search formWeblkml.org
Date Sat, 7 Jul 2007 02:41:05 +0000 (GMT)
From William Pitcock
Subject Re: Is it time for remove (crap) ALSA from kernel tree ?
Digg This
On Wed, 4 Jul 2007 19:32:29 +0200, Adrian Bunk wrote:
> On Wed, Jul 04, 2007 at 02:35:39AM -0400, Darren wrote:
>>
>> I know this may sound kind of stupid, but how about not deprecating either,
>> and fully supporting both sound systems? Maybe we can get them to work
>> together, and the distro or user can choose whether they would like to use
>> alsa or oss for that particular card (or have the distro choose the sound
>> drivers that are best supported for that particular card). As it is now,
>> most apps already support oss and alsa.
>
> It does not sound stupid and sounds good at first sight.
>
> But there are problems we've already seen with similar situations in
> different parts of the kernel:
> They would have different hardware support, features and bugs.
>
> And then a user user whose sound card is only supported by sound system A
> needs a feature only available in sound system B.
>
> And the quality decreases since people will often not report bugs in
> sound system A if sound system B works for them.
>
> OTOH, for a user it shouldn't matter whether there's OSS or ALSA, that's
> mostly a difference for application developers. And since (as you say)
> most applications already support both, there's no compelling reason for
> providing more than one of them.
>
> cu
> Adrian
>
If the developers of ALSA made a nuclear reactor, it would have five
different control panels for controlling the rods in the reactor core, and
each would do something different and not what the documentation said.
Actually, I lied about that. It wouldn't have any usable documentation.
But, there would be a hidden feature that you could sound the overload
alarm by pulling out the stapler in the control office. Useful feature,
that.
As an audio developer on Linux, I must say that developing with ALSA is
absolute fucking hell. If there was a way where both APIs could natively
be supported, more people would be happy with the current state of affairs
in the kernel.
The most fucked up thing that I can think of about the current state of
affairs in ALSA is dmix. Every other UNIX sound system like ALSA does it's
software mixing in kernel space. The applications never even know about
it. It's not only until recently (2005-2006 or so) that ALSA came close to
this, but there are still problems. Many cards need workarounds to make
dmix work because of the way it works, and the way that ALSA buffers data
around.
For the non-technically inclined, ALSA only keeps two fragments for
input/output data each. This is horribly unusable because most soundcard
fragments are only 1KB, so applications have to adopt ringbuffers to pass
data to ALSA. If you're doing video, this leads to possible timing issues
unless you sit down and well design your abstraction layer for audio I/O.
So people switch to things like JACK and PulseAudio because it's the only
way they can get workable Audio I/O on ALSA.
What's even worse for the ALSA API is that it's designed around lowlatency
programming, but only a few drivers properly support it. Why do you need
lowlatency access to play a beep or a ding or whatever? The simple answer
is you don't.
ALSA could and can be done correctly, but OSS4 is already here and
provides an API which solves all of ALSA's current problems. So why waste
time with that, when OSS4 is already here and more friendly to the
developers of the software most Linux users use?
If OSS4 and ALSA apis could run on the same base driver, then a lot more
people will be happier, as there will be choice available in which API to
use, e.g. OSS4 or the libasound self-abuse method.
Hannu has ideas on how that could work. I suggest all of the kernel
developers listen, and listen well, or this mess will never be fixed in a
way that is truly usable.
good points – obawiam się jednak, że i tym razem 'duma' i 'honor' developerów nie pozwoli im dogadać się ze sobą dla dobra wszystkich
w myśl zasady:
"- why do another sound API?"
- because I can"
Czyż nie jest to właśnie motor rozwoju Open Source?
I czy nie jest to właśnie główna przyczyna, że Linux nie może wyjść poza zaklęty krąg komputerowych hobbystów?
@mk: Nie, zwazywszy ze tego typu zachowania nie sa w Open Source uniwersalne. Sa projekty podchodzace do tego troche bardziej dojrzale.
Owszem, te, za których rozwojem stoi jakaś firma komercyjna.
No akurat za ALSA od samego (chyba?) początku stała SuSE. Chłoptaki mają płacone za dłubanie tych sterowników – to nie ma się co dziwić, że się tym zajmują. Niby czemu nie? Robią to, co lubią – i jeszcze zarobek mają.
@mk: Niekoniecznie. Za FreeBSD czy OpenSSH nie stoi zadne komercyjne wsparcie. Z drugiej strony przyklad powyzej pokazuje, ze w druga strone tez to nie dziala.
@master widzę, że promujesz OSS tak jakby był lekarstwem na całe zło z dźwiękiem w Linuksie. Moim zdaniem i bardzo wielu ludzi tak nie jest, dlatego nadal upieram(ją) się przy rozwoju ALSA. Problemem są pieniądze i tym samym brak programistów profesjonalnie zajmujących się tą trudną dziedziną. Nie każdy ma dobry słuch i wyczucie by mógł zajmować się tym. Chcesz pomóc daj dotację, nie wszystko jest za darmo. OSS ma dużą przewagę, która ostatnio traci na skutek otwarcia swoich źródeł i dokumentacji. Mam nadzieję, że 4Front Technologies zbankrutuje i w tedy zobaczymy czy to taka rewelacja. Obawiam się tego, że rozwój się znów spowolni a co najważniejsze programiści opłacani obecnie przez 4Front Technologies mniej będą przykładać się do optymalizacji pod ten system dźwięku. ALSA technicznie jest lepsza.
ALSA nie ma zadnych architekturalnych przewag nad OSS. Jedynym powodem, dla ktorego w ogole weszla do kernela bylo to, ze ktos postanowil wynalezc kolo na nowo zamiast poprawic OSS-a, popsutego ktoras z kolei zmiana w reszcie kernela.
Po prostu wydaje mi się bardziej sensowne dokończeni prac nad projektem który ma 15lat i u standaryzowanie go niż zaczynanie kolejnych, bo wcześniejszy przez pewien czas się wolniej rozwijał.. Nakład pracy, by ALSA działała jak należy, miała proste API i obsługiwała inne systemy jak *BSD, SOLARIS, HAIKU etc. jest zdecydowanie większy.. niż podjęcie decyzji Linusa by znowu domyślnie OSS obsługiwało dźwięk w Linuksie.. XMMS-FANBOY
mi sie to jakos inaczej przypomina – tj. alsa weszla do jaja, bo obslugiwala wiecej sprzetu i wydawalo sie ze do niej prosciej sie pisze sterowniki (ze niby zrodla bardziej modularne)
na tą chwilę tak obsługiwała więcej, OSS miało wtedy przy stój i w tym momencie oby dwa projekty były porównywalne.. rozwój ALSY był pewny, OSS nie, więc go usunęli, niemniej kierunek i nie profesjonalizm, deweloperów sprawił, ze kod ALSY to istna sodoma, prawdziwy cud, że to działa.. wątpię by ktoś się zdecydował przejąć prowadzenie tego projektu, jak jest tak bardzo zapętlony, natomiast OSS w dalszym ciągu jest KISS, jasno zwięźle, kod dobrze opisany ja laik wiem co gdzie w kodzie mojego sterownika.. ALSA to nuclear reactor, który zawiódł chyba wszystkich.