[alsa-devel] After kernel upgrade to v ~~> 4.1.0, no audio output unless UNPLUG/RE-PLUGIN of audio jack on card; OK with earlier kernels
I run Opensuse 13.2/64.
My audio system has been / is ALSA, not PulseAudio.
I have installed
rpm -qa | grep -i alsa alsa-utils-1.0.29-143.1.x86_64 alsa-plugins-jack-1.0.29-99.1.x86_64 alsa-firmware-1.0.29-33.1.noarch alsa-devel-1.0.29-218.1.x86_64 alsa-plugins-1.0.29-99.1.x86_64 alsa-1.0.29-218.1.x86_64 alsa-oss-1.0.28-51.1.x86_64 alsa-docs-1.0.29-218.1.noarch
It's run fine for ages. In the past week -- after a bunch of zypper (distro packages) upgrades, and no I don't know which one specifically -- I now have an audio problem.
When I boot my machine there's no audio output.
Every alsa/sound diagnostic I ran said everything's OK.
Took me awhile to figure out that simply UNPLUGGING the audio jack from the mobo socket, then replugging it in fixes the audio -- immediately.
Chatting in #irc, suggestion was to check kernel version dependency.
I'm currently on latest stable kernel 4.1.X.
uname -rm 4.1.1-1.ga46abf6-desktop x86_64
I am absolutely sure that this was NOT a problem in the 4.0.X kernel branch. I am pretty-darn-sure that this was NOT a problem in earlier 4.1.X branch.
Unfortunately, I only had access to
4.1.1-1.1.ga46abf6 4.1.0-3.g5ee367d
and
3.16.7-21.1.x86_64
no longer any earlier 4.1.X or 4.0.X kernels.
Testing each of those
4.1.1-1.1.ga46abf6 --> FAILs 4.1.0-3.g5ee367d --> FAILs 3.16.7-21.1.x86_64 --> WORKs
so at least from 3.16.7 -> 4.1.0 there's a kernel dependency. Again, I'm pretty certain that this was NOT a problem with earlier 4.1.X and 4.0.X kernels; just can't prove it.
As instructed in IRC, I DL'd and exec'd the 'alsa-info.sh' script.
I ran the script in 2 cases:
[1] boot to console, kernel 4.1.1-1.1.ga46abf6, no audio output [2] boot to console, kernel 4.1.1-1.1.ga46abf6, unplug & replug, OK audio output
First, the DIFF between the two shows there IS a change on UNPLUG/REPLUG of the jack,
DIFF: ------------------------------------------ --- alsa-info.txt.BEFORE 2015-07-05 12:32:44.973554471 -0700 +++ alsa-info.txt.AFTER 2015-07-05 12:34:01.935900433 -0700 @@ -3,7 +3,7 @@ !!ALSA Information Script v 0.4.64 !!################################
-!!Script ran on: Sun Jul 5 19:32:43 UTC 2015 +!!Script ran on: Sun Jul 5 19:34:00 UTC 2015
!!Linux Distribution @@ -332,7 +332,7 @@ Pin-ctls: 0x40: OUT Unsolicited: tag=01, enabled=1 Power states: D0 D1 D2 D3 - Power: setting=D3, actual=D3 + Power: setting=D0, actual=D0 Connection: 1 0x16 Node 0x1d [Pin Complex] wcaps 0x40058d: Stereo Amp-Out @@ -602,7 +602,7 @@ crw-rw---- 1 root audio 116, 6 Jul 5 12:31 /dev/snd/hwC0D0 crw-rw---- 1 root audio 116, 10 Jul 5 12:31 /dev/snd/hwC2D0 crw-rw---- 1 root audio 116, 4 Jul 5 12:31 /dev/snd/pcmC0D0c -crw-rw---- 1 root audio 116, 3 Jul 5 12:32 /dev/snd/pcmC0D0p +crw-rw---- 1 root audio 116, 3 Jul 5 12:33 /dev/snd/pcmC0D0p crw-rw---- 1 root audio 116, 5 Jul 5 12:31 /dev/snd/pcmC0D3p crw-rw---- 1 root audio 116, 12 Jul 5 12:31 /dev/snd/pcmC1D0c crw-rw---- 1 root audio 116, 8 Jul 5 12:31 /dev/snd/pcmC2D3p ------------------------------------------
Since the output's too big for the list, apparently, I pastebin'd the full script output
[1] -> http://pastebin.com/jUyTRrFG [2] -> http://pastebin.com/4V8YCguV
- Rob
As add'l info
with guidance from #irc, I've tried
adding
/etc/modprodbe.d/50-sound.conf ... + options snd-hda-intel power_save_controller=0
and adding
/etc/init.d/after.local ... + hda-verb /dev/snd/hwC0D0 0x1c SET_POWER_STATE 0
and launching
cat /usr/local/scripts/alsa-fix.sh #!/bin/bash sudo hda-verb /dev/snd/hwC0D0 0x1c SET_POWER_STATE 0
as a KDE startup script,
and exec'ing
hda-verb /dev/snd/hwC0D0 0x1c SET_POWER_STATE 0
@ desktop shell as uid=<myuser>
None work.
The one thing that DOES work, so far, is @ desktop shell, exec of
sudo hda-verb /dev/snd/hwC0D0 0x1c SET_POWER_STATE 0
as sudo (root).
On exec, I hear a 'pop' through the speakers, and immediately after I can play audio -- withOUT having to physically UNPLUG/REPLUGIN the jack.
Clearly, I can't figure out how to automate this workaround -- not clear where else to try it. Begs the question why it only works in this case.
- Rob
At Sun, 05 Jul 2015 13:39:08 -0700, robert.devanna@nospammail.net wrote:
I run Opensuse 13.2/64.
My audio system has been / is ALSA, not PulseAudio.
I have installed
rpm -qa | grep -i alsa alsa-utils-1.0.29-143.1.x86_64 alsa-plugins-jack-1.0.29-99.1.x86_64 alsa-firmware-1.0.29-33.1.noarch alsa-devel-1.0.29-218.1.x86_64 alsa-plugins-1.0.29-99.1.x86_64 alsa-1.0.29-218.1.x86_64 alsa-oss-1.0.28-51.1.x86_64 alsa-docs-1.0.29-218.1.noarch
It's run fine for ages. In the past week -- after a bunch of zypper (distro packages) upgrades, and no I don't know which one specifically -- I now have an audio problem.
When I boot my machine there's no audio output.
Every alsa/sound diagnostic I ran said everything's OK.
Took me awhile to figure out that simply UNPLUGGING the audio jack from the mobo socket, then replugging it in fixes the audio -- immediately.
Chatting in #irc, suggestion was to check kernel version dependency.
I'm currently on latest stable kernel 4.1.X.
uname -rm 4.1.1-1.ga46abf6-desktop x86_64
I am absolutely sure that this was NOT a problem in the 4.0.X kernel branch. I am pretty-darn-sure that this was NOT a problem in earlier 4.1.X branch.
Unfortunately, I only had access to
4.1.1-1.1.ga46abf6 4.1.0-3.g5ee367d
and
3.16.7-21.1.x86_64
no longer any earlier 4.1.X or 4.0.X kernels.
Testing each of those
4.1.1-1.1.ga46abf6 --> FAILs 4.1.0-3.g5ee367d --> FAILs 3.16.7-21.1.x86_64 --> WORKs
so at least from 3.16.7 -> 4.1.0 there's a kernel dependency. Again, I'm pretty certain that this was NOT a problem with earlier 4.1.X and 4.0.X kernels; just can't prove it.
As instructed in IRC, I DL'd and exec'd the 'alsa-info.sh' script.
I ran the script in 2 cases:
[1] boot to console, kernel 4.1.1-1.1.ga46abf6, no audio output [2] boot to console, kernel 4.1.1-1.1.ga46abf6, unplug & replug, OK audio output
First, the DIFF between the two shows there IS a change on UNPLUG/REPLUG of the jack,
DIFF:
--- alsa-info.txt.BEFORE 2015-07-05 12:32:44.973554471 -0700 +++ alsa-info.txt.AFTER 2015-07-05 12:34:01.935900433 -0700 @@ -3,7 +3,7 @@ !!ALSA Information Script v 0.4.64 !!################################
-!!Script ran on: Sun Jul 5 19:32:43 UTC 2015 +!!Script ran on: Sun Jul 5 19:34:00 UTC 2015
!!Linux Distribution @@ -332,7 +332,7 @@ Pin-ctls: 0x40: OUT Unsolicited: tag=01, enabled=1 Power states: D0 D1 D2 D3
- Power: setting=D3, actual=D3
- Power: setting=D0, actual=D0 Connection: 1 0x16
Node 0x1d [Pin Complex] wcaps 0x40058d: Stereo Amp-Out @@ -602,7 +602,7 @@ crw-rw---- 1 root audio 116, 6 Jul 5 12:31 /dev/snd/hwC0D0 crw-rw---- 1 root audio 116, 10 Jul 5 12:31 /dev/snd/hwC2D0 crw-rw---- 1 root audio 116, 4 Jul 5 12:31 /dev/snd/pcmC0D0c -crw-rw---- 1 root audio 116, 3 Jul 5 12:32 /dev/snd/pcmC0D0p +crw-rw---- 1 root audio 116, 3 Jul 5 12:33 /dev/snd/pcmC0D0p crw-rw---- 1 root audio 116, 5 Jul 5 12:31 /dev/snd/pcmC0D3p crw-rw---- 1 root audio 116, 12 Jul 5 12:31 /dev/snd/pcmC1D0c crw-rw---- 1 root audio 116, 8 Jul 5 12:31 /dev/snd/pcmC2D3p
Since the output's too big for the list, apparently, I pastebin'd the full script output
[1] -> http://pastebin.com/jUyTRrFG [2] -> http://pastebin.com/4V8YCguV
The most important bit wasn't shown in the mail -- the codec name.
It's a known problem with VIA codecs, and the fix was already merged in 4.2-rc1, the commit 735c75cf4d434862e38c01dcfb2ce8d2fcb9035f. The next stable 4.1.x kernel should contain the fix.
thanks,
Takashi
On Mon, Jul 6, 2015, at 01:46 AM, Takashi Iwai wrote:
The most important bit wasn't shown in the mail -- the codec name.
It's a known problem with VIA codecs, and the fix was already merged in 4.2-rc1, the commit 735c75cf4d434862e38c01dcfb2ce8d2fcb9035f. The next stable 4.1.x kernel should contain the fix.
I didn't realize the script wouldn't grab the important info needed.
I think this does say it's a VIA codec here?
aplay -l **** List of PLAYBACK Hardware Devices **** card 0: SB [HDA ATI SB], device 0: VT1708S Analog [VT1708S Analog] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: SB [HDA ATI SB], device 3: VT1708S Digital [VT1708S Digital] Subdevices: 1/1 Subdevice #0: subdevice #0 card 2: NVidia [HDA NVidia], device 3: HDMI 0 [HDMI 0] Subdevices: 1/1 Subdevice #0: subdevice #0 card 2: NVidia [HDA NVidia], device 7: HDMI 1 [HDMI 1] Subdevices: 1/1 Subdevice #0: subdevice #0
cat /proc/asound/card0/codec* | grep Codec Codec: VIA VT1708S
At Mon, 06 Jul 2015 06:02:32 -0700, robert.devanna@nospammail.net wrote:
On Mon, Jul 6, 2015, at 01:46 AM, Takashi Iwai wrote:
The most important bit wasn't shown in the mail -- the codec name.
It's a known problem with VIA codecs, and the fix was already merged in 4.2-rc1, the commit 735c75cf4d434862e38c01dcfb2ce8d2fcb9035f. The next stable 4.1.x kernel should contain the fix.
I didn't realize the script wouldn't grab the important info needed.
The script includes the information, but your mail didn't, so I had to start a browser, and read it through by myself. If the codec chip was mentioned in the mail, I could answer in a second.
So, please, at the next time, give your hardware detail concisely in the mail itself. This will save lots of time.
thanks,
Takashi
The script includes the information, but your mail didn't, so I had to start a browser, and read it through by myself. If the codec chip was mentioned in the mail, I could answer in a second.
So, please, at the next time, give your hardware detail concisely in the mail itself. This will save lots of time.
I cooperatively provided the info that I was asked to provide -- the alsa-info script output for the before/after cases. ...
Since the output's too big for the list, apparently, I pastebin'd the full script output
[1] -> http://pastebin.com/jUyTRrFG [2] -> http://pastebin.com/4V8YCguV
The script info in my email clearly DOES provide the codec information.
I'd have put the script output INTO the email if the list didn't limit the size of the mail and refuse to accept it. It would save time if that limit didn't prevent including the info we're asked to provide.
At Mon, 06 Jul 2015 06:31:57 -0700, robert.devanna@nospammail.net wrote:
The script includes the information, but your mail didn't, so I had to start a browser, and read it through by myself. If the codec chip was mentioned in the mail, I could answer in a second.
So, please, at the next time, give your hardware detail concisely in the mail itself. This will save lots of time.
I cooperatively provided the info that I was asked to provide -- the alsa-info script output for the before/after cases. ...
Since the output's too big for the list, apparently, I pastebin'd the full script output
[1] -> http://pastebin.com/jUyTRrFG [2] -> http://pastebin.com/4V8YCguV
The script info in my email clearly DOES provide the codec information.
I'd have put the script output INTO the email if the list didn't limit the size of the mail and refuse to accept it. It would save time if that limit didn't prevent including the info we're asked to provide.
Well, sorry, you miss the point.
Although alsa-info.sh contains the whole things, it's too lengthy. The problem is not about whether you attach it or copy the URL. It's about the attitude to ask something.
Imagine you are asking someone the place of your favorite restaurant. Would you give just a thick address book that includes your marking? No, usually you tell the name or the address of the restaurant. Then some people might already know and can explain even without reading through the whole book. If not told, people won't pay attention to your question (who dare read the whole book?).
In general, it's important to know which information to give for asking something. For a sound problem, usually the hardware information (the machine model, the codec chip, etc) is the starting point. Attaching alsa-info.sh outputs helps indeed, and often requested; but this is rather a subsidiary thing. Just a more couple of lines to describe your hardware often helps people to understand the problem itself better.
Takashi
participants (2)
-
robert.devanna＠nospammail.net -
Takashi Iwai