ALSA: Conexant CX20585 (thinkpad t510) speaker powersave regression

ALSA: Conexant CX20585 (thinkpad t510) speaker powersave regression

[Kevin Fenzi]

[-- Attachment #1: Type: text/plain, Size: 936 bytes --]

Greetings. 

I've got an issue with sound on my t510. It started in the late 3.4.x
kernels. Sound works on boot and for 5-10min after, then the speakers
stop working at all. 

I posted a while back on the alsa-users list, and someone else had the
same issue: 

http://www.mail-archive.com/alsa-user@lists.sourceforge.net/msg28769.html

It seems that the speakers(?) are getting moved to state D3 and turning
off. You can manually get it to come back for a few minutes by using
hda-verb to move it back to D0: 

hda-verb /dev/snd/hwC0D0 0x1f SET_POWER_STATE 0

http://www.alsa-project.org/db/?f=fd5ca157b2e76942df5ce2f0ae1a2817f3f08afd
is my alsa-info. 

I'd file a bug on the alsa bug tracker, but it still seems to be down
(for many months now?). No response on alsa-users, so now that I have a
bit of time, I am posting here in hopes someone can look. ;) 

Happy to provide more info or try things. 

kevin

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: ALSA: Conexant CX20585 (thinkpad t510) speaker powersave regression

[Takashi Iwai]

At Sat, 22 Dec 2012 14:23:24 -0700,
Kevin Fenzi wrote:
> 
> Greetings. 
> 
> I've got an issue with sound on my t510. It started in the late 3.4.x
> kernels. Sound works on boot and for 5-10min after, then the speakers
> stop working at all. 
> 
> I posted a while back on the alsa-users list, and someone else had the
> same issue: 
> 
> http://www.mail-archive.com/alsa-user@lists.sourceforge.net/msg28769.html
> 
> It seems that the speakers(?) are getting moved to state D3 and turning
> off. You can manually get it to come back for a few minutes by using
> hda-verb to move it back to D0: 
> 
> hda-verb /dev/snd/hwC0D0 0x1f SET_POWER_STATE 0
> 
> http://www.alsa-project.org/db/?f=fd5ca157b2e76942df5ce2f0ae1a2817f3f08afd
> is my alsa-info. 
> 
> I'd file a bug on the alsa bug tracker, but it still seems to be down
> (for many months now?). No response on alsa-users, so now that I have a
> bit of time, I am posting here in hopes someone can look. ;) 
> 
> Happy to provide more info or try things. 

It's a known problem that some people have already reported, but
currently no clue who actually turns down the pin to D3.
Conexant guys wrote me that the codec doesn't do it by itself, and the
driver neither, AFAIK.  A possible answer is the firmware / BIOS, but
who knows.

In anyway, could you try to trace the hd-audio events and see whether
the power down is *not* issued by the driver when you see this state?
See Documentation/sound/alsa/HD-Audio.txt, the section "Tracepoints"
for a brief instruction.


thanks,

Takashi

Re: ALSA: Conexant CX20585 (thinkpad t510) speaker powersave regression

[Kevin Fenzi]

[-- Attachment #1: Type: text/plain, Size: 678 bytes --]

On Tue, 08 Jan 2013 16:26:38 +0100
Takashi Iwai <tiwai@suse.de> wrote:

> It's a known problem that some people have already reported, but
> currently no clue who actually turns down the pin to D3.
> Conexant guys wrote me that the codec doesn't do it by itself, and the
> driver neither, AFAIK.  A possible answer is the firmware / BIOS, but
> who knows.

Thanks for the answer! :) 

> In anyway, could you try to trace the hd-audio events and see whether
> the power down is *not* issued by the driver when you see this state?
> See Documentation/sound/alsa/HD-Audio.txt, the section "Tracepoints"
> for a brief instruction.

I can give it a try... 

kevin

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: ALSA: Conexant CX20585 (thinkpad t510) speaker powersave regression

[Kevin Fenzi]

