Tester für snd_hda Rewrite gesucht!

Yamagi

Possessed With Psi Powers
Staff member
Alexander Motin hat sich seinen snd_hda Audiotreiber noch einmal vorgenommen und einem sehr grundlegenden Umbau unterzogen. Die Änderungen sind im Einzelnen:

- Der Code wurde in mehrere einzelne Treiber aufgespalten. Für den Nutzer ergibt sich dadurch keine Änderung, der Treiber wird aber einfacher warten und weiterzuentwickeln.

- Multichannel Aufnahme ist nun möglich.

- Möglichkeiten zum Hardwaremixing (mehrere Hardwarekanäle zeigen auf einen Ein- oder Ausgang) werden nun besser genutzt.

- HDA-Codecs können in mehr als 4 logische Soundkarten gespalten werden.

- Ein- und Ausgangskonfigurationen können nun ohne Reboot oder Neuladen des Moduls genutzt werden. Mit einigen weiteren Verbesserungen in der Benennung der Ausgang soll die Konfiguration deutlich vereinfacht werden.

Da dies jede Menge Änderungen sind und snd_hda zudem dank der großen Nutzerbasis ein sehr kritischer Treiber, muss er getestet werden. Alexander bittet daher um Rückmeldungen und Erfahrungen. Weiteres steht unten in der E-Mail.

Code:
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

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!

-- 
Alexander Motin
 
Guck ich mir auch mal an, wobei ich sagen muss, dass ich auf noch keinem Betriebsystem so problemlos Sound nutze, wie unter FreeBSD. Unter Windows brauchte man immer Treiber, und naja ich glaube, was ALSA, Pulse und Konsorten angeht, da fang ich lieber erst garnicht an :ugly:
 
Ich hatte ein reject in sys/dev/sound/pci/hda/hdac.c, war ein recht großer Brocken.
 
Dafür hat Alexander ein Update erstellt:
Code:
> The patch doesn't apply cleanly to r230008; hdac.c.rej is 15661 bytes
> in size (mostly the section which deletes all the manufacturer-specific
> defines at the top of the file).

That is probably because of $FreeBSD$ macro resolution. Here is version 
with present value from 10-CURRENT SVN (sources from CVS or STABLE will 
need that patch line modified respectively) and some minor additional 
improvements like CODEC ODs and some more sysctls:
http://people.freebsd.org/~mav/hda.rewrite2.patch
 
Hi,

wie liefen die Tests? Mich interessiert vorallem die Konfiguration ( Übersichtlicher, Änderungen ohne Reboot übernehmen? ) ... hab mich noch nicht ran getraut ...

Danke und Grüße,
Kai
 
Back
Top