sound only works after suspend/resume cycle

Bug #1068804 reported by Alex Chiang on 2012-10-19
This bug affects 11 people
Affects Status Importance Assigned to Milestone
Luke Yelavich
linux-nexus7 (Ubuntu)
David Henningsson
ubuntu-defaults-nexus7 (Ubuntu)
Oliver Grawert

Bug Description

Currently, in Ubuntu on the Nexus 7, audio playback is only working either A) on the first boot after install or b) after a suspend/resume cycle. This is easily reproducible.

Steps to reproduce:
1) Install system
2) Reboot system (after Desktop comes up once)
3) Try to play audio file
4) Note audio doesn't work
5) Suspend from indicator
6) Resume
7) Play sound again; note sound is heard

Alex Chiang (achiang) on 2012-10-19
Changed in newark:
importance: Undecided → High
Chris Van Hoof (vanhoof) on 2012-10-19
Changed in newark:
assignee: nobody → David Henningsson (diwic)
status: New → Confirmed
Chris Van Hoof (vanhoof) wrote :


While having some troubles replicating the no-sound-before-suspend issue, I added a few files just because it didn't take me long to write them...

I don't know how to send patches for review or how things are incorporated into the newark image, so I'm just sending the files here and hope that someone will review and pick them up (or possibly tell me how to properly send them).

The 90-tegra-rt5640.rules goes into /lib/udev/rules.d/
and the files in the alsa-mixer directory should be added to the /usr/share/pulseaudio/alsa-mixer directory on the image.

After a reboot (note: restarting pulseaudio is not enough), Sound settings will show one "Headphones" and one "Speaker" port, selecting one of them will cause sound to output through that port, and volume up/down to change volume of that port and not the other one.

There's no jack detection yet so after plugging in / unplugging, you would have to switch port manually in Sound Settings.

David Henningsson, Canonical Ltd.

Chris Van Hoof (vanhoof) wrote :
Chris Van Hoof (vanhoof) wrote :

Heya David -- Just gave this a spin and am able to play both on speakers
and headphones after selecting a profile ... I do have to click suspend
from the top right menu, then wake it up ... after that I'm listening to
Rack City

Awesome work man!


Alex Chiang (achiang) wrote :

For me, sound worked after first boot, and didn't require a reboot.

Alex Chiang (achiang) wrote :

After a reboot, sound no longer works.

Then, I suspend/resume and sound is working again.

This is as of the 20121020-1 build.

Alex Chiang (achiang) on 2012-10-24
Changed in newark:
importance: High → Medium
Matt Fischer (mfisch) on 2012-10-25
tags: added: nexus7
Matt Fischer (mfisch) on 2012-10-26
information type: Proprietary → Public
tags: added: mobile
affects: newark → ubuntu-nexus7
Alex Chiang (achiang) on 2012-11-05
tags: added: tegra3
Chris Wayne (cwayne18) on 2012-11-08
description: updated
Changed in ubuntu-nexus7:
importance: Medium → Critical
David Henningsson (diwic) wrote :

The contents of /sys/kernel/debug/asoc before S3, i e when sound is not working

David Henningsson (diwic) wrote :

The contents of /sys/kernel/debug/asoc after S3, during playback of working sound

David Henningsson (diwic) wrote :
Download full text (4.8 KiB)

Some analysis on the Tegra side using a diff between the two directories:

>diff -Nur playback-notworking2/tegra30-ahub playback-working2/tegra30-ahub
>--- playback-notworking2/tegra30-ahub 2012-11-07 16:59:10.000000000 +0100
>+++ playback-working2/tegra30-ahub 2012-11-07 17:02:23.000000000 +0100
>@@ -6,7 +6,7 @@
> TEGRA30_AHUB_CHANNEL_CLEAR[1] = 00000000
> TEGRA30_AHUB_CHANNEL_CLEAR[2] = 00000000
> TEGRA30_AHUB_CHANNEL_CLEAR[3] = 00000000

TEGRA30_AHUB_CHANNEL_STATUS seems to vary during playback, maybe it's an indicator of where in the ring buffer you currently are. Probably nothing

>@@ -21,7 +21,7 @@
> TEGRA30_AHUB_MISC_CTRL = 80000000
> TEGRA30_AHUB_DAM_LIVE_STATUS[0] = 00000083
> TEGRA30_AHUB_DAM_LIVE_STATUS[1] = 00000083
> TEGRA30_AHUB_DAM_LIVE_STATUS[2] = 00000083
>@@ -30,7 +30,7 @@
> TEGRA30_AHUB_DAM_INT_MASK = 00939393
>-TEGRA30_AHUB_I2S_INT_STATUS = 0000000c
>+TEGRA30_AHUB_I2S_INT_STATUS = 00000004

These seem interesting - could they be indicating some error in the i2s communication? However, these two registers are not used in code (only referenced during debug code), so it's impossible to tell how to fix it.

