No sound on omap4

Pulseaudio version is 1:0.9.22+stable-queue-24-g67d18-0ub

Is there an E for this patchset anywhere? I know this is hardware enablement, but a lot of alsa and pulse code is being added/modified in this series of patches, such that I don't feel comfortable putting it in wholesale without release teamn approval.

The patches are in tarball form here: http://afuera.cortijodelrio.net/~ddiaz/paucm/

You can find the UCM PA patches on the pulseaudio mailing list here:

https://tango.0pointer.de/pipermail/pulseaudio-discuss/2011-April/009746.html

so there was a lot confusion about what we actually need. here the actual links to the two archives needed:

http://afuera.cortijodelrio.net/~ddiaz/paucm/PA_UCM_cofigFiles.tar.gz
http://afuera.cortijodelrio.net/~ddiaz/paucm/UCM-patches-commit-message.tar.bz2

also these patches seem to differ from what was sent to the PA ML

I was asked today to make a review of the current PA patches for UCM.
I've been told that for omap4, sound is currently dysfunctional and
these patches help. For all others, no added functionality and so we
need to take all precautions possible to avoid regressions.

Seems like there are two distinct parts of functionality added, the UCM
configuration to PA profile mapping, and jack detection.

Let's focus on the UCM to PA first:

This seems relatively safe from regressions: the only thing that is now
called for all cards is snd_use_case_mgr_open. It would be preferable if
this was proactively selected, e g through a udev rule or through a
module parameter passed on through module-udev-detect to the alsa card
module. All other usages of ucm functions are never called if
snd_use_case_mgr_open returns false.

A few comments on the code:
- It would be great if all the new ucm functionality was in a separate
pair of .c and .h files. That would make it easier for us to pick up
patches to the alsa-card.c file from upstream. I also believe upstream
would appreciate that separation.
- pa_log is used extensively, should be pa_log_debug, pa_log_info to
avoid annoying syslog messages.

For the jack detection code, that's currently not finished. The current
code doesn't add anything of value to the end user, so my recommendation
is not to merge it at this point. Margarita is working on a new version
but it is not finished yet. Anyway, that part is more invasive to
current code and so if we decide to merge it I strongly recommend to
keep it disabled by default and make a module parameter to
module-udev-detect to enable jack detection explicitly.

--
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic

I was asked today to make a review of the current PA patches for UCM. I've been told that for omap4, sound is currently dysfunctional and these patches help. For all others, no added functionality and so we need to take all precautions possible to avoid regressions.

Seems like there are two distinct parts of functionality added, the UCM configuration to PA profile mapping, and jack detection.

Let's focus on the UCM to PA first:

This seems relatively safe from regressions: the only thing that is now called for all cards is snd_use_case_mgr_open. It would be preferable if this was proactively selected, e g through a udev rule or through a module parameter passed on through module-udev-detect to the alsa card module. All other usages of ucm functions are never called if snd_use_case_mgr_open returns false.

A few comments on the code:
- It would be great if all the new ucm functionality was in a separate pair of .c and .h files. That would make it easier for us to pick up patches to the alsa-card.c file from upstream. I also believe upstream would appreciate that separation.
- pa_log is used extensively, should be pa_log_debug, pa_log_info to avoid annoying syslog messages.

For the jack detection code, that's currently not finished. The current code doesn't add anything of value to the end user, so my recommendation is not to merge it at this point. Margarita is working on a new version but it is not finished yet. Anyway, that part is more invasive to current code and so if we decide to merge it I strongly recommend to keep it disabled by default and make a module parameter to module-udev-detect to enable jack detection explicitly.

A new update was posted to me through email a few hours ago.

> This seems relatively safe from regressions: the only thing that is now called for all cards is snd_use_case_mgr_open. It would be
> preferable if this was proactively selected, e g through a udev rule or through a module parameter passed on through module-
> udev-detect to the alsa card module.

This has not changed in the version posted, comment remains.

> - It would be great if all the new ucm functionality was in a separate pair of .c and .h files. That would make it easier for us to pick
> up patches to the alsa-card.c file from upstream. I also believe upstream would appreciate that separation.

This has improved.

> - pa_log is used extensively, should be pa_log_debug, pa_log_info to avoid annoying syslog messages.

This is ok now although it seems like every pa_log has just changed to pa_log_info.

