[alsa-devel] hda-verb, hda-analyzer, hda-emu and codecgraph

[Takashi Iwai]

At Tue, 27 Jul 2010 16:57:44 +0200 (CEST),
Jaroslav Kysela wrote:
> 
> On Tue, 27 Jul 2010, Takashi Iwai wrote:
> 
> > At Tue, 27 Jul 2010 16:07:31 +0200 (CEST),
> > Jaroslav Kysela wrote:
> >>
> >> On Tue, 27 Jul 2010, Takashi Iwai wrote:
> >>
> >>> At Tue, 27 Jul 2010 13:31:16 +0200,
> >>> David Henningsson wrote:
> >>>>
> >>>> Hi Takashi,
> >>>>
> >>>> Do you plan to make hda-verb, hda-analyzer, hda-emu and/or codecgraph a
> >>>> part of alsa-tools/alsa-utils/pyalsa in the future?
> >>>>
> >>>> I'm asking because I would like to know if it makes sense to package
> >>>> them separately for Debian.
> >>>
> >>> I can put hda-emu to alsa-tools if anyone wants.
> >>> This is a really small code.  (But I didn't put it because I didn't
> >>> want to 100 times bigger auto-tools stuff for it :)
> >>>
> >>> But, hda-emu doesn't suit with alsa-tools category.  It's a tool to
> >>> be built with the latest (or the version to be tested) sound kernel
> >>> tree.  So, it's not much worth to package.
> >>>
> >>> hda-analyzer is already in alsa.git.  I guess it depends on Jaroslav.
> >>
> >> What about an idea to move all hda related stuff to new git repository
> >> like alsa-hda-tools ? It will make packaging more easy with uniform
> >> name and developers will find all recent stuff at one place.
> >
> > Well, hda-emu shouldn't be packaged together, so I'd like to keep it
> 
> I would just put the hda-emu to repo for reference and access. The 
> packaging is different thing.

Well, people would package it anyway, and I don't want it :)
(The original question came up because David wanted packaging, see?)


> > separately.  So, what else?  hda-verb and hda-analyzer?  hda-verb
> > hasn't been updated since long time ago :)
> 
> A little off topic: hda-compiler . I'm playing with an idea to have the 
> hda-intel driver behaviour description (patches) in a firmware file. This 
> file would contain an indexing against the hw identification and will 
> contain instruction like:
> 
> 32-bit 	(size and instruction)
>  	16-bit - instruction code
>  	16-bit - instruction size in 32-bit words
> 
> Possible instructions examples:
> 
> 0x00010001 0x00000010	- attach beep device for NID 0x10
> 0x00020003 <nid> <verb> <param> - hda_verb initialization
> 
> Instruction blocks:
> - hw initialization and controls, PCMs + etc. allocation (patch callback)
> - function blocks - control info/get/put callbacks, unsolicited events
> 
> Variables, arrays:
> - instructions to set/fetch information
> - instructions to allocate and manage arrays
> 
> It's just a rough idea - many things must be designed and thinked out. But 
> we need a compiler from an easy readable text syntax to generate these 
> "firmware" files - hda-compiler.

I've implemented a similar thing years ago.  It worked somehow, but
the rate of development of new hardware codec chips was much higher
than adapting the code.  In the end, it was far easier to write the
code in the kernel, so it got sent to a graveyard.

A tricky part is the implementation of strange mixer elements like
bind_mixer and the handling of unsolicited events.  The former can be
avoided (e.g. by using vmaster).  The latter requires a closure (or
whatever you call), and this wasn't always trivial.

Such a thing is lovely, and stimulating for hacking.  But, at the same
time, it's a bit hard to maintain because we'll face bugs now in
multiple layers (interpreter/parser in kernel, compiler, and the
firmware code itself).

Anyway, if this can be implemented in a moderate amount of code in the
kernel side and if we have decent user-space tools, it'd be nice to
have, indeed.


thanks,

Takashi