Paul Davis wrote:
>>-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?
>
>
>
I think I discussed this on the ALSA lists many years ago,
most of the times, the answer was simple:
-No answer, message ignored
-Do it yourself, It's opensource, we have no time to work on it.
I'm not blaming anyone for this, but just noting that it's not that
simple to "help" if you dont have the time or knowledge to write code.
>>-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?
>
>
>
I dont know how the driver is supposed to know. But let me be more
detailed on the issue, because you are probably misunderstanding.
Many soundcard drivers have a module option about where to ALLOCATE
the mpu/joy/opl3/etc IO-port, not where it is in the hardware (ala old
nonpnp ISA devices).
If you dont supply a port, just any port (all will work as long as no
one else is using it)
then the desired feature wont work. I understand that hardware-wise this
has been
designed like this for compatibility with MS-DOS/Win9x, so old apps can
access to
a standard (read, old soundblaster) port. But I find it strange that
ALSA asks YOU where
to alocate that IO/Port instead of figuring out a free port itself via
the kernel API. Why cant
the kernel/driver simply find a free port for it and enable the feature
by default??
This is ABSOLUTELY user unfriendly. Maybe I do know about it, but why
does the common
user who just wants to make music or play a game using a joystick needs
to know about
this supplied MS-DOS hardare compatibility options?! or even, what an
IOPort is?
>>-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.
>
>
>
Tell that to debian and generic distro mantainers.
>>-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?
>
>
>
>
What design discussions? I gave up posting to ALSA-dev list because no one
seems to care about design discussions.
Juan
Received on Mon Jun 20 20:15:21 2005
This archive was generated by hypermail 2.1.8 : Mon Jun 20 2005 - 20:15:22 EEST