>diff -Nur playback-notworking2/tegra30-dam.0 playback-working2/tegra30-dam.0
>--- playback-notworking2/tegra30-dam.0 2012-11-07 16:59:10.000000000 +0100
>+++ playback-working2/tegra30-dam.0 2012-11-07 17:02:23.000000000 +0100
>@@ -2,9 +2,9 @@
> TEGRA30_DAM_CLIP = 00000000
>-TEGRA30_DAM_CH0_CTRL = 12e20300
>-TEGRA30_DAM_CH0_CONV = 000038af
>+TEGRA30_DAM_CH0_CTRL = 52e00300
>+TEGRA30_DAM_CH0_CONV = 000034bd
> TEGRA30_DAM_CH1_CTRL = 00000010
>-TEGRA30_DAM_CH1_CONV = 0000e565
>+TEGRA30_DAM_CH1_CONV = 0000e145

From what I can tell from code, the CH0 and CH1 registers seem to be used for input (and this was a playback test only), so probably these differences are irrelevant.

>diff -Nur playback-notworking2/tegra30-dam.1 playback-working2/tegra30-dam.1
>--- playback-notworking2/tegra30-dam.1 2012-11-07 16:59:10.000000000 +0100
>+++ playback-working2/tegra30-dam.1 2012-11-07 17:02:23.000000000 +0100
>@@ -1,10 +1,10 @@
>-TEGRA30_DAM_CTRL = 00000060
>+TEGRA30_DAM_CTRL = 00000040

The TEGRA30_DAM_CTRL difference here corresponds to sample rate, I believe - but my guess is that we use dam.0 only, so probably irrelevant too?

> TEGRA30_DAM_CLIP = 00000000
>-TEGRA30_DAM_CH0_CTRL = 55cd0800


David Henningsson (diwic) wrote :

Analysis of the RT5640 part of things:

>diff -Nur playback-notworking2/tegra-rt5640/rt5640.4-001c/codec_reg playback-working2/tegra-rt5640/rt5640.4-001c/codec_reg
>--- playback-notworking2/tegra-rt5640/rt5640.4-001c/codec_reg 2012-11-07 16:59:10.000000000 +0100
>+++ playback-working2/tegra-rt5640/rt5640.4-001c/codec_reg 2012-11-07 17:02:23.000000000 +0100
>@@ -64,9 +64,9 @@
>-008e: 0004
>+008e: 0084


>-0090: 0646
>+0090: 0636


These two registers seem to be involved with headphone plug-unplug. But we have no sound from speaker either, so...?

>-00bf: 0100
>+00bf: 0180


This register is never set in code, nor is its individual bits documented.

>-00c4: 0025
>+00c4: 3fd2


>-00c6: 2000
>+00c6: 253b


"The DSP can be controlled through DSP command format (0xfc), addr (0xc4), data (0xc5) and cmd (0xc6) register.". As far as I know, we don't use the DSP. But I might be wrong.

>-00fc: 0000
>+00fc: 00e0


Despite its name, this register seems also related to the DSP.

David Henningsson (diwic) wrote :

Other things tried so far, without success:

 * Locking the sample rate to 44100 in PulseAudio.

 * Manually calling Tegra and/or rt5640 supsend/resume code, even though the system is not preparing for real S3.

Changed in ubuntu-nexus7:
assignee: David Henningsson (diwic) → Alex Chiang (achiang)
David Henningsson (diwic) wrote :

No news?

Robert Bruce Park (robru) wrote :

I can still reproduce this with a fully-updated raring image on my nexus (fully updated as of yesterday anyway).

I will try to check on our Linux for Tegra platform and try to repo the same.

David Henningsson (diwic) wrote :

@kpurandare, thank you very much, let me know if you need any assistance.

jbert (jjberthels) wrote :

Can confirm this is still a problem, after update to latest kernel today. I'm trying to use a nexus7 with a cracked screen as a DLNA renderer. I have a 3.5mm stereo jack connected to audio in on an amp.

For me, running pm-suspend after a boot works, as long as I also press volume_up or volume_down. If I fail to do these two steps, no sound is heard. If I do both, I get sound reliably, so 100% reproducible for problem and fix.

Please let me know if there is any relevant debug info to provide.

Jani Monoses (jani) wrote :

For me it works after running pm-suspend but I don't need to press the volume buttons or adjust the volume in any way.
via ssh:

$sudo pm-suspend
$export DISPLAY=:0
$canberra-gtk-play --file=/usr/share/sounds/gnome/default/alerts/glass.ogg

Jani Monoses (jani) wrote :

The problem seems to go away if we build in the INTEL_HDA_TEGRA support (just like Android and we had it originally).
I'll send a patch to the kernel team.
The consequence is HDA - even if unused on this board - will be card0 and the Realtek codec will be card1 so some ALSA configs files may need to change if they assume a single card.