[-- Attachment #1: Type: text/plain, Size: 3603 bytes --]

On Tue, 08 Jan 2013 16:26:38 +0100
Takashi Iwai <tiwai@suse.de> wrote:

> At Sat, 22 Dec 2012 14:23:24 -0700,
> Kevin Fenzi wrote:
> > 
> > Greetings. 
> > 
> > I've got an issue with sound on my t510. It started in the late
> > 3.4.x kernels. Sound works on boot and for 5-10min after, then the
> > speakers stop working at all. 
> > 
> > I posted a while back on the alsa-users list, and someone else had
> > the same issue: 
> > 
> > http://www.mail-archive.com/alsa-user@lists.sourceforge.net/msg28769.html
> > 
> > It seems that the speakers(?) are getting moved to state D3 and
> > turning off. You can manually get it to come back for a few minutes
> > by using hda-verb to move it back to D0: 
> > 
> > hda-verb /dev/snd/hwC0D0 0x1f SET_POWER_STATE 0
> > 
> > http://www.alsa-project.org/db/?f=fd5ca157b2e76942df5ce2f0ae1a2817f3f08afd
> > is my alsa-info. 
> > 
> > I'd file a bug on the alsa bug tracker, but it still seems to be
> > down (for many months now?). No response on alsa-users, so now that
> > I have a bit of time, I am posting here in hopes someone can
> > look. ;) 
> > 
> > Happy to provide more info or try things. 
> 
> It's a known problem that some people have already reported, but
> currently no clue who actually turns down the pin to D3.
> Conexant guys wrote me that the codec doesn't do it by itself, and the
> driver neither, AFAIK.  A possible answer is the firmware / BIOS, but
> who knows.
> 
> In anyway, could you try to trace the hd-audio events and see whether
> the power down is *not* issued by the driver when you see this state?
> See Documentation/sound/alsa/HD-Audio.txt, the section "Tracepoints"
> for a brief instruction.

ok. I am not sure I am doing the right thing, but: 

- echo 1 > /sys/kernel/debug/tracing/events/hda/enable
- Run hda-verb to get sound working. 
- Play a video to confirm. 
- check /sys/kernel/debug/tracing/trace
- Wait a while. 
- Play another sound that doesn't come out of speakers. 
- check /sys/kernel/debug/tracing/trace for anything new. 

The only things I see in the trace file are my hda-verb call, and the
sounds playing. Nothing else. 

I then tried to duplicate it, but the trace file didn't seem to update
properly. Is there some reset needed? 

Or is this not the info you were looking for?

        hda-verb-27187 [001] .... 78907.305149: hda_power_count: [0:0]
        power_count=1, power_on=1, power_transition=0
        hda-verb-27187 [001] .... 78907.305152: hda_send_cmd: [0:0]
        val=1f70500
        hda-verb-27187 [001] .... 78907.305214: hda_get_response: [0:0]
        val=0
        hda-verb-27187 [001] .... 78907.305214: hda_power_count: [0:0]
        power_count=0, power_on=1, power_transition=0
       alsa-sink-17958 [000] .... 78933.682478: hda_power_count: [0:0]
        power_count=1, power_on=1, power_transition=0
       alsa-sink-17958 [000] .... 78933.683330: hda_power_count: [0:0]
        power_count=2, power_on=1, power_transition=0
       alsa-sink-17958 [000] .... 78933.683335: hda_power_count: [0:0]
        power_count=3, power_on=1, power_transition=0
       alsa-sink-17958 [000] .... 78933.683336: hda_send_cmd: [0:0]
        val=103a047
       alsa-sink-17958 [000] .... 78933.683378: hda_get_response: [0:0]
        val=0
       alsa-sink-17958 [000] .... 78933.683379: hda_power_count: [0:0]
        power_count=2, power_on=1, power_transition=0
       alsa-sink-17958 [000] .... 78933.683380: hda_power_count: [0:0]
       power_count=3, power_on=1, power_transition=0
...

