Comment 13 for bug 637947

The kernel solution seems to need a machine driver: something akin to sound/soc/omap/sdp4430.c (either a new file, or adding runtime detection for the alternate hardware to that file (renaming appropriately, etc.). Documentation on this lives in Documentation/sound/alsa/soc/machine.txt

In addition to simply providing a base driver to activate the hardware, such a kernel solution should also strive to provide appropriate defaults and naming such that as udev discovers the devices, the information passed to pulseaudio is sufficient for accurate and correct autoconfiguration.

The userspace solution should be considered only as a fallback. The acceptable changes to pulse's daemon.conf will be commited with the solution to bug #623242 , and are essentially unrelated to this bug (problems with pulse configuration and codec performance vs. missing driver). There is significant interest in not setting flat-volumes = no, as this is considered to give users the most intuitive response to use of the audio controls available in the OS.

If the kernel is unable to set a sensible default configuration on initialisation, the omap4_amixer_config.sh should be replaced with files in /usr/share/alsa/ as documented in comment #1. Entries like "amixer cset name='Earphone Driver Switch' 1" would become "CTL{name}='Earphone Driver Switch', CTL{value}=1". An entry needs to be added to /usr/share/alsa/init/00main to load this new file conditionally based on CARDINFO.

The proposed changes to pulse's default.pa are firstly disabling module-console-kit, which is undesireable, as this is used for such purposes as allowing user switching and audio at the GDM prompt as well as post-login; and secondly static loading of various modules: this static loading is unsuitable as a default for varied hardware, but it is better to rely on module-udev-detect: if the issues cannot be solved in the kernel, and appropriate defaults cannot be set for one reason or another, additional udev rules ought be added to provide pulseaudio with the appropriate information to load the modules correctly only where that hardware is present.