[alsa-devel] Intel HDA / ca0132: Multichannel + S/PDIF support

[Takashi Iwai]

At Sun, 04 Jan 2015 22:26:44 +0100,
Stefan Oltmanns wrote:
> 
> Am 04.01.2015 um 21:33 schrieb Dylan Reid:
> > On Sat, Jan 3, 2015 at 2:43 AM, Stefan Oltmanns <stefan-oltmanns at gmx.net> wrote:
> >> Am 03.01.2015 um 02:30 schrieb Dylan Reid:
> >>> On Tue, Dec 30, 2014 at 8:05 AM, Stefan Oltmanns
> >>> <stefan-oltmanns at gmx.net> wrote:
> >>>> Hi,
> >>>>
> >>>> I own a Gigabyte G1.Sniper M3 Z77 mainboard with ca0132 onboard audio.
> >>>> Currently only stereo out and headphone out (at the back, always same
> >>>> signal) work by default.
> >>>> I was able to fix S/PDIF out by changing the headphone pin in function
> >>>> ca0132_config to something below 0x0d, like:
> >>>>
> >>>> spec->out_pins[1] = 0x0a;
> >>>>
> >>>> No idea why this fixes S/PDIF, but no other effects noticed. No idea if
> >>>> it´s going to break something on other devices. Original value is 0x10.
> >>>>
> >>>> In this function also 3 DACs are listed. The board has a total of 5
> >>>> stereo outputs:
> >>>>
> >>>> -Frontpanel (HDA pin connector on mainboard)
> >>>> 4x 3,5mm output at backpanel:
> >>>> -Stereo out
> >>>> -Headphone out
> >>>> -Rear out
> >>>> -Center/LFE out
> >>>>
> >>>> I tried to increase the number of channels and create additional outputs
> >>>> and connected to the other DACs. The maximum I´m able to is to get
> >>>> different signals out of stereo out and front headphone (not useful,
> >>>> just some weird mixes) or same signal from all 3 outputs. Rear and c/lfe
> >>>> out always no signal.
> >>>>
> >>>> During initialization snd_hda_parse_pin_def_config is called and two
> >>>> outputs are found. I tried to override that and change spec->autocfg
> >>>> after that function is called, no success.
> >>>> Also no matter what I change there, a little later I get this kernel
> >>>> messages:
> >>>>
> >>>> kernel: [    2.642972] input: HDA Intel PCH Line Out as
> >>>> /devices/pci0000:00/0000:00:1b.0/sound/card0/input8
> >>>> kernel: [    2.643142] input: HDA Intel PCH Front Headphone as
> >>>> /devices/pci0000:00/0000:00:1b.0/sound/card0/input7
> >>>> kernel: [    2.644932] input: HDA Intel PCH Line as
> >>>> /devices/pci0000:00/0000:00:1b.0/sound/card0/input6
> >>>> kernel: [    2.645050] input: HDA Intel PCH Mic as
> >>>> /devices/pci0000:00/0000:00:1b.0/sound/card0/input5
> >>>>
> >>>> I could not find the code where this messages are generated, where is that?
> >>>>
> >>>> Any ideas what I could/should try to get multichannel support working?
> >>>> Is there any kind of documentation on the ca0132 that could be helpful?
> >>>
> >>> A lot of these capabilities need to be exposed by the DSP on the
> >>> ca0132.  What firmware are you loading on it?
> >>
> >> I tried the one included and none, makes no difference for that problem.
> >> Also the firmware gets loaded after all the input/output configuration,
> >> you´re sure the firmware is needed for multichannel support? Is it
> >> possible/legal to extract it from the windows driver somehow?
> >>
> > 
> > I'm not sure you need the DSP to do this.  You could try the widows
> > firmware, but I don't think the driver will know how to communicate
> > with it.
> > Sorry I don't have anything more encouraging.
> > 
> 
> The firmware seems to be directly included in the driver (file is called
> ctHda.sys), as I can find the byte sequence MXFL many times in it (this
> is how the ctefx.bin file starts). Unfortunately it does not even to be
> in one part (there are strings in between). Is there any information
> available of the file format of the firmware, like header structure, so
> I can find out length of it?
> 
> Still the question remains, the input/outputs seem to be generated
> before the firmware is loaded, how is that done? How does the driver
> know that there are this 4 I/Os and that they are named like that?
> That´s not from the patch_ca1032.c. I cannot find any code for that.

It's parsed from the pin-default config values set by the hardware.
In the case of onboard audio, usually this is set by BIOS.
Stand-alone boards should set it by themselves, too.

The SPDIF I/O itself has worked even without the DSP (but some volume
controls didn't), IIRC, at least on a Recon3D board I've tested in the
past.

Reassigning the pin is the right fix for your board.  The correct way
would be to add a fixup entry depending on the PCI or codec SSID.


thanks,

Takashi