kevin

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: ALSA: Conexant CX20585 (thinkpad t510) speaker powersave regression

[Takashi Iwai]

At Sat, 12 Jan 2013 11:40:24 -0700,
Kevin Fenzi wrote:
> 
> On Tue, 08 Jan 2013 16:26:38 +0100
> Takashi Iwai <tiwai@suse.de> wrote:
> 
> > At Sat, 22 Dec 2012 14:23:24 -0700,
> > Kevin Fenzi wrote:
> > > 
> > > Greetings. 
> > > 
> > > I've got an issue with sound on my t510. It started in the late
> > > 3.4.x kernels. Sound works on boot and for 5-10min after, then the
> > > speakers stop working at all. 
> > > 
> > > I posted a while back on the alsa-users list, and someone else had
> > > the same issue: 
> > > 
> > > http://www.mail-archive.com/alsa-user@lists.sourceforge.net/msg28769.html
> > > 
> > > It seems that the speakers(?) are getting moved to state D3 and
> > > turning off. You can manually get it to come back for a few minutes
> > > by using hda-verb to move it back to D0: 
> > > 
> > > hda-verb /dev/snd/hwC0D0 0x1f SET_POWER_STATE 0
> > > 
> > > http://www.alsa-project.org/db/?f=fd5ca157b2e76942df5ce2f0ae1a2817f3f08afd
> > > is my alsa-info. 
> > > 
> > > I'd file a bug on the alsa bug tracker, but it still seems to be
> > > down (for many months now?). No response on alsa-users, so now that
> > > I have a bit of time, I am posting here in hopes someone can
> > > look. ;) 
> > > 
> > > Happy to provide more info or try things. 
> > 
> > It's a known problem that some people have already reported, but
> > currently no clue who actually turns down the pin to D3.
> > Conexant guys wrote me that the codec doesn't do it by itself, and the
> > driver neither, AFAIK.  A possible answer is the firmware / BIOS, but
> > who knows.
> > 
> > In anyway, could you try to trace the hd-audio events and see whether
> > the power down is *not* issued by the driver when you see this state?
> > See Documentation/sound/alsa/HD-Audio.txt, the section "Tracepoints"
> > for a brief instruction.
> 
> ok. I am not sure I am doing the right thing, but: 
> 
> - echo 1 > /sys/kernel/debug/tracing/events/hda/enable
> - Run hda-verb to get sound working. 
> - Play a video to confirm. 
> - check /sys/kernel/debug/tracing/trace
> - Wait a while. 
> - Play another sound that doesn't come out of speakers. 
> - check /sys/kernel/debug/tracing/trace for anything new. 
> 
> The only things I see in the trace file are my hda-verb call, and the
> sounds playing. Nothing else. 
> 
> I then tried to duplicate it, but the trace file didn't seem to update
> properly. Is there some reset needed? 
> 
> Or is this not the info you were looking for?
> 
>         hda-verb-27187 [001] .... 78907.305149: hda_power_count: [0:0]
>         power_count=1, power_on=1, power_transition=0
>         hda-verb-27187 [001] .... 78907.305152: hda_send_cmd: [0:0]
>         val=1f70500

Yes these are what I'd like to check.

The point to check here is exactly which verbs have been sent, and how
is the codec power status.  Check what is the last power_on value when
the problem appears.  If it's power_on=1, it's fine.
And you can concentrate on the verb to NID 0x1f, namely, hda_send_cmd
with a value 1fxxxxx.  In the example above, 1f70500 means it's
setting the power state of 0x1f to D0.

Last but not least, you can try my very latest code in sound-unstable
tree:
  git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-unstable.git

Either master or test/hda-migrate branch contains the latest code for
Conexant codecs.


thanks,

Takashi

Re: ALSA: Conexant CX20585 (thinkpad t510) speaker powersave regression

[Kevin Fenzi]

