Bug Description

with the current daily-preinstalled images (from build 20100913 on) which include new kernel patches and which are built for ES2.0 boards only. we do not have a sound device in the sound prefs dialog anymore, only the dummy device shows up.

the dialog should have two sound output devcies, one for the earphone jack, one for HDMI output. with the earphone jack being the default preselected output.

I believe the correct way to fix this is by creating a board-specific driver that will indicate the wire layout from the codec (which driver exists) to the ports on specific boards. Failing this, there may be ways to hardcode the wire layout either (incorrectly) in the codec driver, or (less bad) by setting quirks based on some other discoverable factor about the board.

If no kernelspace solution is available, a hardcoded asound.conf in a separate package (or created by jasper) is is very heavy-handed and inflexible way to address the issue, and has significant potential to break other audio paths (e.g. USB audio). Much better would be to add codec-specific initialisation into a configuration fragment in the /usr/share/alsa/ distributor configuration directory. I'm not deeply familiar with this, but I believe that adding a /usr/share/alsa/init/omap4 or similar would be appropriate as a fallback for buggy kernel drivers (with appropriate conditional inclusion from 00main).

oh, and please note that we can not change the deamon.conf file from any packages but pulseaudio itself (and i assume the flat-volumes = no is a required setting on other arches) if we need to do overrides like that, i think emmets way of using the alsa initalization framework is the best way to go here (default.pa should be fine once teh multi-config patch is in pulse)

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.

Bryan, with same kernel patched on top of omap4 cdimage from 29-sep-2010 + sdp4430.conf, I have no sound either. Earphone and headset should be both turned on by this file. However, what I see is that the file is read when PA is started but somehow settings get overwritten or not taken into account. "amixer controls" list all the controls and "amixer cget numid=<control numid<>" retrieves a value for a control. I can also see an asound.state file is created. But still I don't get how all that work together b/w alsa and pulseaudio.

First, I'd be happy to find out how SDP4430.conf is read and if this file is properly formatted and read by alsa.

With these latest audio updates, and while SDP4430.conf file is not properly used, the attached amixer.sh script can be used to properly configure the audio path.
Using this script, I was able to play audio on the headset connector (lower connector) with the audio patches update.

hmm, not so well, i just found that this only works if "alsactl init" is called, which seems to be gone from our setup completely (you can call it manually but that seems awkward ... another way to use this as a slightly cleaner hack migh be to call alsactl init from a udev rule if the device is initialized)

so in this light the only actually proper fix is to use the SDP4430.conf file but fix it so it gets properly executed ...

the above fix is just a better alternative to the hack the amixer.sh script provides but requires a one line patch to libasound0 which i'm not sure the release team would be happy to accept its a tad less evil but stil evil.

ASoC audio (like used on most ARM platforms) has controls for setting up the backend routing... as you can see above pulse is not enough to initialize sound here.
i will try to find criteria for the hardware with which we can match it in a udev rule which in turn can call the alsactl init thats necessary.

i managed to testbuild the fixes from bug 652035 today, and they in fact initialize the card fine using the omap4 file from above and teh one line change in 00main ... could someone upload a test kernel binary with the other changes so i can actually test the alternative omap4 file that switches on card name ?

First of all I'd like to take this opportunity to thank all those who attended the Panda audio brainstorming session. I hope it proved productive for you all.

Attendees of the meeting are as follows; lag, mpoirier, diwic, berco, sebjan, lrg, rsrimushnam, persia and abduenas. I'm sure there were some spectators and side-liners there also.

I believe it's worth forking development down two routes; one for Maverick, consisting of best hacks and workarounds we can think of, and one for Natty, using the most up-to-date mechanisms for insuring an intuitive audio framework for the future.

Maverick discussion:
There are multiple issues currently preventing correct audio behavior within Maverick. Solving any single issue will not insure correct audio behavior. These issues will be discussed in turn.

The kernel audio driver does not export key information needed by scripts running in userspace. This prevents successful platform differentiation. Unless other similar boards use exactly the same configuration, a solution that works well on one platform may well not work on another. To solve this issue it is believed that the kernel audio driver should export at least a unique 'platform name'. A good example of a script which configures mixer settings based on exported 'platform names' can be found in '/usr/share/alsa/init/hda'.

[ACTION] Liam Girdwood to write a patch which which exports the device's 'platform name'.

Once the 'platform name' has been exported from the driver, Oliver's usermode scripts will be able to configure the mixers correctly for the current board. These scripts include a one line change in '/usr/share/alsa/init/00main' which tells ALSA which configuration file to load - in our case 'omap4'. The 'omap4' file will reside in the same location, thus '/usr/share/alsa/init/omap4'.

[ACTION] Oliver Grawert to edit '00main' and locate the new 'omap4' file in '/usr/share/alsa/init/'

The other issue is that HDMI audio output is not initialised and exposed to Pulse correctly. ALSA's Use Case Manager (UCM) would be an ideal solution to this, but unfortunately it's not available to us yet. Instead, the same can be achieved with a modified Pulse profile. The Pulse Audio (PA) team have agreed to include our profile in native-instruments-audio8dj.conf. Using the modified profile in conjunction with Oliver's init script would provide us with everything we needed for selectable output (default would be analog output). If there are interested parties wishing to adjust default settings they should be encouraged to download 'pavucontrol' from our repos. When the kernel audio driver has been patched to export the 'platform name', Pulse Audio can then auto-detect the bespoke profile. Once compete the bespoke Pulse profile file will be located in '/usr/share/pulseaudio/alsa-mixer/profile-sets'.