> For the jack detection code, that's currently not finished. The current code doesn't add anything of value to the end user,

It is unclear to me whether the new version adds value or not. Some things might have improved, but there is still no card matching, and there will still be calls to ucm functions even for non ucm cards.

> that part is more invasive to current code and so if we decide to merge it I strongly recommend to keep it disabled by default and
> make a module parameter to module-udev-detect to enable jack detection explicitly.

This has not been considered, recommend not to take the jack detection part for now.

In addition, the new version has three new patches about "namereg_fail", without any explanation as of what they would solve.

Summary:

UCM profile patches (OK):

0001-alsa-make-visible-profile-functions.patch
0002-alsa-add-proplist-ucm-data.patch
0003-alsa-add-ucm-data-structures-and-calls.patch
0004-alsa-add-support-for-ucm-profiles.patch

Namereg patches (Not OK - No reason given why this is needed or what it would improve):

0001-alsa-sink-source-Use-the-namereg_fail-module-argumen.patch
0001-module-alsa-card-New-argument-namereg_fail.patch
0001-module-udev-detect-When-loading-module-alsa-card-use.patch

Jack detection patches (Not OK - still not finished and too invasive at this part of the cycle):

0005-alsa-add-jack-detection-support.patch
0006-alsa-add-hook-calls-for-jack-insertion-and-removal.patch
0007-alsa-load-jack-detection-module.patch

Might be needed for compilation on our current version of PulseAudio (OK if needed):

UCM-decibel_fixes-compilation-error-on-PA-0-9-22.patch
UCM-undefined-references-pa_xxx.patch

Here are the patches reviewed in the last comment.

You will find a package with the recommended patches applied in my PPA, http://launchpad.net/~themuso/+archive. My PPA is x86 only, so arm folks will have to role their own package, however it is important that this gets tested on x86 as well. Binaries for x86 should be available in a few hours.

pulse armel binaries with the 4 patches are at http://people.canonical.com/~ogra/natty-omap4-pulse/

This bug was fixed in the package alsa-lib - 1.0.24.1-0ubuntu5

