Takashi Iwai, the Linux sound maintainer, is about to merge a patch set of about 150 patches into linux-next. These changes, in short, unify the different HDA codec drivers.
Introduction and background
First, the basics: HDA Intel is the current standard protocol for accessing your built-in soundcard, as well as HDMI/DisplayPort audio, and is used in almost all desktop and laptop computers since about 2005. In the HDA Intel world, there are controllers and codecs. The codecs also have a configuration, which tells which pins of the codecs that are connected to what input or output (this is set by BIOS/UEFI).
Hardware is very diverse: The HDA Intel driver supports at least 50 different controllers, and about 300 different codecs. On top of that, every codec usually support many different configurations.
The codecs come from 10-12 different vendors, and within the same vendor, it is more likely that the codec layout is somewhat like other codecs from the same vendor. As a result, the HDA codec driver is split up in 10-12 codec driver files, one per vendor. These files are to some degree copies of each other, but also contains every vendor’s specials.
What changes?
Takashi’s patches are solving a long term maintenance problem: as we want to add new features to the kernel drivers, we would previously have to do this once per codec – whereas with the unification of codec drivers, we would just have to add this code once. Or possibly twice, as the HDMI codecs will still have its own codec driver. In addition, new codec hardware is more likely to “just work”, or at least partially work, without explicit support in the kernel. The potential downside, of course, is that as you improve the driver to solve some edge case, you’re more likely to screw some other edge case up.
There’s not much of new features added in this new, generic driver at this point. However, if you have an “unusual” codec chip vendor, you might see minor improvements as these are brought up to feature parity with the more common codecs.
When does it change?
As usual, you can’t know until it’s in there. Takashi’s latest plan is to make the move for 3.9 for at least some of the codecs, and 3.10 for the rest of them.
Update: Some blog, referencing this one, said this feature would come to Ubuntu 13.04. Ubuntu 13.04 uses kernel 3.8, so this feature won’t be in Ubuntu until 13.10.
Update 2: As of 2013-01-23, the new code has been merged, for all codecs, for linux-next (kernel 3.9)!
Regressions and testing
Judging from the database you might have contributed to by yourself by submitting your alsa-info, there are about 6000 different machines out there, and there is not enough manpower to test them all. So we need a different approach. Conveniently, Takashi has written an emulator called hda-emu to test the codec driver code, and I’ve improved that emulator with some scripting, so that hda-emu effectively becomes an automated test suite. The test suite is still very incomplete, but it at least runs a few different tests such as faked playback, S3, and manipulating of volume controls, and checks if hda-emu crashes or reports an error. And sure enough, when running this test suite over all the alsa-infos in the database, a few regressions were discovered that I was able to fix.
So far, so good. If it weren’t for the fact that hardware often does not work exactly as advertised. The parser algorithm for reading the codec layout and creating a working kernel driver out of it, must now take all codecs from all vendors into account. The old vendor-specific parser might have done things in one way and the new parser might do things a different way, causing the audio to be routed differently.
As an example, assume the codec is broken in such a way that it advertises two audio paths, but in practice only one of the paths actually works. The new parser might then route the audio differently from the old one – and as a result it will look like audio should really work, in theory. In practice, there is nothing but silence. Another example could be that maybe the new driver will power down different parts of the codec in different order than the old driver did, causing your speakers to click.
How can I help?
Right now, what’s needed is more testing on real hardware. Takashi has called for testing of his hda-migrate branch of the sound-unstable tree.
If you’re running Ubuntu, I have made packages for 12.04, 12.10 and 13.04 – just download, install it (you might need to install dkms and kernel headers too). Then reboot and test. Simply uninstall the package and reboot when you’ve finished testing.
Update: I will probably close the comments soon due to the amount of spam coming in that way. Please report back – especially if you did see a regression – to the alsa-devel mailing list. Thanks!
Update 2: As the code is now merged into linux-next, please use these instructions to try it out on Ubuntu. Thanks!
This is awesome. Incredible changes are coming then to 3.9 and 3.10. Love the way everyone works together to achieve stuff like this.
What would be useful to test?
I can still play music, use the microphone, continues working after suspend as well. Anything else?
And is there any good place to report back? Simply: it seems to work on my device: 00:14.2 Audio device: Advanced Micro Devices [AMD] nee ATI SBx00 Azalia (Intel HDA) (rev 40)
or submit a new alsa info with it on: http://www.alsa-project.org/db/?f=698989e4b43403dec923d83c3ebdcdc384a311ac
So, in other words, is posting the above useful?
It is useful, thanks!
Things to test, well, everything that matters to you, e g:
– All inputs and outputs (internal mic, external mic, line in, line out, speakers, headphones, HDMI, SPDIF etc, all that you got)
– Suspend/resume, as you say
– Modify volume and/or gain and see that the resulting volume/gain changes accordingly
– Automute (speakers mute when headphones are plugged in) and autoswitch (switch to external mic when plugged in), at least check that it hasn’t stopped working compared to the old/current drivers.
– And just an extra eye to see if anything strange is happening that wasn’t happening before.
It saddens me a bit to see most of upstream development to be financed by other distributors like redhat or suse, while ubuntu is most of the time occupied developing their own stuff they invented (upstart) or maintaining parts which have been forked or are heavily modified compared to upstream (compiz, gtk, …)…
This is a side track, and I can only answer for myself and my experiences, rather than for Canonical’s policies in general.
When it comes to the stuff I get paid for developing, I try to make sure that it is accepted upstream. The automated test tool I mentioned in this post, that’s a part of hda-emu. hda-jack-retask? Part of the alsa-tools package. The new hardware that I help enabling? Patches are upstreamed to the Linux kernel as soon as I get them working and accepted. I’ve been working hard on the jack detection and sound settings projects to make sure they are upstreamable to PulseAudio and Gnome – in the end, all of the jack detection and most of the sound settings were upstreamed. I’m also one of the active maintainers of PulseAudio.
Another thing, that happens to me a quite often, is this:
* An Ubuntu user reports a bug
* An Ubuntu bug triager, in this case myself, works back and forth with the bug reporter to figure out what the problem is.
* I write a patch, often package it up for easy testing, and ask the Ubuntu user to test it.
* The Ubuntu user tests it and confirms that it fixes the bug. This might take a few iterations until the bug is resolved.
* Once all that is done, I go to upstream with the patch.
* Upstream recognises the problem, but wants to solve it slightly differently, so the patch is rewritten by the upstream maintainer, and committed.
The end result: The Ubuntu user and the Ubuntu bug triager have spend much more time on resolving the bug than upstream have, yet upstream gets the credit for fixing the bug.
(This is not criticism against my upstreams; as long as the bug is solved I’m happy – I’m just pointing out that it skews the statistics.)
So; I’m not saying that Canonical does as much upstream development as Redhat or SUSE do, we probably don’t. I’m just saying that to me, the world isn’t as black and white as it may look.
And finally, when it comes to Upstart, that’s the init system that has been used by Ubuntu, Fedora, OpenSUSE, and many others. As of today, many of the bigger distros – Ubuntu, RHEL, CentOS, ChromeOS (not sure if that counts as a distro?), etc – are currently using it. If that doesn’t count as “upstream development”, I don’t know what does.
Thanks for sharing your point-of-view and your objective arguments (actually I have to admit I never thought that comment would be approved).
Good to know people at Canonical do care about upstream development – I just would wish it would be still a bit more … and a little less work/reliance on in-house stuff…
Regarding upstart, RHEL and CentOS are based on Fedora, so its basically only a matter of time. Most major distros switched to systemd – which is quite a controversial system but seems to be more powerful overall.
Works for me.
Details: [00:1b.0 Audio device: Intel Corporation 6 Series/C200 Series Chipset Family High Definition Audio Controller (rev 05)
ALC269VB Analog (both internal speaker, headphones and microphone).
Not tested:
ALC269VB Digital (digital out)
HDMI (haven't device)]
Thank you! Installed your package for Ubuntu 12.04 and suddenly autodetection of jack-plugs works and it switches the speakers automatically off and on! I tried many times to get that working, didn’t really expect anything now.
Also the ugly crackling at shutdown is gone. Suspend/Resume works, probably did before. Mic jack works, even stereo-microfone, didn’t know that it’s supported, plugged in the Stereo-Mic ME-1, that I bought for my DSLR.
The report of my hardware: http://www.alsa-project.org/db/?f=e5fad7eee51878c757bd0595dfe1eb03fd2d486d
I will continue “Testing”, I feel no urge to remove the package again.
Pingback: Unity Changes – Ubuntu 13.04 Raring Ringtail | Tips Cara Cepat Hamil
Note that Ubuntu 13.04 will use Kernel 3.8. This change isn’t coming to Ubuntu until 13.10.
Maybe you can still add it to 13.04 as an optional package (either something dkms-based like the packages that you made here, or as one of the linux-backports-modules-* packages)?
That could be worth considering if there’s sufficient demand for it. However, once the code is merged into the right trees (it currently lives in Takashi’s sound-unstable tree only), there will be automatic daily builds for it in a PPA: https://wiki.ubuntu.com/Audio/UpgradingAlsa/DKMS
Everything looks good.
pci:
00:14.2 Audio device: Advanced Micro Devices [AMD] nee ATI SBx00 Azalia (Intel HDA) (rev 40)
02:00.1 Audio device: Advanced Micro Devices [AMD] nee ATI RV710/730 HDMI Audio [Radeon HD 4000 series]
usb:
Bus 004 Device 003: ID 0d8c:0102 C-Media Electronics, Inc. CM106 Like Sound Device
http://www.alsa-project.org/db/?f=3f2865024d69a5f52a5376319ee3e45bcb4b1d2b
This is a bit off topic but the internal mic on my netbook hasn’t worked with ubuntu for at least the last three releases.
I need to go into pavucontrol and go to input tab and then set all inputs to front left 100% and front right 153%, thats for microphone, internal microphone and analog input. If i mute any of those the internal microphone is also muted and i cant use it in a hangout.
Its kind of confusing which is why i haven’t filed a bug, also unsure as to where i should file it.
Have similar issue when trying to use external microphone. Have no idea which source signifies what at this point.
Don’t know whether internal microphone actually means the internal microphone or whether it means 3.5 microphone. Any help would be appreciated. Thanks.
oh almost forgot, using acer aspire one zg5
See if this is the Inverted internal mic problem. If not, try filing a bug using the “ubuntu-bug audio” terminal command and follow the instructions – although there is no guarantee that there will be enough time to look at all bugs filed that way.
Thanks david, seems to be the inverted mic issue. I added my alsa-info.txt to the bug report. Is there any chance that this bug will be resolved by the release of 13.04?
There is hope, but I don’t give guarantees at this point, have too much stuff to keep in my head already.
Everything that matters to me is working on this machine:
http://www.alsa-project.org/db/?f=8eacd1d2717d5776a62039e57e7a0db18360dba3
00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio Controller (rev 03)
What I tested was:
– external mic [OK]
- headphones [OK]
- speakers [OK]
- dunno what’s line in, line out
– sound after resume (from suspend) [OK]
- sound after resume (from hibernate) [OK]
- volume modification [OK]
- automute [OK]
These tests pass with the Intel drivers who come with Ubuntu 12.04.1 so everything is working as ‘usual’, no changes for me =)
The 12.04 package failed to install for me (in Precise):
I’m guessing this is because I’m running linux-signed-generic-lts-quantal which is 3.5.0.22.29 currently; the 12.10 package seemed to install fine. Will testing data from this kind of hybrid setup still be useful?
If you’re running the lts-quantal kernel in 12.04, you should be able to use the 12.10 package. I believe it works.
It does not work on my Lenovo Thinkpad x220 with Ubuntu 12.10. I installed the linked package and after a reboot the sound device was replaced by a dummy device in the sound settings, sound did not work anymore. The gnome-shell process was consuming all the CPU power (>200% in top) and everything was super slow.
Maybe something else went wrong to cause this behavior, I am happy to test again and provide log files, etc.
I removed the package and after rebooting again everything worked as before.
I tried it again and now it works. Speaker, headphone and built-in microphone array work as before. Jack detection is not functional, also as before.
Hi Jörn,
Thanks for testing – could you please provide your alsa-info too? https://wiki.ubuntu.com/Audio/AlsaInfo