Jani Monoses (jani) on 2013-01-24
Changed in ubuntu-nexus7:
status: Confirmed → In Progress

We could ship a module configuration file in the nexus7 defaults for ALSA to force the HDA card to a lower index, thereby making sure the SoC card gets slot 0. Once a new kernel is released, I'll chase this up.

David Henningsson (diwic) wrote :

@jani, very interesting, thanks for the finding! Very weird though; they should not affect each other - the HDA card, that cannot be used since we don't have a HDMI port, should be a completely different sound card/system.

Luke's fix is probably a good thing to do, however, for PulseAudio based applications it does not matter. I could make a quirk to make PulseAudio ignore it if it shows up.

Jani Monoses (jani) wrote :

@David, I am guilty of bad science.
While I got it working with the modified kernel (and I think reverting to one without HDA made the problem reappear), after feedback from ogra and Tessadar on IRC who did not see improvement with my kernel I could then have working sound even with the stock kernel. So it must be something else I had changed as I now.
What besides alsa store output would be necessary to make sure I snapshot my full current sound related config to try having it reproduced on someone else's tablet?

Jani Monoses (jani) wrote :

The result of sudo alsactl store on a tablet that has working sound without pm-suspend
I use the canberra-gtk player as in my previous tests, where I needed pm-suspend and volume settings first.

Luke Yelavich (themuso) wrote :

Jani's pastebin as well as looking at David's pulse config files for the Nexus got me on the right track to getting audio working without suspending, as this afternoon I have managed to get audio working using pure ALSA and no pulseaudio, from a fresh init of the mixer, i.e no saved state from either ALSA or pulse.

i am pretty sure this bug is purely to do with something in userspace, but I am yet to determine what, and where.

I'll continue pursuing this on Monday, and feel I could have a fix by EOD Monday or early next week given what I've already discovered.

Changed in ubuntu-nexus7:
assignee: Alex Chiang (achiang) → Luke Yelavich (themuso)
Jani Monoses (jani) wrote :

I just freshly reinstalled the Jan 31 image.
Sound worked on the first boot if I pressed the volume button - after the previous install had working sound.
On subsequent boots that is no longer the case.

Luke Yelavich (themuso) wrote :
Download full text (3.5 KiB)

I think the bug may be somewhere in ALSA's mixer restore logic in alsactl, but not sure yet. This is how I got to my theory.

I firstly completely disabled pulseaudio from autospawning, and worked with a pure ALSA test environment to make sure pulse wasn't getting in the way. To disable pulse autospawn, read

