[alsa-devel] Splitting up the HDA-INTEL modules

Andrew Paprocki andrew at ishiboo.com
Tue Jan 15 21:06:45 CET 2008

I am for this idea as well. The whole idea of the hard-coded 'model'
definitions is kind of counter-intuitive considering the chipsets
allow for dynamic reconfiguration. The kernel driver right now is
lacking support to really take advantage of this flexibility.

If this was done, the burden for adding new models could then be
shared among non-kernel developers because most people should be
capable of playing around with a configuration file/tool until a
working configuration is found and then sharing their results. When
this requires modifying the driver code, it unfortunately makes all
the work for adding new models fall on kernel developers who might be
busy with other things.

Also, it should allow for reconfiguration of the ports without
re-inserting the kernel module. This would help out in configurations
where dynamic modules are not used and a reboot would otherwise be

Could this all be done through a /proc interface? For example, a
/proc/asound/hda directory which contained files representing the
different connections in the chipset?


On Jan 15, 2008 2:20 PM, Claudio Matsuoka <cmatsuoka at gmail.com> wrote:
> On Jan 15, 2008 4:36 PM, Marco Schuster <marco at harddisk.is-a-geek.org> wrote:
> > when I looked today through the files of the snd-hda-intel module, I
> > was a bit shocked by this complex amount of code (patch_realtek.c for
> > example). I would think about splitting up the code in a way each
> > chipset gets its own .c file - which will make debugging, patching or
> > editing a lot easier IMO, and for second people can then comment on
> > just their specific chipset in config.
> >
> > What do you think about this?
> One interesting development for hda drivers would be to keep the basic
> infrastructure for each codec in the driver, and configure them from
> userspace. That would remove all quirks and special cases from the
> kernel, and allow easier update for users without the need of
> deploying a new kernel (or new ALSA), just updating the userspace
> tool.

More information about the Alsa-devel mailing list