[-- Attachment #1: Type: text/plain, Size: 3866 bytes --]

On Sun, 13 Jan 2013 10:06:41 +0100
Takashi Iwai <tiwai@suse.de> wrote:

> At Sat, 12 Jan 2013 11:40:24 -0700,
> Kevin Fenzi wrote:
> > 
> > On Tue, 08 Jan 2013 16:26:38 +0100
> > Takashi Iwai <tiwai@suse.de> wrote:
> > 
> > > At Sat, 22 Dec 2012 14:23:24 -0700,
> > > Kevin Fenzi wrote:
> > > > 
> > > > Greetings. 
> > > > 
> > > > I've got an issue with sound on my t510. It started in the late
> > > > 3.4.x kernels. Sound works on boot and for 5-10min after, then
> > > > the speakers stop working at all. 
> > > > 
> > > > I posted a while back on the alsa-users list, and someone else
> > > > had the same issue: 
> > > > 
> > > > http://www.mail-archive.com/alsa-user@lists.sourceforge.net/msg28769.html
> > > > 
> > > > It seems that the speakers(?) are getting moved to state D3 and
> > > > turning off. You can manually get it to come back for a few
> > > > minutes by using hda-verb to move it back to D0: 
> > > > 
> > > > hda-verb /dev/snd/hwC0D0 0x1f SET_POWER_STATE 0
> > > > 
> > > > http://www.alsa-project.org/db/?f=fd5ca157b2e76942df5ce2f0ae1a2817f3f08afd
> > > > is my alsa-info. 
> > > > 
> > > > I'd file a bug on the alsa bug tracker, but it still seems to be
> > > > down (for many months now?). No response on alsa-users, so now
> > > > that I have a bit of time, I am posting here in hopes someone
> > > > can look. ;) 
> > > > 
> > > > Happy to provide more info or try things. 
> > > 
> > > It's a known problem that some people have already reported, but
> > > currently no clue who actually turns down the pin to D3.
> > > Conexant guys wrote me that the codec doesn't do it by itself,
> > > and the driver neither, AFAIK.  A possible answer is the
> > > firmware / BIOS, but who knows.
> > > 
> > > In anyway, could you try to trace the hd-audio events and see
> > > whether the power down is *not* issued by the driver when you see
> > > this state? See Documentation/sound/alsa/HD-Audio.txt, the
> > > section "Tracepoints" for a brief instruction.
> > 
> > ok. I am not sure I am doing the right thing, but: 
> > 
> > - echo 1 > /sys/kernel/debug/tracing/events/hda/enable
> > - Run hda-verb to get sound working. 
> > - Play a video to confirm. 
> > - check /sys/kernel/debug/tracing/trace
> > - Wait a while. 
> > - Play another sound that doesn't come out of speakers. 
> > - check /sys/kernel/debug/tracing/trace for anything new. 
> > 
> > The only things I see in the trace file are my hda-verb call, and
> > the sounds playing. Nothing else. 
> > 
> > I then tried to duplicate it, but the trace file didn't seem to
> > update properly. Is there some reset needed? 
> > 
> > Or is this not the info you were looking for?
> > 
> >         hda-verb-27187 [001] .... 78907.305149: hda_power_count:
> > [0:0] power_count=1, power_on=1, power_transition=0
> >         hda-verb-27187 [001] .... 78907.305152: hda_send_cmd: [0:0]
> >         val=1f70500
> 
> Yes these are what I'd like to check.

Sorry for the long delay here... was the above info of any use? 

> The point to check here is exactly which verbs have been sent, and how
> is the codec power status.  Check what is the last power_on value when
> the problem appears.  If it's power_on=1, it's fine.
> And you can concentrate on the verb to NID 0x1f, namely, hda_send_cmd
> with a value 1fxxxxx.  In the example above, 1f70500 means it's
> setting the power state of 0x1f to D0.
> 
> Last but not least, you can try my very latest code in sound-unstable
> tree:
>   git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-unstable.git
> 
> Either master or test/hda-migrate branch contains the latest code for
> Conexant codecs.

I'll note that the problem persists in 3.9.0-0.rc1

