sound only works after suspend/resume cycle

Hi!

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.
https://launchpad.net/~diwic

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!

--chris

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

After a reboot, sound no longer works.

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

This is as of the 20121020-1 build.

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

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

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[0] = 04070000
>+TEGRA30_AHUB_CHANNEL_STATUS[0] = 05010000
> TEGRA30_AHUB_CHANNEL_STATUS[1] = 08080000
> TEGRA30_AHUB_CHANNEL_STATUS[2] = 08080000
> TEGRA30_AHUB_CHANNEL_STATUS[3] = 08080000

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_CONFIG_LINK_CTRL = 08008000
> TEGRA30_AHUB_MISC_CTRL = 80000000
> TEGRA30_AHUB_APBDMA_LIVE_STATUS = 01fe02fc
>-TEGRA30_AHUB_I2S_LIVE_STATUS = 000033f3
>+TEGRA30_AHUB_I2S_LIVE_STATUS = 000033fb
> 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_SPDIF_INT_MASK = 00008fff
> TEGRA30_AHUB_APBIF_INT_MASK = 0001ffff
>-TEGRA30_AHUB_I2S_INT_STATUS = 0000000c
>+TEGRA30_AHUB_I2S_INT_STATUS = 00000004
> TEGRA30_AHUB_DAM_INT_STATUS = 00808080
> TEGRA30_AHUB_SPDIF_INT_STATUS = 00000000
> TEGRA30_AHUB_APBIF_INT_STATUS = 00000002

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_CLIP_THRESHOLD = 007fff00
> TEGRA30_DAM_AUDIOCIF_OUT_CTRL = 00001100
>-TEGRA30_DAM_CH0_CTRL = 12e20300
>-TEGRA30_DAM_CH0_CONV = 000038af
>+TEGRA30_DAM_CH0_CTRL = 52e00300
>+TEGRA30_DAM_CH0_CONV = 000034bd
> TEGRA30_DAM_AUDIOCIF_CH0_CTRL = 00001104
> TEGRA30_DAM_CH1_CTRL = 00000010
>-TEGRA30_DAM_CH1_CONV = 0000e565
>+TEGRA30_DAM_CH1_CONV = 0000e145
> TEGRA30_DAM_AUDIOCIF_CH1_CTRL = 00001104

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_CLIP_THRESHOLD = 007fff00
> TEGRA30_DAM_AUDIOCIF_OUT_CTRL = 00001100
>-TEGRA30_DAM_CH0_CTRL = 55cd0800
>-TEGRA...

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

RT5640_DEPOP_M1

>-0090: 0646
>+0090: 0636

RT5640_DEPOP_M3

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

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

RT5640_INT_IRQ_ST

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

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

RT5640_DSP_CTRL1

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

RT5640_DSP_CTRL3

"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

RT5640_DUMMY3

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

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.

No news?

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.

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

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.

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

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.

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.

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

@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?

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.

http://paste.ubuntu.com/1580862/

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.

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.

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 https://wiki.ubuntu.com/PulseAudio/Log.

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
 numid=123,iface=MIXER,...

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?

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

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

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.

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

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

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.

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

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

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