[alsa-devel] Trying to get unsupported CODEC to work

[Alex Austin]

On Thu, Nov 5, 2009 at 4:21 AM, Takashi Iwai <tiwai at suse.de> wrote:

> At Thu, 5 Nov 2009 03:15:52 -0600,
> Alex Austin wrote:
> >
> > I know this thread is ancient, but the question has come to my forefront
> > again, so I'll see if I can ask it better now.
> >
> > On Fri, Dec 12, 2008 at 3:23 AM, Takashi Iwai <tiwai at suse.de> wrote:
> >
> > > Alex Austin wrote:
> > > >
> > > > Shoot. The DAE-3 is a controller for a 5-CH Amplifier card driving
> > > > speakers directly, but I still need the subwoofer output from the
> ALC888.
> > > I
> > > > may be able to get by without the ALC using high-level inputs on the
> sub
> > > amp.
> > > > Even without it, what do I need to do to enable the DAE-3? I'm
> > > comfortable in
> > > > C, but I don't know ALSA much, if at all, yet.
> > >
> > > The codec parser isn't present for DAE-3, and the generic parser
> > > obviously doesn't work for it.  So, you need to create a new codec
> > > parser such as other patch_*.c.
> > >
> > > Takashi
> > >
> > >
> > Since the output of codecgraph looks pretty simple, what codec
> > parser would you recommend starting with as a base?
>
> Hard to say...  Maybe the one in patch_cirrus.c or patch_ca0110.c,
> which are relatively straightforward parsers.  patch_sigmatel.c
> includes many fix-ups.  Ditto for realtek.
>
> Thanks. I'll start there. Since I'll be trying to work from codecgraph
output,
can someone supply me a codecgraph for either a cirrus or ca0110 codec
to compare against the parser source?

>
> > On Fri, Dec 12, 2008 at 1:02 AM, Takashi Iwai <tiwai at suse.de> wrote:
> >
> > > At Thu, 11 Dec 2008 16:28:28 -0600,
> > > Alex Austin wrote:
> > > >
> > > > Hello,
> > > > I have an MSI Media Live DIVA motherboard. It has an AMD SB600 HD
> > > > Audio controller, and two CODECs on the HDA bus.
> > > >
> > > > First is an ALC888
> > > > Second is an Intersil DAE-3.
> > >
> > > The analog outputs on both codecs are really used at the same time?
> > > Then it doesn't work right now.  Simply "not implemented".  And no
> > > concrete plan to fix it yet.  This might require a fundamental
> > > re-design.
> > >
> > >
> > > Takashi
> > >
> >
> > Is this still the case? Structurally, why can't this be supported now?
>
> The problem is that the driver device tree is based on the PCI
> device.  That is, each card-object is created for each PCI device,
> not for each codec.
>
> The re-design I mentioned above is to create a HD-audio bus per PCI
> device and a card instance for each codec chip on that bus.  But, this
> results in the incompatibility with the current setup, and so far, no
> real hardware requires that.
>
> Alternatively, you can add quirks for both codecs to create controls
> freely with different names or with unique indices so that they don't
> conflict with each other.
>
>
> Takashi
>
So, the only reason it won't work now is because of duplicate control names?

On a related note, can audio be routed from an analog input on one codec
to an analog output on another within the controller, or would that need to
be done via a userspace app?