Re: [RFT] Major snd_hda rewrite

2012/1/11 Alexander Motin <mav_at_freebsd.org>

> Hi.
>
> I would like request for testing of my work on further HDA sound driver
> improvement.
>
> List of changes done this time:
>  - Huge old hdac driver was split into three independent pieces: HDA
> controller driver (hdac), HDA CODEC driver (hdacc) and HDA sudio function
> driver (hdaa). All drivers are completely independent and talk to each
> other only via NewBus interfaces. Using more NewBus bells and whistles
> allows to properly see HDA structure with standard system instruments, such
> as `devinfo -v`. Biggest driver file size now is 150K, instead of 240K
> before, and the code is much more clean.
>  - Support for multichannel recording was added. While I've never seen it
> configured by default, UAA specification tells that it is possible. Now, as
> specification defines, driver checks input associations for pins with
> sequence numbers 14 and 15, and if found (usually) -- works as before,
> mixing signals together. If it doesn't, it configures input association as
> multichannel. I've found some CODECs doing strange things when configured
> for multichannel recording, but I've also found successfully working
> examples.
>  - Signal tracer was improved to look for cases where several DACs/ADCs in
> CODEC can work with the same audio signal. If such case found, driver
> registers additional playback/record stream (channel) for the pcm device.
> Having more then one stream allows to avoid vchans use and so avoid extra
> conversion to pre-configured vchan rate and sample format. Not many CODECs
> allow this, especially on playback, but some do.
>  - New controller streams reservation mechanism was implemented. That
> allows to have more pcm devices then streams supported by the controller
> (usually 4 in each direction). Now it limits only number of
> _simultaneously_ transferred audio streams, that is rarely reachable and
> properly reported if happens.
>  - Codec pins and GPIO signals configuration was exported via set of
> writable sysctls. Another sysctl dev.hdaa.X.reconfig allows to trigger
> driver reconfiguration in run-time. The only requirement is that all pcm
> devices should be closed at the moment, as they will be destroyed and
> recreated. This should significantly simplify process of fixing CODEC
> configuration. It should be possible now even to write GUI to do it with
> few mouse clicks.
>  - Driver now decodes pins location and connector type names. In some
> cases it allows to hint user where on the system case connectors, related
> to the pcm device, are located. Number of channels supported by pcm device,
> reported now (if it is not 2), should also make search easier.
>  - Added fix for digital mic recording on some Asus laptops/netbooks.
>
> That is how it may look now in dmesg:
>
> hdac0: <Intel 5 Series/3400 Series HDA Controller> mem
> 0xf7ef4000-0xf7ef7fff irq 22 at device 27.0 on pci0
> hdacc0: <VIA VT1708S_0 HDA CODEC> at cad 0 on hdac0
> hdaa0: <VIA VT1708S_0 HDA CODEC Audio Function Group> at nid 1 on hdacc0
> hdacc1: <Intel Ibex Peak HDA CODEC> at cad 3 on hdac0
> hdaa1: <Intel Ibex Peak HDA CODEC Audio Function Group> at nid 1 on hdacc1
> pcm0: <VIA VT1708S_0 HDA CODEC PCM (Analog)> at nid 28,29 and 26,30,27 on
> hdaa0
> pcm1: <VIA VT1708S_0 HDA CODEC PCM (Digital)> at nid 32 on hdaa0
> pcm2: <Intel Ibex Peak HDA CODEC PCM (DisplayPort 8ch)> at nid 6 on hdaa1
>
> Patch can be found here:
> http://people.freebsd.org/~**mav/hda.rewrite.patch<http://people.freebsd.org/~mav/hda.rewrite.patch>
>
> Patch was generated for 10-CURRENT, but should apply to fresh 9-STABLE and
> 8-STABLE branches also.
>
> Special thanks to iXsystems, Inc. for supporting this work.
>
> Comments and tests results are welcome!
>
>
Hi,

first thank for your work ! i'll try the patch this week end.

DisplayPort 8ch : does it mean that we now support 8 channel PCM over
DisplayPort and HDMI ?
i need this feature for DTS-HDMA and TrueHD with XBMC.