[alsa-devel] Future of the HDA driver

[Takashi Iwai]

At Mon, 03 Oct 2011 15:14:47 +0200,
David Henningsson wrote:
> 
> On 10/03/2011 02:27 PM, Takashi Iwai wrote:
> > At Mon, 03 Oct 2011 14:01:00 +0200,
> > David Henningsson wrote:
> >>
> >> Hi Takashi etc,
> >>
> >> 1) I think it would make sense to have a designated time and room for a
> >> "future of HDA" discussion in Prague. We could e g discuss input jacks
> >> as kcontrols, and exposing routing to user space, as IIRC Mark Brown was
> >> suggestion earlier. What do you think?
> >
> > Sure, we can hold a meeting spontaneously, as this would be for
> > smaller group.  The sound BoF isn't exactly scheduled at all yet.
> > I don't know how many guys will be there, so I thought it can be
> > managed spontaneously by announcing on the message board there or so.
> 
> Sorting something out on-site will probably work as well, but I was just 
> thinking that a pre-scheduled meeting is less likely to be forgotten or 
> missed.

It's fine for me to have a fixed schedule, too.

> >> 2) With Ubuntu 11.10 in a "Freeze" state and PulseAudio 1.0 out the
> >> door, I might have some time to contribute to the HDA driver...at least
> >> if not a lot of urgent stuff comes up, and up to the 3.2 merge window or
> >> so. (Any idea how far away that would be?) Do you think it would make
> >> sense to split hda_codec.c into hda_codec.c and hda_autoparser.c, move
> >> snd_hda_parse_pin_defcfg there, then add more functions as discovered to
> >> be useful to more than one autoparser?
> >
> > The merge window for 3.2 is almost closed now, as 3.1 will come out
> > today or tomorrow, I suppose.  Such a big change as you suggested in
> > the above is a 3.3-material, I suppose.
> 
> Oh, I always seem to have bad timing :-(
> 
> But maybe I can make a 3.2 patch today or tomorrow to make naming of the 
> input jacks a little more consistent, right now it's a little different 
> between Realtek and Sigmatel/IDT parsers, e g.

Yes, such a small fix is welcome, of course.
I merged your patch now.


> > The unification of parsers is a longterm goal.  My plan is to reduce
> > the rest of Realtek-quirk codes as much as possible in 3.3, try to
> > clean up / implement the auto-parser for AD codecs, and slowly
> > starting to the unified parser by moving the pieces to the core
> > hd-audio code from codec-specific codes.
> 
> Hmm, maybe better to move things to a more generic auto-parser first, 
> then the AD auto-parser could be more easily implemented. But I trust 
> your judgement on the matter :-)

This can be started in parallel.  I thought of starting AD-codec
support because it has already the parser for AD1988, but not for
others.  But, it can be judged later dynamically, whether to proceed
the generic code more ahead or first finish the AD-codec parser.

> >> 3) One thing that has been annoyed me lately is the moving of hp out or
> >> speaker out to line out, which IMO leads to somewhat messy code. Seen in
> >> retrospect of course, don't you think it would make more sense to do let
> >> line_out_pins be "line out" only, and add one more variable primary_out
> >> that would be initialized as:
> >>
> >> primary_out_pins = line_outs ?&line_out_pins : (speaker_outs ?
> >> &speaker_out_pins : (hp_outs ?&hp_out_pins : NULL))
> >>
> >> ..and then you could do something like:
> >>
> >> #define hp_is_primary_out(_auto) ((_auto)->primary_out_pins ==
> >> &(_auto)->hp_out_pins)
> >>
> >> Redoing that will probably require careful reading to avoid regressions
> >> though...
> >
> > Yeah, the current code is still messy although you cleaned up a lot.
> > This needs revisited.
> 
> Heh, thanks for the credit, although my contributions are fairly small 
> compared to yours :-)

I expect more codes will come up from you in near future ;)


thanks,

Takashi