Identify element requesting sound chip to sleep

Question

Since a few months the sound is suddenly stopping on my laptop after some time. My computer is a Toshiba Satellite L755 with a Conexant CX20585 sound chip, running Ubuntu 17.04.

I found out that this is caused by the sound chip being put to sleep, as explained here.

When the sound is working, reading /proc/asound/card0/codec\#0 shows:

Codec: Conexant CX20585
Address: 0
AFG Function Id: 0x1 (unsol 1)
Vendor Id: 0x14f15069
Subsystem Id: 0x1179fc50
Revision Id: 0x100302
[...]
Node 0x1f [Pin Complex] wcaps 0x400501: Stereo
  Pincap 0x00000010: OUT
  Pin Default 0x92170110: [Fixed] Speaker at Int Front
    Conn = Analog, Color = Unknown
    DefAssociation = 0x1, Sequence = 0x0
    Misc = NO_PRESENCE
  Pin-ctls: 0x40: OUT
  Power states:  D0 D1 D2 D3 D3cold EPSS
  Power: setting=D0, actual=D0

And when the sound is not working, it shows:

Node 0x1f [Pin Complex] wcaps 0x400501: Stereo
  Pincap 0x00000010: OUT
  Pin Default 0x92170110: [Fixed] Speaker at Int Front
    Conn = Analog, Color = Unknown
    DefAssociation = 0x1, Sequence = 0x0
    Misc = NO_PRESENCE
  Pin-ctls: 0x40: OUT
  Power states:  D0 D1 D2 D3 D3cold EPSS
  Power: setting=D3, actual=D3

The node 0x1f being set in the power state D3 is therefore the issue. As I found out in the previous link, I can put it back to the power state D0 with the command sudo hda-verb /dev/snd/hwC0D0 0x1f SET_POWER_STATE 0. The sound is then back, but only for a few minutes.

Tracking the hda events with echo 1 > /sys/kernel/debug/tracing/events/hda/enable shows that no hda event is sent by the sound driver when the sound cuts:

cat /sys/kernel/debug/tracing/trace 
# tracer: nop
#
# entries-in-buffer/entries-written: 20/20   #P:4
#
#                              _-----=> irqs-off
#                             / _----=> need-resched
#                            | / _---=> hardirq/softirq
#                            || / _--=> preempt-depth
#                            ||| /     delay
#           TASK-PID   CPU#  ||||    TIMESTAMP  FUNCTION
#              | |       |   ||||       |         |
 alsa-sink-CX205-2584  [001] d...   240.469929: snd_hdac_stream_stop: stream_tag: 5
        hda-verb-3617  [003] ....   257.329599: hda_send_cmd: [0000:00:1b.0:0] val=0x01f70500
        hda-verb-3617  [003] ....   257.329672: hda_get_response: [0000:00:1b.0:0] val=0x00000000
 alsa-sink-CX205-2584  [001] ....   279.844834: hda_send_cmd: [0000:00:1b.0:0] val=0x010a0000
 alsa-sink-CX205-2584  [001] ....   279.844888: hda_get_response: [0000:00:1b.0:0] val=0x00004011
 alsa-sink-CX205-2584  [001] ....   279.855672: hda_send_cmd: [0000:00:1b.0:0] val=0x01020011
 alsa-sink-CX205-2584  [001] ....   279.855722: hda_get_response: [0000:00:1b.0:0] val=0x00000000
 alsa-sink-CX205-2584  [001] ....   279.855725: hda_send_cmd: [0000:00:1b.0:0] val=0x011a0000
 alsa-sink-CX205-2584  [001] ....   279.855758: hda_get_response: [0000:00:1b.0:0] val=0x00004011
 alsa-sink-CX205-2584  [001] ....   279.867648: hda_send_cmd: [0000:00:1b.0:0] val=0x01120011
 alsa-sink-CX205-2584  [001] ....   279.867701: hda_get_response: [0000:00:1b.0:0] val=0x00000000
 alsa-sink-CX205-2584  [001] d...   279.867829: snd_hdac_stream_start: stream_tag: 5
 alsa-sink-CX205-2584  [001] d...   297.821668: snd_hdac_stream_stop: stream_tag: 5
[Set sound on with hda-verb]
        hda-verb-3649  [002] ....   300.602038: hda_send_cmd: [0000:00:1b.0:0] val=0x01f70500
        hda-verb-3649  [002] ....   300.602087: hda_get_response: [0000:00:1b.0:0] val=0x00000000
[Start/stop a Youtube video]
 alsa-sink-CX205-2584  [001] d...   312.264676: snd_hdac_stream_start: stream_tag: 5
 alsa-sink-CX205-2584  [001] d...   376.447668: snd_hdac_stream_stop: stream_tag: 5
 alsa-sink-CX205-2584  [001] d...   389.212522: snd_hdac_stream_start: stream_tag: 5
 alsa-sink-CX205-2584  [001] d...   405.072648: snd_hdac_stream_stop: stream_tag: 5
 alsa-sink-CX205-2584  [001] d...   410.938035: snd_hdac_stream_start: stream_tag: 5
[Sound cuts]

I tried to boot with the kernel option "acpi=off" in order to check if ACPI had a role in this issue, as this bug suggested that it might be caused by an over-aggressive power management. But the sound still cuts after some time without ACPI.

The sound chip is therefore put to sleep by another element that I'm not able to find, only by changing the power state of a pin. Any idea how I could identify it? Could it be the BIOS?

I got the information to complete my answer. Hopefully it helps. The heat sink is supposed to be the better fix... — heynnema, May 07 '17 at 22:37
I had read that this is a overheating issue, but I don't think this is the real cause. My computer has a dual boot with Windows 7, and using Windows I can listen to music as long as I want: the sound is never cut.
That's why I think that Ubuntu is somehow cutting the sound, and I hope to be able to identify the component doing it. — dohseven, May 10 '17 at 11:36
If you're able to isolate it to something else, I'd love to hear about it. — heynnema, May 10 '17 at 14:13

heynnema · Answer 1 · 2017-05-07T22:36:31.270

1

This is actually because the sound chip overheats.

A proper hardware fix would attach a small heat sink to the sound chip.

There is a software poke for the chip that delays the overheating. I put the command into my sister's Toshiba Satellite's /etc/rc.local. I'll have to contact her to get the command as I don't recall it from memory. I'll update this answer as soon as I have the details.

Update:

# turn on power management for audio codec
# to solve loosing sound after a few minutes
echo "1" > /sys/module/snd_hda_intel/parameters/power_save

edited May 07 '17 at 22:36

answered May 07 '17 at 21:46

heynnema

70,711

I tried your option and several others, but sadly none really works in my case: power_save=1, power_save=10, or even power_save=10 power_save_controller=N.
(Instead of putting it in /etc/rc.local, I just edited the /etc/modprobe.d/alsa-base.conf file by adding options snd-hda-intel power_save=10 power_save_controller=N at the end, and rebooted each time)
– dohseven May 08 '17 at 14:01
Why don't you re-try it the way that I've suggested, and see if that works for you? Otherwise, consider the hardware fix. – heynnema May 08 '17 at 14:16
I double-checked it: putting options snd-hda-intel power_save=1 in /etc/modprobe.d/alsa-base.conf does the same thing as echo "1" > /sys/module/snd_hda_intel/parameters/power_save. In both case reading /sys/module/snd_hda_intel/parameters/power_save gives 1. – dohseven May 08 '17 at 14:44

Identify element requesting sound chip to sleep

1 Answers1

Linked