Please let me know if there's anything I can do to move this along or
try. ;( 

kevin

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: ALSA: Conexant CX20585 (thinkpad t510) speaker powersave regression

[Takashi Iwai]

At Sun, 10 Mar 2013 11:44:02 -0600,
Kevin Fenzi wrote:
> 
> On Sun, 13 Jan 2013 10:06:41 +0100
> Takashi Iwai <tiwai@suse.de> wrote:
> 
> > At Sat, 12 Jan 2013 11:40:24 -0700,
> > Kevin Fenzi wrote:
> > > 
> > > On Tue, 08 Jan 2013 16:26:38 +0100
> > > Takashi Iwai <tiwai@suse.de> wrote:
> > > 
> > > > At Sat, 22 Dec 2012 14:23:24 -0700,
> > > > Kevin Fenzi wrote:
> > > > > 
> > > > > Greetings. 
> > > > > 
> > > > > I've got an issue with sound on my t510. It started in the late
> > > > > 3.4.x kernels. Sound works on boot and for 5-10min after, then
> > > > > the speakers stop working at all. 
> > > > > 
> > > > > I posted a while back on the alsa-users list, and someone else
> > > > > had the same issue: 
> > > > > 
> > > > > http://www.mail-archive.com/alsa-user@lists.sourceforge.net/msg28769.html
> > > > > 
> > > > > It seems that the speakers(?) are getting moved to state D3 and
> > > > > turning off. You can manually get it to come back for a few
> > > > > minutes by using hda-verb to move it back to D0: 
> > > > > 
> > > > > hda-verb /dev/snd/hwC0D0 0x1f SET_POWER_STATE 0
> > > > > 
> > > > > http://www.alsa-project.org/db/?f=fd5ca157b2e76942df5ce2f0ae1a2817f3f08afd
> > > > > is my alsa-info. 
> > > > > 
> > > > > I'd file a bug on the alsa bug tracker, but it still seems to be
> > > > > down (for many months now?). No response on alsa-users, so now
> > > > > that I have a bit of time, I am posting here in hopes someone
> > > > > can look. ;) 
> > > > > 
> > > > > Happy to provide more info or try things. 
> > > > 
> > > > It's a known problem that some people have already reported, but
> > > > currently no clue who actually turns down the pin to D3.
> > > > Conexant guys wrote me that the codec doesn't do it by itself,
> > > > and the driver neither, AFAIK.  A possible answer is the
> > > > firmware / BIOS, but who knows.
> > > > 
> > > > In anyway, could you try to trace the hd-audio events and see
> > > > whether the power down is *not* issued by the driver when you see
> > > > this state? See Documentation/sound/alsa/HD-Audio.txt, the
> > > > section "Tracepoints" for a brief instruction.
> > > 
> > > ok. I am not sure I am doing the right thing, but: 
> > > 
> > > - echo 1 > /sys/kernel/debug/tracing/events/hda/enable
> > > - Run hda-verb to get sound working. 
> > > - Play a video to confirm. 
> > > - check /sys/kernel/debug/tracing/trace
> > > - Wait a while. 
> > > - Play another sound that doesn't come out of speakers. 
> > > - check /sys/kernel/debug/tracing/trace for anything new. 
> > > 
> > > The only things I see in the trace file are my hda-verb call, and
> > > the sounds playing. Nothing else. 
> > > 
> > > I then tried to duplicate it, but the trace file didn't seem to
> > > update properly. Is there some reset needed? 
> > > 
> > > Or is this not the info you were looking for?
> > > 
> > >         hda-verb-27187 [001] .... 78907.305149: hda_power_count:
> > > [0:0] power_count=1, power_on=1, power_transition=0
> > >         hda-verb-27187 [001] .... 78907.305152: hda_send_cmd: [0:0]
> > >         val=1f70500
> > 
> > Yes these are what I'd like to check.
> 
> Sorry for the long delay here... was the above info of any use? 