After disabling pulse, my procedure was as follows:
1. Delete /var/lib/alsa/asound.state. I also deleted Pulse config files other than client.conf for good measure, although this is probably not strictly necessary. At this point, also make sure pulseaudio is shut down/killed.
2. Place the attached config file in /usr/share/alsa/cards. This file will allow you to use aplay with no extra arguments to hear sound out of the Nexus speaker. (I'll probably include this file in alsa-lib to make sure a pure ALSA environment is available, i.e audio works without needing pulse.)
3. Disable the alsa store upstart job, by moving the file out of the way. The job you want is /etc/init/alsa-store.conf.
4. Reboot, and attempt to play a wav file with the aplay command. You will find a few wav files in /usr/share/sounds/alsa. You should hear nothing.
5. Open alsamixer, find the "int spk" control, and turn it on."
6. Play a file again with aplay, you should hear something.
7. As root, manually run "alsactl store", and reboot.
8. Once rebooted, try playing a file with aplay again, and you shouldn't hear anything.

After step 6, I took a snapshot of the mixer into a file with "amixer contents", and again after step 8. Unfortunately, the diff doesn't reveal anything obvious, which is why I suspect some race or something else funky going on with the mixer restore process. As per the above, deleting the state file, and a fresh init of the mixer, and turning on "int spk" gets audio working.

I also took snapshots of the mixer pre-suspend, and post-suspend when again, audio worked fine, and again, nothing obvious shows up.

Here is the diff from first init with int spk turned on, and mixer stored, then after a reboot:
--- mixer-fresh-intspk.txt 2013-02-04 15:52:26.724732002 +1100
+++ mixer-after-store-reboot.txt 2013-02-04 16:13:45.417744002 +1100
@@ -111,7 +111,7 @@
   : values=0
 numid=36,iface=MIXER,name='ADC Switch'
   ; type=BOOLEAN,access=rw------,values=1
- : values=off
+ : values=on
 numid=17,iface=MIXER,name='ADC Capture Switch'
   ; type=BOOLEAN,access=rw------,values=2
   : values=on,on
@@ -170,7 +170,7 @@
   : values=0
 numid=35,iface=MIXER,name='DAC Switch'
   ; type=BOOLEAN,access=rw------,values=1
- : values=off
+ : values=on
 numid=10,iface=MIXER,name='DAC1 Playback Volume'
   ; type=INTEGER,access=rw---R--,values=2,min=0,max=175,step=0
   : values=175,175

And here is the diff between pre-suspend and post-suspend, after the initial mixer store and reboot.
--- mixer-after-store-pre-suspend.txt 2013-02-04 16:31:46.750269002 +1100
+++ mixer-after-store-post-suspend.txt 2013-02-04 16:33:33.111757042 +1100
@@ -513,13 +513,13 @@
   : values=0
 numid=122,iface=MIXER,name='Stereo ADC MIXL ADC1 Switch'
   ; type=BOOLEAN,access=rw------,values=1
- : values=on
+ : values=off


David Henningsson (diwic) wrote :

I thought that I've tried everything mixer wise both forwards and backwards, but maybe I missed something.
Thanks Luke for the research.

I've now tried something simpler: just move the /etc/init/alsa-store.conf away. Do this on your first boot, when sound is still working. This seems to me like it causes the sound to survive a reboot, although sound might be muted (which you can fix either in the sound indicator or with "pactl set-sink-mute @DEFAULT_SINK@ 0").

I know we've had red herrings before, so I'm hesitant to throw a party just yet! So could you others try this as well and see if this makes your audio work?

Oliver Grawert (ogra) wrote :

note that none of the nexus7's i had in my hands to help people installing actually had working sound on first boot.

this seems to be a matter of the android version (or configuration) that was installed before installing ubuntu, we can not rely on the fact that sound works on forst boot for anyone ...

David Henningsson (diwic) wrote :

Ok, then in addition to removing /etc/init/alsa-store.conf, also remove /var/lib/alsa/asound.state. Then reboot.

Oliver Grawert (ogra) wrote :

this workaround works fine here, so putting two .override upstart jobs for alsa-store.conf and alsa-restore.conf into ubuntu-defaults-nexus7 shold help.

Oliver Grawert (ogra) wrote :

i uploaded the workaround, lets leave the ubuntu-nexus7 project task open though since the uploaded fix is only a workaround ...

Changed in ubuntu-defaults-nexus7 (Ubuntu):
status: New → Fix Committed
importance: Undecided → Critical
assignee: nobody → Oliver Grawert (ogra)
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package ubuntu-defaults-nexus7 - 0.51

ubuntu-defaults-nexus7 (0.51) raring; urgency=low

  * add alsa-store and alsa-restore .override files for the upstart jobs as
    a workaround to make sound work on boot without suspend (LP: #1068804)
 -- Oliver Grawert <email address hidden> Mon, 04 Feb 2013 13:53:06 +0100

Changed in ubuntu-defaults-nexus7 (Ubuntu):
status: Fix Committed → Fix Released
David Henningsson (diwic) wrote :

Hmm, I believe I might have found something...the "dangerous" control, which alsa-restore must not restore, is probably the "Register Control" control. It can potentially cause a codec reset in the middle of the initialization.

As such, the attached patch should disable "Register Control", i e, make alsactl store/restore work without disabling audio in the process.
Could you guys who like building kernels test it? Thanks.

Andy Whitcroft (apw) on 2013-02-04
Changed in ubuntu-nexus7:
assignee: Luke Yelavich (themuso) → Andy Whitcroft (apw)
status: In Progress → Fix Committed
assignee: Andy Whitcroft (apw) → nobody
assignee: nobody → David Henningsson (diwic)
Andy Whitcroft (apw) wrote :

Kernel side fixes released as below:

linux-nexus7 (3.1.10-9.26) raring; urgency=low

  [ Andy Whitcroft ]

  * SAUCE: (no-up) quiet down stop_machine when running normally
    - LP: #1113396
  * SAUCE: cpu-tegra3: reduce noise waking and sleeping CPUs
    - LP: #1113396
  * SAUCE: (no-up) quiet CPU start/stop when system running normally
    - LP: #1113396
  * SAUCE: tegra -- quiet cpu start messages when system running normally
    - LP: #1113396

  [ Upstream Kernel Changes ]

  * ASoC: Disable "Register Control" for RT5640
    - LP: #1068804
 -- Andy Whitcroft <email address hidden> Mon, 04 Feb 2013 20:18:24 +0000

Changed in ubuntu-nexus7:
assignee: David Henningsson (diwic) → Luke Yelavich (themuso)
status: Fix Committed → Confirmed
Changed in linux-nexus7 (Ubuntu):
assignee: nobody → David Henningsson (diwic)
importance: Undecided → Medium
status: New → Fix Released

Sound is indded available right after boot, without suspend, but volume is always zero after boot.

Luke Yelavich (themuso) wrote :

Thanks, can confirm this myself. Will chase this down.

Changed in ubuntu-nexus7:
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers