> -Dmix. It's not fair, why not the windows/beos approach which uses > primary/secondary buffers? so you can
you know what? there is plenty about the design to complain about, but when i complain about it, i willingly admit my own complicity in the mistakes that were made. ALSA has been under development for nearly 10 years. if you or others saw the "right way to do things" so clearly, why on earth didn't you speak up about it? > -Module configuration parameters. WHY ON EARTH do I have to specify the > IO port for mpu401, joystick, etc as driver options when loading the > modules for my soundcard, else doesnt work? What year are we on?! I cant > believe that this resource allocation is not handled by ALSA or the > linux kernel! how is the driver supposed to know? in general, the default values of these parameters works fine, but on linux, we reuse generic drivers all the time, and guess what? different audio/MIDI interfaces move the register/portIO addresses of common devices around. do you have a better solution? > -OSS/ALSA Conflicting modules in hotplug. Hotplug seems to make a mess > in many systems i've seen, of loading ALSA and OSS modules at the same > time, by rendering the system audio unusable. compiling a kernel to have both OSS and ALSA modules around makes a mess of many systems i've seen. > -Mixer is very complicated, with lot of useless options for the card, > many times buggy with inverted ins/outs (CMIPCI). Why not simply make > the alsa mixer system work with categories? I Mean.. you > can have the basic categories INPUT/OUTPUT, but also to host special > categories like 3D control, individual > channels of sblive, and other stuff which may be soundcard specific? > This way mixers could be sane again. and have you volunteered to help? have you put any time in to the numerous design discussions about the ALSA mixer API? why do you think it looks the way it does?
