Identify element requesting sound chip to sleep

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?

Solution 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