---------------
alsa-lib (1.0.24.1-0ubuntu5) natty; urgency=low

  * Add ALSA UCM config files for omap4 (LP: #746023)
 -- Luke Yelavich <email address hidden> Mon, 11 Apr 2011 20:52:10 +1000

the armel builds of the new pulse test packages are at
http://people.canonical.com/~ogra/natty-omap4-pulse/
if someone tests,, please test them together with the just uploaded libasound2 1.0.24.1-0ubuntu5

Tested with the new alsa-lib package and the pulse ones provided by Oliver but still unable to hear a sound. I cleaned up my alsa-state, rebooted and still no sound.

During boot I'm still seeing some error messages, like:
[ 903.817871] asoc: no valid backend routes for PCM: SDP4430 Media
[ 903.825408] asoc: no valid backend routes for PCM: SDP4430 Media

At the mixer application I can see the PandaHDMI output only, but unable to hear from hdmi. Also tried the audio jack but got nothing.

I installed the arm packages at http://people.canonical.com/~ogra/natty-omap4-pulse/ onto the linaro ubuntu-desktop image and booted on a beagle C4, still no audio. (I did check the levels in alsamix, looks ok) I also booted this same image on a beagle Xm. Again no audio.

Thanks for trying, but the omap4 changes are omap4 specific. You have an omap3 system. It will require some different changes, and actually should be less intrusive. See bug 651302 for the omap3 info.

Still no sound on the Pandaboard. I test using speaker-test.

Now, I'm not sure about this, but there's something that looks off in aplay -l:

    card 0: SDP4430 [SDP4430], device 0: Multimedia-null-codec-dai-0 []

That 'null-codec' thing just doesn't look right.

@luke, i guess we are still carrying the maverick init scripts for the panda, these likely need to be removed, i suspect we have conflicts here.

The name of this defect is very misleading, is this really a new feature repository for UCM for PA and Alsa? To my knowledge, PA has not accepted th UCM changes yet.

On Wed, Apr 13, 2011 at 05:00:06AM EST, Oliver Grawert wrote:
> @luke, i guess we are still carrying the maverick init scripts for the
> panda, these likely need to be removed, i suspect we have conflicts
> here.

Since switching to the new alsa init system, we are no longer using the big alsa init script that was used in maverick and earlier, however we are still carrying the omap4 alsa init database patch that was added in Maverick. I of course don't have the hardware to check that it still worked, so I haven't heard of any complaints with that until now.

Luke

following up on comment #19 i filed bug 760571 for removal of the old omap4 init scripts

Still no sound with PPA pulse audio and latest alsa packages (which remove the init scripts). Should I clear anything?

using the packages with the 4 patches included i can see the devices in the hardware tab of the sound preferences for SDP4430 i can select profiles. selecting SDP4430 and clicking on "test speakers" the sound prefs crash.

going to the output tab i am only offered HDMI but not SDP4430 for output, no matter which profile is selected.

@luke 0001-module-udev-detect-When-loading-module-alsa-card-use.patch seems to be missing in your build, i'm trying to add it to my testbuild for arm now.

hmm, adding that patch gets me back to only seeing HDMI in the sound prefs

with a lot of testing we found that two simple udev rules already get SDP4430 working fine, pulse patches are not needed for having working sound.

we will add the udev rules entries to alsa-lib and keep the pulseaudio changes for an SRU and for oneieric

udev rules actually live in alsa-utils, adding a task for it

https://code.launchpad.net/~ogra/alsa-utils/746023/+merge/58483 has the udev rules etc ...

This bug was fixed in the package alsa-utils - 1.0.24.2-0ubuntu6

---------------
alsa-utils (1.0.24.2-0ubuntu6) natty; urgency=low

  * add udev rule to initialize SDP4430 (TI omap4 pandaboard)
    with proper defaults with the alsa use case manager (LP: #746023)
 -- Oliver Grawert <email address hidden> Wed, 20 Apr 2011 13:20:33 +0200

I'm wondering if a udev rule is the proper way to handle this. While it is good for an immediate fix, we should probably explore a more generic way to launch ucm at boot, as this won't fix omap3 (bug 651302).

@Tobin, well, I agree in principle - if so it should be a part of (or replacement of) the volume restore script done by alsactl. At this point I kind of prefer non-invasive fixes and do "the right thing" for the next release. AFAIK we don't have ucm config files for omap3 anyway...?

Actually, I am working on them today. Should have something in a few hours.

Ok, still seeing some issue. The SPD4430 device doesn't show up in pulseaudio until after reboot. Will explore more as to why. May be an init thing.

Apparently the udev rule for alsaucm never fires. First issue is the lack of a path for alsaucm in /lib/udev/rules.d/90-alsa-ucm.rules. Adding /usr/bin to the run lines still doesn't allow the rule to run though.

Changing the alsa-utils portion of the bug back to in-progress as it contains the udev rule.

After debugging this issue with Oliver we got to the following solution:
 * Fix /lib/udev/rules.d/90-alsa-ucm.rule to include the whole alsaucm path;
 * Create a postinst hack that will erase the old alsa state file, call alsaucm and store the new file (the alsa state is restored after the udev rule is called, so it should be removed to avoid the wrong sound card setup);

It's safe to remove the old alsa state file because it's broken with Natty anyway. We should still keep the udev rule in case the user erases the alsa state file by accident, so he can still have a working sound at next reboot.

@Ricardo,
If alsactl restore shouldn't be used in combination with alsaucm, it'd make more sense to combine the alsactl restore and alsaucm calls into the same udev file, calling one or the other depending on the hardware.

> It's safe to remove the old alsa state file because it's broken with Natty anyway.

Could you elaborate on this? Is it broken in general and for all platforms, or just for omap4? Is there a bug report?

On Wed, Apr 27, 2011 at 10:41 AM, David Henningsson
<email address hidden> wrote:
>> It's safe to remove the old alsa state file because it's broken with
> Natty anyway.
>
> Could you elaborate on this? Is it broken in general and for all
> platforms, or just for omap4? Is there a bug report?

Sorry, previous state files for omap4 should all be incorrect because
of the kernel and ucm changes, so it's safe to just remove it if
needed.

if you install todays image without the above fixes, your system will store the non working state on first shutdown.
the problem here is the order of things, udev fires first, then upstart calls the upstart job to restore the state from the existing state file ...
so if you ever booted a system with the original setup, you will have a broken state file that restores the broken state *after* ucm has set the defaults from the udev rule.

using the udev rule alone by default instead of the state file would mean that you dont store the state at all and always force the user into using the HiFi and Record profiles after a reboot, no matter if he selected something different.

what we need is to call alsaucm with the default use cases (HiFi and Record) and then create a new state file with these settings, that might work even without removing the old state file if the postinst calls alsactl store after the settings of alsaucm were applied...

Based purely on the last few comments I *suspect* that the state saving needs to be moved into Pulse so it can sync up with the UCM status that it's managing - I'd guess you'd wind up with only a small bit of state (eg, master volume) being saved, the rest of the card config should come from the UCM setup for the system.

Hi everyone, my pandaboard doesn't have sound, I downloaded and update all package of the natty distribution and revised, reinstalled the alsa-base and alsa-tools, then install the package the http://people.canonical.com/~ogra/natty-omap4-pulse/ and neither work the sound. How do I get the sound system work.

Hi All,

I am not able to record audio on pandaboard.
under sound preferences...showing two options:
                             Hardware->PandaHDMI(1 Output) and SDP4430(1 Output) .
no device for Audio input.

please find pointer to resolve Audio In problem.

As a temporary workaround, here are the steps needed to fix analog audio on panda:

Open a terminal and type:

sudo alsaucm set _verb HiFi
sudo alsaucm set _verb Record
sudo rm /var/lib/alsa/asound.state
sudo reboot

This gets audio out working for me. Audio in is still not functional, but may be driver related (I twiddled every alsamixer control and still didn't get anything).

the input socket is hardwired as line-in, did you try with an mp3 player or some such (mic's dont give you a high enough level) ?
recording works fine here OOTB after setting the Record verb.

You might want to know about http://bazaar.launchpad.net/~ubuntu-audio-dev/alsa-utils/ubuntu.oneiric/revision/90 and bug 803448

I get a workable kernel of panda from linaro landing team, and after set alsa mixer properly, the sound will play well.
amixer cset name='DL1 Mixer Multimedia' 1
amixer cset name='DL1 Media Playback Volume' 118
amixer cset name='Sidetone Mixer Playback' 1
amixer cset name='SDT DL Volume' 120
amixer cset name='DL1 PDM Switch' 1
amixer cset name='HS Left Playback' 'HS DAC'
amixer cset name='HS Right Playback' 'HS DAC'
amixer cset name='Headset Playback Volume' 13

I update the mixer setting into alsa ucm configurations of panda.
http://git.linaro.org/gitweb?p=people/weifeng/alsa-ucm-conf.git
BTW, in linaro release, i can't find udev rules for alsa-utils. So I'm not sure if "alsaucm set _verb HiFi" is called properly. In that case, you can call "sudo alsaucm set _verb HiFi" mannually

BTW, the 1108 release kernel has some module issues, see https://bugs.launchpad.net/linaro-ubuntu/+bug/760919. So I think 1109 would be a fixed release

Latest TILT kernel doesn't show SDP4430 for Panda anymore:

root@linaro-desktop:~# cat /proc/asound/cards
 0 [Panda ]: OMAP4 - Panda
                      TI OMAP4 Board
 1 [PandaHDMI ]: - PandaHDMI
                      TI OMAP4 HDMI Board

Tree: http://git.linaro.org/gitweb?p=people/andygreen/kernel-tilt.git;a=shortlog;h=refs/heads/tilt-linux-linaro-3.0

Guess Ubuntu will also be based on this tree, so this change should also happen at alsa-utils again.

Feng, now we also have a PandaHDMI device, so we may need new configs for it.

I will add HDMI device to HiFi use case, but it won't do any actual mixer control because there's no alsa control for HDMI card. What can it do is only provide some information about the device's PlaybackPCM.
That is to say, nothing in udev rules should be configured for HDMI device, and HDMI device should be available in current ucm configuration.

This bug was fixed in the package alsa-utils - 1.0.24.2-0ubuntu8

---------------
alsa-utils (1.0.24.2-0ubuntu8) oneiric; urgency=low

  * 90-alsa-ucm.rules: Trigger on ATTRS{id}=="SDP4430|Panda" (LP: #746023)
 -- Adam Conrad <email address hidden> Thu, 29 Sep 2011 12:02:39 -0600