no sound devices on current ES2.0 boards

Bug #637947 reported by Oliver Grawert
38
This bug affects 3 people
Affects Status Importance Assigned to Milestone
alsa-utils (Ubuntu)
Fix Released
High
Oliver Grawert
Maverick
Fix Released
High
Oliver Grawert
linux-ti-omap4 (Ubuntu)
Fix Released
High
Lee Jones
Maverick
Fix Released
High
Lee Jones

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.

Oliver Grawert (ogra)
tags: added: armel
Changed in linux-ti-omap4 (Ubuntu Maverick):
milestone: none → ubuntu-10.10
importance: Undecided → High
Lee Jones (lag)
Changed in linux-ti-omap4 (Ubuntu Maverick):
assignee: nobody → Lee Jones (lag)
status: New → Confirmed
Revision history for this message
Emmet Hikory (persia) wrote :

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).

Revision history for this message
Lee Jones (lag) wrote :

Applied all new patches from TI's L24.9 branch.

Still not sound on 6 layer ES2.0.

Revision history for this message
Oliver Grawert (ogra) wrote :

no device at all in the sound settings panel ?
how about the 8 layer board ?

Revision history for this message
David Bercovitz (berco) wrote :

These settings will part of an OMAP4 config package

Revision history for this message
David Bercovitz (berco) wrote :
Revision history for this message
David Bercovitz (berco) wrote :
Revision history for this message
Lee Jones (lag) wrote :

There is a sound icon in the panel.

I don't have an 8 layer board to test.

I have a few more things to try on the 6 layer board.

Revision history for this message
David Bercovitz (berco) wrote :

L24.9 works well on my Panda 8-layers.
I have used PA default.pa and daemon.conf files attached and setup the amixer settings with the attached config file.

In the Sound Preferences applet Ihave:
- Hardware tab => no hardware listed
- Input tab => "SDP4430" is listed
- Output tab => "HDMI stereo" and "Onboard_speakers stereo" are listed.

Audio works fine in MP3 playback using Totem.

Revision history for this message
Oliver Grawert (ogra) wrote :

nothing in hardware tab does not look right to me.

Revision history for this message
Oliver Grawert (ogra) wrote :

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)

Revision history for this message
Lee Jones (lag) wrote :

I only have "Onboard_speakers" in my Output tab.

Still no sound from my 6 layer.

Revision history for this message
Lee Jones (lag) wrote :

I just received this while playing a *.ogg file.

Still no audio.

Revision history for this message
Emmet Hikory (persia) wrote :

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.

Revision history for this message
Oliver Grawert (ogra) wrote :

testing on my ES2.0 8-layer i only need teh amixer hack and the following change in default.pa to make sound work

--- /etc/pulse/default.pa.bak 2010-09-17 09:52:51.000000000 +0200
+++ /etc/pulse/default.pa 2010-09-17 10:17:27.000000000 +0200
@@ -48,6 +48,11 @@
 #load-module module-null-sink
 #load-module module-pipe-sink

+# OMAP4 panda hacks
+load-module module-alsa-sink device=hw:0,0 sink_name=output format=s32le rate=48000 channels=2 sink_properties=device.description=Onboard_speakers tsched=0
+load-module module-alsa-sink device=hw:0,7 sink_name=hdmi sink_properties=device.description=HDMI
+load-module module-alsa-source device=hw:0,2 source_name=input tsched=0
+
 ### Automatically load driver modules depending on the hardware available
 .ifexists module-udev-detect.so
 load-module module-udev-detect

Revision history for this message
Lee Jones (lag) wrote :

I've come to the conclusion that audio is not possible on my board.

I believe this could be down to a faulty filter.

Revision history for this message
Oliver Grawert (ogra) wrote :

please see bug 644828 too

tags: added: omap4 panda
Revision history for this message
David Bercovitz (berco) wrote :

They should be enough for ALSA conf

Revision history for this message
David Bercovitz (berco) wrote :

Second patch needed too

tags: added: iso-testing
tags: added: patch
Revision history for this message
David Bercovitz (berco) wrote :
Revision history for this message
Bryan Wu (cooloney) wrote :

I got one more audio fixing patch from Sebjan and pushed all the audio patches here:
http://kernel.ubuntu.com/git?p=roc/ubuntu-maverick.git;a=shortlog;h=refs/heads/ti-omap4

And a audio fixing kernel was built for testing:
http://people.canonical.com/~roc/kernel/audio/

After installing the audio kernel on my ES2.0 8 layers board, I did following testing:
 - cp SDP4430.conf from Berco to /usr/share/alsa/cards/SDP4430.conf
 - aplay: http://pastebin.ubuntu.com/503799/
 - pulseaudio: I followed David Henningsson's wiki: https://wiki.ubuntu.com/PulseAudio/Log. PA fails to run, here is the log: http://pastebin.ubuntu.com/503801/
 - run alsamixer -D hw:0 to turn on earphone and headset
 - run speaker-test -D plughw:0,9 -t sine -c 2, I can here sound from my earphone.