[ACTION] Abraham Duenas de la Cruz to write a PA profile for SDP4430/OMAP4
[ACTION] David Hessingsson to provide support
[ACTION] David Bercovitz to test

It has been decided that using uniform control names at this early stage wouldn't necessarily be a good thing. The reason behind this decision is that they can not be applied to all current audio hardware....

testing further we apparently still need the alsactl init call even with the fix from bug 652035.
but that fix actually made calling alsactl init from the preinit_levels hack in /sbin/alsa-utils work (which didnt work before)

so my current proposal is:

go forward with the kernel patches from liam that make the sound card distinguishable by boardname (will attache them here now)

go also forward with the 00main change and the omap4 file (but one that adjusts mixer levels based on card name)

and additionally apply a change to /sbin/alsa-utils that calls alsactl init for Panda and SDP4430 boards (there is a function called preinit_levels_on_card() which seems to be suited for this)

Accepted linux-ti-omap4 into maverick-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Testing pulseaudio profile file for pandaboard to copy in /usr/share/pulseaudio/alsa-mixer/profile-sets/
+ you need to add one line in /lib/udev/rules.d/90-pulseaudio.rules file so that it add panda.conf -> looks like this:

Accepted alsa-utils into maverick-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

[ Luke Yelavich ]
* Merge from debian unstable. Remaining changes:
- debian/init:
+ wait until /usr/bin and /var/lib/alsa exist
+ only display an error when dealing with alsactl if there is no card
specified
+ Set sane level for 'Speaker' and 'Headphone', needed for Dell Mini 9
and Dell E series
+ ute PC Beep on hda cards that support it during initial volume setup
+ update lsb header to indicate no running of the script unless the
udev rule is run
+ Mute *Analog/Digital Control for Creative cards by default
+ Default Digital Input Source to be Digital Mic 1 so that users
with digital mic will be able to use it out of the box
+ Mute "IEC958 Optical Raw" by default
+ Set sane level for headphone 1 for Dell Studio XPS with 2.6.30
+ Don't muck with sound card state if alsactl restore fails
+ Don't wait for 1 second after alsactl store
+ Stop muting on reboot/shutdown
+ Prefer built-in digital mics on newer Dells
+ Unmute 'Line HP Swap' for Dove boards
- debian/rules:
+ ship udev rules file in /lib/udev/rules.d
+ Do not install start symlinks for the alsa-utils init script, it gets
run from a udev rule
- debian/udev.script: do not use hotplug functions
- debian/README.init.cs4236: Include in /usr/share/doc/alsa-utils so that
users of snd-cs4236 (e.g., ThinkPad 600) can have audible sound
- debian/patches/unset_pulse_internal.patch: We don't want alsamixer to
show the pulse mixer by default, since it can be controlled from
pulseaudio itself
- debian/patches/fix_misspelling_speaker-test_man_page.patch: Fix
misspelling in speaker-test(1)
- Remove alsaconf from build system and remove po files
- Create an upstart job specifically saving mixer levels to resolve race
- Version build-dep to upstart-aware debhelper.
- Move the initscript into /sbin. We now have an upstart job just for
handling alsactl store
- Include several changes from upstream git master:
+ upstream git changesets:
+ dcb90a77 - Use "Found hardware:" instead "Unknown hardware:"
+ 7f6a55e2 - use "generic method" instead "guess method"
+ 52bd2f8a - Handle "Capture Source" and "Mic Boost"
+ ef919a47 - Initialize also "Master Front Playback Volume" & "Switch"

[ Oliver Grawert ]
* debian/patches/add_omap4_support.patch: [adds support for the OMAP4
Pandaboard as well as for the OMAP4 Blaze SDP4430 SoC]
* debian/init add a separate call to alsactl init in case an SDP4430 or
OMAP4 Pandaboard is detected. This ASoC driver requires explicit
initialization currently (LP: #637947)

Accepted alsa-utils into maverick-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

* make the posinst test for Panda and SDP4430 cards not fail (LP: #664645)

alsa-utils (1.0.23-2ubuntu3.3) maverick-proposed; urgency=low

* debian/patches/add_omap4_support.patch: [Make sure
alsactl/init/Makefile.am and alsactl/init/Makefile.in install the omap4
file along with the other init files] (LP: #637947)
* also init all OMAP4 devices once from postinst so that the state file is
updated with proper initialization values (LP: #637947)

alsa-utils (1.0.23-2ubuntu3.2) maverick-proposed; urgency=low

* debian/patches/add_omap4_support.patch: [adds support for the OMAP4
Pandaboard as well as for the OMAP4 Blaze SDP4430 SoC]
* debian/init add a separate call to alsactl init in case an SDP4430 or
OMAP4 Pandaboard is detected. This ASoC driver requires explicit
initialization currently (LP: #637947)

This happens because the package tries to call alsactl init, and the config file expects the installed kernel to have both kernel patches posted at this bug, what is not the case when giving apt-get upgrade (the kernel update went on-line at the same time as the package update).

To fix this you basically need to call alsactl init only if the user already has the proper kernel installed and etc.