After upgrade from 13.2 to 42.2 I have no sound, sound card not detected.
I enter Yast, and two cards appear:
0 nVidia corporation
1 SBx00 Azalia (Intel HDA)
I edit them both in yast, reset all values to default, exit yast and sound is working again, but when I restart the computer the dummy output is here again.
What can I do to fix the sound card?
regards
The NVIDIA is probably HDMI out try changing the order make the analog card the first ie device 0
gogalthorp has a good suggestion.
I do not know what alsa module these two cards use. If they use different instances of the same module, then yast will not be able to correctly handle such a situation.
One can also direct the sound, on a per application and per sound device basis, using the application ‘pavucontrol’. If not installed it can be installed.
If card-0 and card-1 is reversed, aside from using ‘pavucontrol’ one can also force the sound cards to a different setup by a custom edit to a configuration file, where one specifies the card via its ID. If necessary I can help there.
yes, they show in kde sound control as
Built-in audio analog surround 5.1
High definition audio controller digital surround 5.1 (HDMI)
The second one is the card linked to the HDMI output of the sound card?
The one I am using is the 5.1 motherboard sound card.
should I delete the other?
regards
In Yast change the order. You can test there also it must work there or won’t work anywhere. Then go to sound cards in Desktop settings
I set the analog one as primary card but the problem remains.
Tne I deleted both cards in yast and then configure them again, now their name has changed, yast cofired them as
0 M4A785TD Motherboard
1 High Definition Audio Controller
And it worked, but again, after a reboot I have the dummy output in kde.
pavucontrol reports “no cards available for configuration”
regards
Can you provide us more information on your PC audio setup ? You can do this by running a diagnostic script as a regular user in a konsole/xterm with PC connected to the internet (see command below). You may wish to try this a couple of times, once with sound configured via YaST and once with it not configured via YaST :
/usr/sbin/alsa-info.sh
Select the SHARE/UPLOAD option when prompted, let the script run to completion, and then when it completes look in the xterm/konsole and you will see a URL address indicating where script output has been uploaded. Copy that address/URL here. We can take a look at it and we may be able to then come up with a better suggestion as opposed to our just speculating.
Note if both devices use different instances of the same sound module, YaST will struggle wrt applying a permanent solution fix. I tried to indicate that in my previous post - but received no feed back if the devices use the same or different alsa sound modules. The diagnostic script will hopefully provide that information.
Configured with yast and working
http://www.alsa-project.org/db/?f=5875313243cfe3071ac00706c1daf7ed2aa5f74c
Configured but not working (after restart)
http://www.alsa-project.org/db/?f=882ba47fc4c4bc6b1b3bd22943931e26a48e276c
Not configured (deleted configuration of both cards with yast) … but working!!!
http://www.alsa-project.org/db/?f=46e8ff7d648f6980e052b90c51d60eec35ffbc6c
Not configured and not working (after restart)
http://www.alsa-project.org/db/?f=52ccabc5000f9c582dc270271898e2d558654e9c
Is a lot of information, I not sure if it is some difference between the four of them.
I think both cards are using the same alsa module :
snd_hda_intel
can you see something important in this info?
thanks
It is puzzling. I have some ideas.
As near as I can determine in every case your analog sound device was correctly identified as sound-card-0 (default) and your HDMI as sound-card-1, even when sound was not working.
I did a computer comparison, and while I saw some minor differences, the differences are outside of my competence to comment on. Most of what I saw in the configuration is identical no matter if sound is broken or working. It also suggests (since this is an alsa script), that the problem is not with alsa but it is somewhere else - possibly with pulse audio or possibly with some app that has seized the sound device and is refusing to share it.
I note after going into YaST and configuring (or deleting) sound works. This suggests the YaST functionality of restarting pulse/alsa does the trick and not the actual configuration details.
BUT I need to eliminate any 50-sound.conf file possibility to be certain. One thing I did note is there is no evidence of YaST creating a 50-sound.conf file from the script run after configuring with YaST (as that should appear in the script output and it does not appear). Could you configure sound with YaST, get sound working, and then look to see if there is any /etc/modprobe.d/50-sound.conf file created ? If so, back it up, then check after a reboot if the file is still there ? (also post a copy of that file here, if it existed). If after a reboot the 50-sound.conf file is still there - does sound work ? My guess is no - sound does not work.
Assuming then sound does not work, remove that file (with root permissions) and reboot and test. Does sound work now? I suspect it might < not sure > Assuming it does work, do NOT (I repeat do NOT) go into YaST > Hardware > Sound. YaST sound app does NOT work well if one’s two devices (analogue sound and HDMI) both use different instances of the same snd-hda_intel module - which IS the case for you.
So if sound is working (after after a reboot with no /etc/modprobe.d/50-sound file in place) we have a work around.
If that is not the case (no 50-sound.conf file or sound not working) let me know - as we need to find a different approach. Where I think that different approach focuses on pulse and an app and not on alsa. I say this as another cause of the problem could be that after sound is configured in the boot, some app is then launched that blocks the sound. And by going into YaST and forcing a sound restart you break the hold that app has on blocking your sound.
I am speculating here in both cases above.
wrt the alsa-script outputs :
I note after 18-seconds in the boot process (according to dmesg) the sound module loading completes. I assume sound does not work then. I note further at 2222 seconds (about 37-minutes) more audio entries, which I assume is you configuring sound with YaST, after which sound works. Note in doing such YaST will restart pulse and alsa. It may be that restart and not the configuring that does the ‘trick’.
I assume here there was a 50-sound.conf file in place, and your sound did not work. If so that means the YaST 50-sound.conf file did not help after a reboot. I note here the alsa modules are loaded after about 23 seconds into the boot. I also can not see a 50-sound.conf file content reflected in the script, and nominally if there is such a file one might see an entry in the script reflecting there being some custom entries in such a file.
I note here alsa (sound) was configured after 23-seconds into the boot, and then again later 441 seconds (7-minute) into the boot. I suspect the 441 seconds was deleting the sound devices in YaST (which restarted the sound). What I do not know if sound was working at the 23 second point.
Working after deleting the cards with YaST (and no config) suggests it was YaST forcing a pulse/alsa restart that did the trick - as it broke the block that some app had on the alsa driver.
I note here alsa (sound) was configured about 23-to-25 seconds into the boot. You note no sound. That suggests something has seized the sound device, and is not sharing it, which is why no sound.
My guess is with the /etc/modprobe.d/50-sound.conf file removed, you have no sound after a boot.
My guess is also that after a boot, if we give you the command to force a pulse restart (and maybe an alsa restart) your sound may then work.
Do you have your desktop setup to run any multimedia apps at boot ?
/etc/modprobe.d/50-sound.conf was there, i deleted it, configured sound with yast and it appeared again, the same content
options snd slots=snd-hda-intel
# 5Dex.Llr7zS2YqdE:M4A785TD Motherboard
alias snd-card-0 snd-hda-intel
Then I rebooted, sound did not work but file was still there. Then I deleted the file and rebooted. Sound did not work.
There is a empty 50-sound.conf.YaST2save
If that is not the case (no 50-sound.conf file or sound not working) let me know - as we need to find a different approach. Where I think that different approach focuses on pulse and an app and not on alsa. I say this as another cause of the problem could be that after sound is configured in the boot, some app is then launched that blocks the sound. And by going into YaST and forcing a sound restart you break the hold that app has on blocking your sound.
I am speculating here in both cases above.
wrt the alsa-script outputs :
I note after 18-seconds in the boot process (according to dmesg) the sound module loading completes. I assume sound does not work then. I note further at 2222 seconds (about 37-minutes) more audio entries, which I assume is you configuring sound with YaST, after which sound works. Note in doing such YaST will restart pulse and alsa. It may be that restart and not the configuring that does the ‘trick’.
I assume here there was a 50-sound.conf file in place, and your sound did not work. If so that means the YaST 50-sound.conf file did not help after a reboot. I note here the alsa modules are loaded after about 23 seconds into the boot. I also can not see a 50-sound.conf file content reflected in the script, and nominally if there is such a file one might see an entry in the script reflecting there being some custom entries in such a file.
I note here alsa (sound) was configured after 23-seconds into the boot, and then again later 441 seconds (7-minute) into the boot. I suspect the 441 seconds was deleting the sound devices in YaST (which restarted the sound). What I do not know if sound was working at the 23 second point.
Working after deleting the cards with YaST (and no config) suggests it was YaST forcing a pulse/alsa restart that did the trick - as it broke the block that some app had on the alsa driver.
I note here alsa (sound) was configured about 23-to-25 seconds into the boot. You note no sound. That suggests something has seized the sound device, and is not sharing it, which is why no sound.
My guess is with the /etc/modprobe.d/50-sound.conf file removed, you have no sound after a boot.
My guess is also that after a boot, if we give you the command to force a pulse restart (and maybe an alsa restart) your sound may then work.
Do you have your desktop setup to run any multimedia apps at boot ?
No, I have nothing like amarok or similar running at boot.
regards
Assuming you have set the card you want to card zero one of the panels in kde settings multimedia has many options for what type of sound goes where. First set the default devices in audio volume then go to audio and video device preferences and select the same card for all of them one at a time and set the card you don’t want off in audio hardware setup.
Worked for me but I can’t be 100% of the order I did it in and when I go to audio hardware set up it still shows a card which is off so I have to select the one that I have left on to test it if needed. I suspect I set the unwanted cards off first. I have 3 of them.
The other thing I noticed that one of YAST’s sound tests didn’t play anything so I always finally checked for no sound with kde’s audio hardware set up.
You might find pavucontrol useful as alsa’s desktop gui’s don’t work for me any more. I’d guess that pulse is by passing them somehow.
KDE does not detect any sound card until I change something in yast sound configuration, then kde detect sound card and it play sound well, but after a restart again kde detects no sound card
regards
I would like to investigate this possibility of some app seizing the sound device at boot further. It does not need be an app such as amarok. It could be an app associated with the desktop (KDE in your case) or even an app associated with pulse audio itself. The speculative investigative track here is to see if we can find if something has seized the audio device, and then when you go to YaST and configure / or delete , it restarts pulse/alsa which then allows sound to work.
After a reboot, when your sound is NOT working, could you immediately in a konsole xterm send this command:
pasuspender -- aplay -D hw:0,0 -vv /usr/share/sounds/alsa/test.wav
Note I have assumed " hw:0,0 " is the device where you are trying to direct audio to, based on the scripts you ran which had :
!!Aplay/Arecord output
!!--------------------
APLAY
**** 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 1: VT1708S Digital [VT1708S Digital]
Subdevices: 1/1
Subdevice #0: subdevice #0
ie hw:0,0 being card-0 : device-0
The idea is that command “pasuspender” suspends pulse audio for this one instance of the command aplay, and aplay will play sound direct via alsa to device " hw:0,0 " . If sound works that suggests pulse is blocking the sound. If sound does not work we are not much further ahead, although if that command does not work it does suggest alsa (in addition to pulse) could still be the cause.
I should note in the above that I also assumed when your sound is not working that the following command gives no sound:
aplay -D hw:0,0 -vv /usr/share/sounds/alsa/test.wav
If the aplay command in the line above (without pasuspender) gives sound when sound is NOT nominally working, then my assumptions and investigative track is wrong.
The reason I posted was that this was the only way that I could get kde to retain settings while the sound was playing through the card I wanted it to.
I recollect enabling pulse in yast as well.
Both of them play sound as root, both of them exit with error as normal user
regards
Show error. But also be sure your user is in audio group
I have some apps like old kde3 korn, knotes or akregator that may use sound
fernando@andromeda:~> aplay -D hw:0,0 -vv /usr/share/sounds/alsa/test.wav
ALSA lib pcm_hw.c:1713:(_snd_pcm_hw_open) Invalid value for card
aplay: main:786: audio open error: Permission denied
fernando@andromeda:~> cat /etc/group |grep audio
audio:x:17:pulse
fernando@andromeda:~>
I’m not in audio group. It is necessary for a normal user to be in audio group?
regards
Can be a problem with some sound devices.
If sound works for root but not user it is a good but not certain bet.
Note you must relog after joining a new group for it to take effect