So far, I think kernel's ASoC driver works, maybe some audio system configuration issue blocks us.

-Bryan

Revision history for this message
David Bercovitz (berco) wrote :

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.

-David.

Revision history for this message
Sebastien JAN (sebjan) wrote :

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.

Revision history for this message
Sebastien JAN (sebjan) wrote :

To complement my previous comment, the testing went well also using totem after replacing /etc/pulse/default.pa with attached one, and reboot.

Revision history for this message
Oliver Grawert (ogra) wrote :

the following patch together with the attached omap4 file put into /usr/share/alsa/init/ will make sure the mixer controls are properly set by default:

--- /usr/share/alsa/init/00main 2010-09-23 13:11:10.000000000 +0200
+++ 00main 2010-10-05 20:24:24.000000000 +0200
@@ -32,6 +32,7 @@
 # real ALSA configuration database
 CARDINFO{driver}=="HDA-Intel", INCLUDE="hda", GOTO="init_end"
 CARDINFO{driver}=="CA0106", INCLUDE="ca0106", GOTO="init_end"
+CARDINFO{driver}=="SDP4430", INCLUDE="omap4", GOTO="init_end"
 CARDINFO{driver}=="Test", INCLUDE="test", GOTO="init_end"

 LABEL="init_end"

Revision history for this message
Oliver Grawert (ogra) wrote :
Revision history for this message
Lee Jones (lag) wrote :

Now we're talking.

Well done Oliver.

Revision history for this message
Oliver Grawert (ogra) wrote :

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.

Revision history for this message
Oliver Grawert (ogra) wrote :

the very intresting part is that the above makes pulse work out of the box without any changes (it omits the hdmi sound output though)

Revision history for this message
David Henningsson (diwic) wrote :

Hmm...it might be that "alsactl init" was removed by Daniel T Chen just a week or two ago - I believe the reasoning was that PA still sets all volumes, so why set them one more time?

Revision history for this message
Oliver Grawert (ogra) wrote :

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.

Revision history for this message
Robbie Williamson (robbiew) wrote :

FYI, this has been release noted on https://wiki.ubuntu.com/ARM/MaverickReleaseNotes

Changed in linux-ti-omap4 (Ubuntu Maverick):
milestone: ubuntu-10.10 → none
milestone: none → maverick-updates
Revision history for this message
Oliver Grawert (ogra) wrote :

i was just pointed to bug 652035 that might have some influence on the stuff we see here... will do some tests with the alsa-lib changes before we meet tomorrow

Revision history for this message
Oliver Grawert (ogra) wrote :

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 ?

Revision history for this message
Lee Jones (lag) wrote :
Download full text (4.5 KiB)

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....

Read more...

Emmet Hikory (persia)
Changed in alsa-utils (Ubuntu Maverick):
status: New → Triaged
importance: Undecided → High
Changed in alsa-utils (Ubuntu):
importance: Undecided → High
status: New → Triaged
Changed in linux-ti-omap4 (Ubuntu):
milestone: maverick-updates → none
Changed in alsa-utils (Ubuntu Maverick):
milestone: none → maverick-updates
Emmet Hikory (persia)
Changed in alsa-utils (Ubuntu Maverick):
assignee: nobody → Oliver Grawert (ogra)
Changed in alsa-utils (Ubuntu):
assignee: nobody → Oliver Grawert (ogra)
Changed in linux-ti-omap4 (Ubuntu Maverick):
status: Confirmed → Triaged
Revision history for this message
Oliver Grawert (ogra) wrote :

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)

Revision history for this message
Oliver Grawert (ogra) wrote :
Revision history for this message
Oliver Grawert (ogra) wrote :
Revision history for this message
Oliver Grawert (ogra) wrote :
Revision history for this message
Oliver Grawert (ogra) wrote :
Revision history for this message
Oliver Grawert (ogra) wrote :
Revision history for this message
Oliver Grawert (ogra) wrote :

with the two kernel patches above and additionally the two files added to alsa-utils (plus the four line patch) sound works out of the box here now.

Revision history for this message
Oliver Grawert (ogra) wrote :

the alsa-libs part was uploaded to maverick-proposed now

Changed in alsa-utils (Ubuntu Maverick):
status: Triaged → Fix Committed
Revision history for this message
Martin Pitt (pitti) wrote : Please test proposed package

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!

Changed in linux-ti-omap4 (Ubuntu Maverick):
status: Triaged → Fix Committed
tags: added: verification-needed
Revision history for this message
David Bercovitz (berco) wrote :

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:

SUBSYSTEM!="sound", GOTO="pulseaudio_end"
ACTION!="change", GOTO="pulseaudio_end"
KERNEL!="card*", GOTO="pulseaudio_end"

SUBSYSTEMS=="usb", ATTRS{idVendor}=="17cc", ATTRS{idProduct}=="1978", ENV{PULSE_PROFILE_SET}="native-instruments-audio8dj.conf"
SUBSYSTEMS=="usb", ATTRS{idVendor}=="17cc", ATTRS{idProduct}=="0839", ENV{PULSE_PROFILE_SET}="native-instruments-audio4dj.conf"
SUBSYSTEMS=="usb", ATTRS{idVendor}=="0763", ATTRS{idProduct}=="2012", ENV{PULSE_PROFILE_SET}="maudio-fasttrack-pro.conf"
SUBSYSTEMS=="sound", ATTRS{id}=="SDP4430", ATTRS{number}=="0", ENV{PULSE_PROFILE_SET}="panda.conf"

LABEL="pulseaudio_end"

Revision history for this message
Oliver Grawert (ogra) wrote :

this file is incorrect, with the new kernel patches the sound card reports the board name now as ID so it needs two lines for omap4 (one with ATTRS{id}=="Panda" the other as above)

Revision history for this message
Martin Pitt (pitti) wrote :

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!

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package alsa-utils - 1.0.23-3ubuntu1

