20 Jun
2005
20 Jun
'05
1:10 p.m.
Paul Davis wrote:
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.
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?
Tell that to debian and generic distro mantainers.
What design discussions? I gave up posting to ALSA-dev list because no one
seems to care about design discussions.
Juan
-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?