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

[Takashi Iwai]

At Sat, 19 Jan 2008 17:19:25 -0200,
Claudio Matsuoka wrote:
> 
> On Jan 16, 2008 12:54 PM, Takashi Iwai <tiwai at suse.de> wrote:
> 
> > I put the versoin 0.0.10b now.  It includes the patches to the latest
> > ALSA tree but no other changes.
> >         ftp://ftp.suse.com/pub/people/tiwai/hda-tools/hda-tools-0.0.10b.tar.bz2
> >
> > (it might take some time to be exported to the outside.)
> 
> I see that, while in userspace, this is very similar in overall
> structure to the current kernelspace driver (the file layout being
> much more organized, however). Have you considered the option to have
> codec_config_preset for each model specified in a description file
> that is parsed and sent to the actual driver at runtime, instead of
> hard-wired inside the library? The parser itself doesn't seem hard to
> implement, especially if we use the C preprocessor to handle includes
> and macros. Handling of unsol events would be less flexible, but I
> don't know if there are many uses for it except muting/unmuting other
> channels when using external microphones and headphones (and these
> cases could be well covered by specifying what to mute/unmute in the
> description file).
> 
> The description file could also be very similar to the format
> currently used in the C source, just making it easier to parse and
> having one model per file (with common definitions included via
> preprocessor). I'm not sure how well this would fit for Sigmatel
> codecs, but seems to be apropriate for Realtek.

The current implementation is in such a form intentionally to make a
transition smoothly.  In this way, you can port the existing kernel
code quite easily to the new framework without losing functionality.
The worst thing is that the machine doesn't work any longer by this
transition.  That's why I don't want to move to a generic parser or a
dynamic parsing at the very first step.

Once after we get a certain working version, we can move to the
further steps.  The primary goal is to create a more generic and
powerful parser that supports all codecs without extra codec-specific
hacks.  It'd be likely necessary to provide some extra hints/info, but
it should be as small as possible.  For this, we need to develop a
good algorithm to parse the widget topology and build PCM streams and
mixer elements appropriately.  This will be a fun and interesting.

Another thing in my mind is to develop a codec simulator.  This reads
the codec proc file and responses to the codec commands like the given
codec.  It can log the command request/response sequences, so that you
can catch regressions by the changes of codes.  This would be
especially helpful the transition from the codec-specific code to the
generic parser.  So, a collection of proc files will be very
benifitable in future, too.


Takashi