---------------
alsa-utils (1.0.23-3ubuntu1) natty; urgency=low

  [ 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)

  [ Daniel T Chen ]
  * debian/init: Fix naming of script (LP: #654902)

alsa-utils (1.0.23-3) unstable; urgency=low

  [ Elimar Riesebieter ]
  * unmute_and_set_level "Front Speaker" "80%" for MacBookPro. (closes: #597791)
 -- Luke Yelavich <email address hidden> Tue, 19 Oct 2010 16:22:41 +1100

Changed in alsa-utils (Ubuntu):
status: Triaged → Fix Released
Revision history for this message
Martin Pitt (pitti) wrote :

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!

Revision history for this message
LGB [Gábor Lénárt] (lgb) wrote :

@Martin Pitt: I have a problem with alsa-utils_1.0.23-2ubuntu3.3_i386.deb, see bug #664812
Is it a regression caused with this update, or some other issue? Thanks!

Revision history for this message
Oliver Grawert (ogra) wrote :

it is caused by this update and was fixed in ubuntu3.4 already

Revision history for this message
LGB [Gábor Lénárt] (lgb) wrote :

Thanks a lot, it seems to be OK now, indeed!

Lee Jones (lag)
Changed in alsa-utils (Ubuntu Maverick):
status: Fix Committed → Fix Released
Changed in linux-ti-omap4 (Ubuntu):
status: Confirmed → Fix Released
Changed in linux-ti-omap4 (Ubuntu Maverick):
status: Fix Committed → Fix Released
Revision history for this message
Jean-Baptiste Lallement (jibel) wrote :

setting the maverick task to fix committed as the fix is not in maverick yet.

Changed in alsa-utils (Ubuntu Maverick):
status: Fix Released → Fix Committed
Changed in linux-ti-omap4 (Ubuntu Maverick):
status: Fix Released → Fix Committed
tags: added: verification-done
removed: verification-needed
Revision history for this message
Lee Jones (lag) wrote :

Ah, my mistake.

When are the updates due for release?

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package alsa-utils - 1.0.23-2ubuntu3.4

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

  * 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)

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

  * debian/init: Fix naming of script (LP: #654902)
 -- Oliver Grawert <email address hidden> Thu, 21 Oct 2010 21:26:33 +0200

Changed in alsa-utils (Ubuntu Maverick):
status: Fix Committed → Fix Released
Changed in linux-ti-omap4 (Ubuntu Maverick):
status: Fix Committed → Fix Released
Revision history for this message
Ricardo Salveti (rsalveti) wrote :

With the current version:

# apt-get install alsa-utils
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will be upgraded:
  alsa-utils
1 upgraded, 0 newly installed, 0 to remove and 4 not upgraded.
1 not fully installed or removed.
Need to get 1,107kB of archives.
After this operation, 4,096B of additional disk space will be used.
Get:1 http://ports.ubuntu.com/ubuntu-ports/ maverick-updates/main alsa-utils armel 1.0.23-2ubuntu3.4 [1,107kB]
Fetched 1,107kB in 0s (1,327kB/s)
(Reading database ... 103571 files and directories currently installed.)
Preparing to replace alsa-utils 1.0.23-2ubuntu3 (using .../alsa-utils_1.0.23-2ubuntu3.4_armel.deb) ...
Unpacking replacement alsa-utils ...
Processing triggers for ureadahead ...
Processing triggers for man-db ...

Setting up alsa-utils (1.0.23-2ubuntu3.4) ...
Found hardware: "SDP4430" "" "" "" ""
Hardware is initialized using a generic method
dpkg: error processing alsa-utils (--configure):
 subprocess installed post-installation script returned error exit status 99
dpkg: dependency problems prevent configuration of ubuntu-netbook:
 ubuntu-netbook depends on alsa-utils; however:
  Package alsa-utils is not configured yet.
dpkg: error processing ubuntu-netbook (--configure):
 dependency problems - leaving unconfigured

Errors were encountered while processing:
 alsa-utils
 ubuntu-netbook

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.

Revision history for this message
Ricardo Salveti (rsalveti) wrote :

Following the kernel commit http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-maverick.git;a=commitdiff;h=5469d37bd56cbe8b604e83a8dc769984de5e7437;hp=6b8a624f7c72ac07c28f52371839792d69940c5b you can identify if you're at the proper kernel by probing the driver's name or the long name.

The attached patch check for the correct long name before calling alsactl init.

This at least fixes the apt-get upgrade problem.

Revision history for this message
David Bercovitz (berco) wrote :

I enabled maveric-updates in /etc/apt/sources.list and tried to update the alsa-utils package. I see some errors at the end of the installation and don't know if everything got setup correctly. Here is the log (see 3 last lines):
$ sudo apt-get install alsa-utils
...
1 upgraded, 0 newly installed, 0 to remove and 148 not upgraded.
Need to get 1,107kB of archives.
After this operation, 4,096B of additional disk space will be used.
Get:1 http://ports.ubuntu.com/ubuntu-ports/ maverick-updates/main alsa-utils armel 1.0.23-2ubuntu3.4 [1,107kB]
Fetched 1,107kB in 11s (97.8kB/s)
(Reading database ... 166815 files and directories currently installed.)
Preparing to replace alsa-utils 1.0.23-2ubuntu3 (using .../alsa-utils_1.0.23-2ubuntu3.4_armel.deb) ...
Unpacking replacement alsa-utils ...
Processing triggers for ureadahead ...
ureadahead will be reprofiled on next reboot
Processing triggers for man-db ...
Setting up alsa-utils (1.0.23-2ubuntu3.4) ...
No protocol specified
xcb_connection_has_error() returned true
Home directory /home/ubuntu not ours.

Revision history for this message
David Bercovitz (berco) wrote :

I found that "alsactl init" cannot be run in sudo. This command is called in the postinst script in alsa-utils.

$ sudo alsactl init
Home directory /home/ubuntu not ours.
socket(): Address family not supported by protocol
Found hardware: "SDP4430" "" "" "" ""
Hardware is initialized using a generic method

Revision history for this message
Oliver Grawert (ogra) wrote :

your kernel is wrong, teh sound device is not named properly, you need teh kernel from -proposed first

Revision history for this message
David Bercovitz (berco) wrote :

I think I have a kernel with the correct information:

ubuntu@ubuntu-blaze:/sys$ cat /proc/asound/cards
 0 [SDP4430 ]: SDP4430 - SDP4430
                      TI OMAP4 SDP4430 Board

Revision history for this message
David Bercovitz (berco) wrote :

For the record: ok, my mistake. Wrong kernel actually. However, #57 error is still valid in my case with corrected kernel version.

Revision history for this message
David Bercovitz (berco) wrote :

updating alsa-utils in a ssh console will generate the errors I see i.e.:
$ sudo apt-get install alsa-utils
...
1 upgraded, 0 newly installed, 0 to remove and 148 not upgraded.
Need to get 1,107kB of archives.
After this operation, 4,096B of additional disk space will be used.
Get:1 http://ports.ubuntu.com/ubuntu-ports/ maverick-updates/main alsa-utils armel 1.0.23-2ubuntu3.4 [1,107kB]
Fetched 1,107kB in 11s (97.8kB/s)
(Reading database ... 166815 files and directories currently installed.)
Preparing to replace alsa-utils 1.0.23-2ubuntu3 (using .../alsa-utils_1.0.23-2ubuntu3.4_armel.deb) ...
Unpacking replacement alsa-utils ...
Processing triggers for ureadahead ...
ureadahead will be reprofiled on next reboot
Processing triggers for man-db ...
Setting up alsa-utils (1.0.23-2ubuntu3.4) ...
No protocol specified
xcb_connection_has_error() returned true
Home directory /home/ubuntu not ours.

If I do the same thing in a console on the board, the installation goes fine.

Revision history for this message
David Henningsson (diwic) wrote :

> No protocol specified
> xcb_connection_has_error() returned true

Hmm, this might be worth investigating further, but it's probably a separate bug, unless your new alsa-utils is homebrewn somehow.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.