de kernel API moet de basis van een systeem zijn. Als de kernel API al zo onbruikbaar is dat men er een userspace library voor moet maken (mijn mening hierover: zie onder), dan is er iets fundamenteel mis.
Unix, en linux in het bijzonder, betekent dat je niet gaat proberen om 100 layers over elkaar heen te leggen, tenzij de layer iets toevoegt. Een layer als in:
code:
1
| int open_sound_device(int mode); |
In plaats van
code:
1
| int open(char *device, int mode); |
heeft dus totaal geen toegevoegde waarde. ALSA doet niks meer of minder dan dit - er is dus een enorme overhead en een nutteloze library die niemand wil en die bovendien een dependency wordt. Vooral als je het hebt over de non-backwards-compatible releases van ALSA, dan is dit een enorme doodsteek. Immers, ik
heb een dependency en ik moet dus elke applicatie hercompilen
en de user moet die lirary op zijn systeem hebben staan. Dat is belachelijk.
Denk je in, als ik nu een ALSA-compatible applicatie wil schrijven, dan moet de gebruiker daarvan, of hij nu ALSA wil gebruiken of niet, die ALSA lib hebben, omdat dat een run-dependency is. Anders start de applicatie niet op. Dat is toch van den gekke? Terwijl dat met het file descriptor systeem zo mooi was afgedekt in kernelspace en userspace en
geen dependencies.
[quote]dat is dan toch makkelijker te gebruiken/te beheren en minder moeite om te programmeren? of heb ik het mis?
Nee!
Zie boven, open_sound_device(int mode) in plaats van open(char *device, int mode) voegt niks toe, behalve overhead. Daarnaast heb je in libalsa nog een extra gevaar, en dat is de ingebouwde sound daemon en de mogelijkheid om on-the-fly in software sound naar andere frequencies over te zetten. Dus een driver die maar 1x kan worden geopend kan toch meerdere geluidjes afspelen.
Maar dat is de taak van de USERSPACE sound daemon, niet een halfbakken ding wat in libalsa
zit. Compleet belahcelijk dus, en wederom verneuken van de unix principes 'make it do one thing and make it do that well' of 'KISS'.
Dan de software resampling (andere frequentie). Nu krijg je dus dat mensen die een halfbakken kaart hebben die alleen in 48kHz kan recorden, en ze willen in 44.1kHz opnemen. Onder OSS kan dat niet. En dus record je in 48kHz en is alles goed. Onder ALSA kan dat, en dus krijg je een enorme toegevoegde CPU load vanwege de software resamping en bovendien een halfbakken functie in libalsa die er helemaal niet in hoort (dat zit in sox - KISS). En omdat het al die functionalieit levert, krijg je alleen maar slechte applicaties die gebruik maken van al die toeters en bellen en die dus een systeem opleveren die niet meer vooruit is te branden omdat overal emulatie wordt toegepast.
Moet je je voorstellen dat je een RGB16-only display hebt en een 48kHz-only soundcard en dat je een concert zit te kijken van 44.1kHz op je RGB24-desktopje KDE3. Ben jij even stoer! En constant 100% CPU load en je systeem is niet vooruit te branden.
Dat wil je dus voorkomen, en dus moet je uberhaupt niet aan kernel emulation modes beginnen.
libalsa is dus een bloated library die op de meeste punten niks toevoegt en die op de punten waar het wel wat toevoegt, alleen maar functionaliteit van andere applicaties overneemt en dus een extra layer toevoegt en dat ook nog eens halfbakken doet. Kortom: ALSA zuigt.
wat wil je precies wat ze doen dan? is
dit niet gewoon genoeg?
Ik wil een complete API description zoals bij OSS, zonder de automatische verplichting om libalsa te gebruiken.
/me had veel liever een OSS2 gezien, een verbetering van OSS die ook nog eens deels backwards compatible was... 
.
.
???
.
:strip_exif()/u/52709/firelogo_s.gif?f=community)