These lines alone don't.  Please check what I had wrote in below.

> > The point to check here is exactly which verbs have been sent, and how
> > is the codec power status.  Check what is the last power_on value when
> > the problem appears.  If it's power_on=1, it's fine.
> > And you can concentrate on the verb to NID 0x1f, namely, hda_send_cmd
> > with a value 1fxxxxx.  In the example above, 1f70500 means it's
> > setting the power state of 0x1f to D0.


thanks,

Takashi

Re: ALSA: Conexant CX20585 (thinkpad t510) speaker powersave regression

[Takashi Iwai]

At Thu, 11 Jul 2013 23:42:27 -0500,
Jason Schindler wrote:
> 
> I'm attempting to jump into the thread from here:
> 
> http://markmail.org/message/zqbhcuc2gnxji3s7
> 
> I'm experiencing the same issue as described in the thread.  I'm
> currently running kernel 3.9.6, but have had the issue for some time.
> 
> I attempted to go through the debugging requested by Takashi Iwai on Jan 13.
> 
> Immediately after issuing the "hda-verb /dev/snd/hwC0D0 0x1f
> SET_POWER_STATE 0" command, here is the trace output:
> 
> # tracer: nop
> #
> # entries-in-buffer/entries-written: 8/8   #P:4
> #
> #                              _-----=> irqs-off
> #                             / _----=> need-resched
> #                            | / _---=> hardirq/softirq
> #                            || / _--=> preempt-depth
> #                            ||| /     delay
> #           TASK-PID   CPU#  ||||    TIMESTAMP  FUNCTION
> #              | |       |   ||||       |         |
>         hda-verb-14066 [001] .... 90509.001737: hda_power_count: [0:0]
> power_count=2, power_on=1, power_transition=0
>         hda-verb-14066 [001] .... 90509.001740: hda_send_cmd: [0:0] val=1f70500
>         hda-verb-14066 [001] .... 90509.001814: hda_get_response: [0:0] val=0
>         hda-verb-14066 [001] .... 90509.001814: hda_power_count: [0:0]
> power_count=1, power_on=1, power_transition=0
>         hda-verb-14122 [003] .... 90712.799801: hda_power_count: [0:0]
> power_count=2, power_on=1, power_transition=0
>         hda-verb-14122 [003] .... 90712.799804: hda_send_cmd: [0:0] val=1f70500
>         hda-verb-14122 [003] .... 90712.799880: hda_get_response: [0:0] val=0
>         hda-verb-14122 [003] .... 90712.799881: hda_power_count: [0:0]
> power_count=1, power_on=1, power_transition=0
> 
> When the speakers stop, here is the output:
> 
> # tracer: nop
> #
> # entries-in-buffer/entries-
> written: 8/8   #P:4
> #
> #                              _-----=> irqs-off
> #                             / _----=> need-resched
> #                            | / _---=> hardirq/softirq
> #                            || / _--=> preempt-depth
> #                            ||| /     delay
> #           TASK-PID   CPU#  ||||    TIMESTAMP  FUNCTION
> #              | |       |   ||||       |         |
>         hda-verb-14066 [001] .... 90509.001737: hda_power_count: [0:0]
> power_count=2, power_on=1, power_transition=0
>         hda-verb-14066 [001] .... 90509.001740: hda_send_cmd: [0:0] val=1f70500
>         hda-verb-14066 [001] .... 90509.001814: hda_get_response: [0:0] val=0
>         hda-verb-14066 [001] .... 90509.001814: hda_power_count: [0:0]
> power_count=1, power_on=1, power_transition=0
>         hda-verb-14122 [003] .... 90712.799801: hda_power_count: [0:0]
> power_count=2, power_on=1, power_transition=0
>         hda-verb-14122 [003] .... 90712.799804: hda_send_cmd: [0:0] val=1f70500
>         hda-verb-14122 [003] .... 90712.799880: hda_get_response: [0:0] val=0
>         hda-verb-14122 [003] .... 90712.799881: hda_power_count: [0:0]
> power_count=1, power_on=1, power_transition=0
> 
> I'm a bit out of my element here, if I've missed a crucial step,
> please let me know.

Well, there is no difference in the traces above.

Actually, after talking with Conexant guys, we concluded that this
problem doesn't seem to be an issue of the Conexant codec at all, but
rather Lenovo's firmware who powers down the speaker.  Maybe some
thermal or power condition triggers it.

So, if it's a regression in the kernel, you should check whether ACPI
or whatever else change influences on the behavior, not only the sound
driver change.


Takashi

Re: ALSA: Conexant CX20585 (thinkpad t510) speaker powersave regression

[Jason Schindler]

I'm attempting to jump into the thread from here:

http://markmail.org/message/zqbhcuc2gnxji3s7

I'm experiencing the same issue as described in the thread.  I'm
currently running kernel 3.9.6, but have had the issue for some time.

I attempted to go through the debugging requested by Takashi Iwai on Jan 13.

Immediately after issuing the "hda-verb /dev/snd/hwC0D0 0x1f
SET_POWER_STATE 0" command, here is the trace output:

# tracer: nop
#
# entries-in-buffer/entries-written: 8/8   #P:4
#
#                              _-----=> irqs-off
#                             / _----=> need-resched
#                            | / _---=> hardirq/softirq
#                            || / _--=> preempt-depth
#                            ||| /     delay
#           TASK-PID   CPU#  ||||    TIMESTAMP  FUNCTION
#              | |       |   ||||       |         |
        hda-verb-14066 [001] .... 90509.001737: hda_power_count: [0:0]
power_count=2, power_on=1, power_transition=0
        hda-verb-14066 [001] .... 90509.001740: hda_send_cmd: [0:0] val=1f70500
        hda-verb-14066 [001] .... 90509.001814: hda_get_response: [0:0] val=0
        hda-verb-14066 [001] .... 90509.001814: hda_power_count: [0:0]
power_count=1, power_on=1, power_transition=0
        hda-verb-14122 [003] .... 90712.799801: hda_power_count: [0:0]
power_count=2, power_on=1, power_transition=0
        hda-verb-14122 [003] .... 90712.799804: hda_send_cmd: [0:0] val=1f70500
        hda-verb-14122 [003] .... 90712.799880: hda_get_response: [0:0] val=0
        hda-verb-14122 [003] .... 90712.799881: hda_power_count: [0:0]
power_count=1, power_on=1, power_transition=0

When the speakers stop, here is the output:

# tracer: nop
#
# entries-in-buffer/entries-
written: 8/8   #P:4
#
#                              _-----=> irqs-off
#                             / _----=> need-resched
#                            | / _---=> hardirq/softirq
#                            || / _--=> preempt-depth
#                            ||| /     delay
#           TASK-PID   CPU#  ||||    TIMESTAMP  FUNCTION
#              | |       |   ||||       |         |
        hda-verb-14066 [001] .... 90509.001737: hda_power_count: [0:0]
power_count=2, power_on=1, power_transition=0
        hda-verb-14066 [001] .... 90509.001740: hda_send_cmd: [0:0] val=1f70500
        hda-verb-14066 [001] .... 90509.001814: hda_get_response: [0:0] val=0
        hda-verb-14066 [001] .... 90509.001814: hda_power_count: [0:0]
power_count=1, power_on=1, power_transition=0
        hda-verb-14122 [003] .... 90712.799801: hda_power_count: [0:0]
power_count=2, power_on=1, power_transition=0
        hda-verb-14122 [003] .... 90712.799804: hda_send_cmd: [0:0] val=1f70500
        hda-verb-14122 [003] .... 90712.799880: hda_get_response: [0:0] val=0
        hda-verb-14122 [003] .... 90712.799881: hda_power_count: [0:0]
power_count=1, power_on=1, power_transition=0

I'm a bit out of my element here, if I've missed a crucial step,
please let me know.

Thanks!

-Jason