Sound card randomly not found at boot/login?

Hey guys, this is a problem this seems to have started about a week ago after one of the updates, and it’s annoying me to the point where I’m about ready to wipe the system and switch to a different distro - but I thought I’d ask and see if any of you might have an idea what’s going on and how I could fix it.

I haven’t logged it exactly, but I’d guess that probably about 4 out of every 5 boots, for some reason KDE (or whatever is looking for my sound card) doesn’t find it, and instead assigns all sounds to a device called “Dummy Output.” The speaker icon comes up in the tray, etc, but it doesn’t appear to see my sound hardware.

BUT - I can go into Yast, go into the Sound settings, and my sound card is right there, sound tests work without a problem, etc.

As you might guess I do quite a bit on my PC that uses sound, so this is driving me batty. Any ideas?
:\

(As an unrelated side note, after the updates my clock now also now insists an being on hour ahead when I reboot even though it’s set to the correct time zone, KDE now asks for the root password about a dozen times a day for stuff it never asked for passwords on before such as device mounting, and Network Manager hasn’t worked right from Day 1. You know, as long as I’m venting frustrations).

On 2013-04-11, Shadoglare <Shadoglare@no-mx.forums.opensuse.org> wrote:
>
> Hey guys, this is a problem this seems to have started about a week ago
> after one of the updates, and it’s annoying me to the point where I’m
> about ready to wipe the system and switch to a different distro - but I
> thought I’d ask and see if any of you might have an idea what’s going on
> and how I could fix it.

I suggest you switch to Ubuntu. Or better, use Windows. Seriously, no-one here is impressed or even threatened by your
suggestion of changing distro. Linux is not free, you just pay with time rather than money. If your mindset is fixed on
having the computer do the job', then Linux is not for you. Linux is about freedom and control. But it comes at the price of having to make choices and puts the responsibility on you to make sure they are informed’ choices.

> I haven’t logged it exactly, but I’d guess that probably about 4 out of
> every 5 boots, for some reason KDE (or whatever is looking for my sound
> card) doesn’t find it, and instead assigns all sounds to a device called
> “Dummy Output.” The speaker icon comes up in the tray, etc, but it
> doesn’t appear to see my sound hardware.

If this is really the case (which I don’t think - see below), you need to test it properly: i.e. boot 10 times - how
many times is the sound hardware detected. If it’s between 1 and 9 then you have a hardware/dust problem, loose
connection, or your soundcard isn’t properly seated. There’s no random number generation during hardware detection.

> BUT - I can go into Yast, go into the Sound settings, and my sound card
> is right there, sound tests work without a problem, etc.

If the sound card is always right there and the sound tests always work, then I don’t know what you mean in the previous
paragraph by `it doesn’t appear to see my sound hardware’.

> As you might guess I do quite a bit on my PC that uses sound, so this
> is driving me batty. Any ideas?

The chances are that you haven’t got a hardware problem. However, you really haven’t given us much to go on. There are
very basic information we need which cannot be extracted telepathically but nevertheless are necessary details required
for us in order to help you, e.g.:

  1. What version of openSUSE are you using?
  2. What sound card do you have?
  3. What graphics card do you have? (and yes this is relevant).

You just have to accept there is a logical reason to your problem and adopt a rational approach in diagnosing the cause
and solving it.

I’ve been using various Linux distros as my primary OS for probably about a decade now (and no, not Ubuntu - because annoyingly it has it’s own glitches in it’s shutdown procedure that mess with my hardware), and this kind of pissy elitist response from the “community” is still a prime reason that I’d hesitate to suggest it to others. I’m sorry but we’re well past the point where we should accept, or for that matter expect stuff breaking on update on anything that isn’t a “testing” level update. Yes, I expect it to “just work,” and it was my impression that the OpenSUSE team prided myself on making sure that happened before releasing - but with this 12.3 release that doesn’t appear to be what’s happening. I have better things to do with my time than spend hours trying to figure out why something isn’t working, especially when it worked just fine a week ago. It has seriously been years since I’ve used a distro where full release updates broke so much stuff. Saying I may switch wasn’t a “threat,” it was expressing that I hope I don’t have to switch and hope somebody has an idea what’s happening because frankly switching is a pain in the butt, something I just did a couple of months ago with 12.3 so I’m not thrilled with the idea of doing another format/restore already.

> I haven’t logged it exactly, but I’d guess that probably about 4 out of
> every 5 boots, for some reason KDE (or whatever is looking for my sound
> card) doesn’t find it, and instead assigns all sounds to a device called
> “Dummy Output.” The speaker icon comes up in the tray, etc, but it
> doesn’t appear to see my sound hardware.

If this is really the case (which I don’t think - see below), you need to test it properly: i.e. boot 10 times - how
many times is the sound hardware detected. If it’s between 1 and 9 then you have a hardware/dust problem, loose
connection, or your soundcard isn’t properly seated. There’s no random number generation during hardware detection.

Point taken on this one.

If the sound card is always right there and the sound tests always work, then I don’t know what you mean in the previous
paragraph by `it doesn’t appear to see my sound hardware’.

I mean when you click on the sound settings icon on the tray, it brings up the sliders for volume and it is for a device named “Dummy Output.” This is regardless of the fact that Yast sees the sound card.

  1. What version of openSUSE are you using?

12.3

  1. What sound card do you have?

Built onto to the motherboard. Yast says it’s an “AC’97”

  1. What graphics card do you have? (and yes this is relevant).

GEForce 7300 LE.

Regardless of our bit of a p***ing match at the start, I’d still be appreciative if anybody has any ideas on this. Thanks guys.

On 2013-04-11, Shadoglare <Shadoglare@no-mx.forums.opensuse.org> wrote:
> this kind of pissy elitist response from the “community” is still a
> prime reason that I’d hesitate to suggest it to others.

Sounded more a like a rant appropriate for soapbox than a proper troubleshooting post. Your time-related side-issue
supports that interpretation (although it might be a good idea to post it as a separate thread in the appropriate
subforum). There’s nothing wrong with venting, but there’s nothing `elitist’ in telling you that suggesting a putative
switch to another distro isn’t necessarily the best way to start a troubleshooting post if you want to garner any input
from other openSUSE regulars. Surely you can see that in the cold light of day?

I’m sorry but we’re well past the point where we should accept, or for that matter expect stuff breaking on update
on anything that isn’t a “testing” level update. Yes, I expect it to “just work,”

If there is mismatch between what you expect openSUSE to control for you and what it actually does control, then that’s
not your fault, but it would presumptive of you to claim it’s openSUSE’s fault. Since, as you say, you have used Linux
for some time, you will know that there are a number of audio layers (ALSA/PulseAudio) that increase the complexity of
sound management. To expect it to `just work’ without your intervention again seems presumptive.

> and it was my impression
> that the OpenSUSE team prided myself on making sure that happened before
> releasing - but with this 12.3 release that doesn’t appear to be what’s
> happening. I have better things to do with my time than spend hours
> trying to figure out why something isn’t working, especially when -it
> worked just fine a week ago-. It has seriously been years since I’ve
> used a distro where full release updates broke so much stuff. Saying I
> may switch wasn’t a “threat,” it was expressing that I hope I don’t
> have to switch and hope somebody has an idea what’s happening because
> frankly switching is a pain in the butt, something I just did a couple
> of months ago with 12.3 so I’m not thrilled with the idea of doing
> another format/restore already.

Since openSUSE 12.3 was released less than a month ago and you claim to have installed it a couple of months ago, I can
only infer that you did not install the full release.

> Regardless of our bit of a p***ing match at the start, I’d still be
> appreciative if anybody has any ideas on this. Thanks guys.

OK - as you seem to suggest, let’s dispense with the unpleasantries and try to solve the problem. Thank you for the
answers (am I right in assuming you have 64-bit openSUSE 12.3 RC installed with KDE?). I’d like to ask a few more
details:

  1. In YaST, are there any nvidia devices listed under `Audio’.
  2. What application with audio are you using to test sound?
  3. Do you have PulseAudio enabled under YaST?
  4. Assuming you do have PulseAudio enabled, are there any devices listed under pavucontrol (which sadly isn’t installed
    by default) in the `Configuration’ tab.
  5. Is your openSUSE 12.3 fully up-to-date? If not, does running a `sudo zypper up’ make any difference?

Yes, however responding to someone’s frustration with system issues with something like “Maybe you should just go back to Windows” isn’t exactly constructive either. (The newest version of Windows I own is about 14 years old, BTW). I’m just putting it down as we both had a grouchy moment that we’re past now.

Since, as you say, you have used Linux for some time, you will know that there are a number of audio layers (ALSA/PulseAudio) that increase the complexity of sound management.

I’m aware that there are multiple layers as well as multiple solutions, and that not all apps necessarily use the same ones, yes.

To expect it to `just work’ without your intervention again seems presumptive.

Except that, as I mentioned, it’s been doing just that until very recently, and it’s probably been years since I’ve encountered a sound issue. Sound worked perfectly “out of the box” and had been until recent updates pulled down, which although I didn’t catch every package I noticed did contain several updates related to those previously mentioned sound systems - thus of course raising my suspicions that the problems were a result of those updates.

Since openSUSE 12.3 was released less than a month ago and you claim to have installed it a couple of months ago, I can only infer that you did not install the full release.

It’s the full release - I installed it a few days after it came out. I don’t recall what the exact release date was or the exact date I installed it, sorry.

OK - as you seem to suggest, let’s dispense with the unpleasantries and try to solve the problem. Thank you for the
answers (am I right in assuming you have 64-bit openSUSE 12.3 RC installed with KDE?). I’d like to ask a few more
details:

Almost - it’s the 64-bit 12.3 full release, with KDE.

  1. In YaST, are there any nvidia devices listed under `Audio’.

Nope, the “AC’97” is the only device listed

  1. What application with audio are you using to test sound?

First I listen for the KDE login sound, which when I don’t hear it I can click on the volume control tray app and see that “Dummy Output” is the selected sound device. At this point I can test using FireFox (such as with Youtube). or Amarok, and they act like they are playing but are silent.
However I can then go into Yast → Sound, and the “AC’07” will be the only device listed - I can then go to Other → Play Test Sound and the test works fine. I have also selected “Set as the primary card” to see if it would make a difference, but it didn’t.

  1. Do you have PulseAudio enabled under YaST?

Yes, if I go to Yast → Sound → Other → PulseAudio Configuration, it shows PulseAudio as enabled.

  1. Assuming you do have PulseAudio enabled, are there any devices listed under pavucontrol (which sadly isn’t installed
    by default) in the `Configuration’ tab.

I installed, ran, and under the Configuration tab it says “No cards available for configuration.”

  1. Is your openSUSE 12.3 fully up-to-date? If not, does running a `sudo zypper up’ make any difference?

It is according to the update app… but I’ll run the zypper command…
And it only found a new update for gtk-config.

I can also say that I’ve got the same thing loaded on my netbook (which is much newer than the desktop I’m having issues with) and it appears to not be having any issues at all - it appears to be something that went wonky with this specific hardware support
:\

I observed this clock problem on one of my 12.3 installs (but NOT on the other two installs). The differences between PCs were hardware. I have not been able to point at any piece of hardware and note its driver caused the clock problem.

I note this morning that the problem has gone away. I examined the updates, but unfortunately they were very large and I can not figure out which one fixed the problem.

I could not find anything in the log files given my knowledge level.

These are the rpms I installed. I can’t recall if the clock problem went away after the 7-April update or the 11-April update (yesterday). But I suspect it may have been yesterday’s that fixed it (the clock problem).


gstreamer-0_10-fluendo-mp3-18-9.7.1.x86_64    Thu 11 Apr 2013 08:28:19 PM CEST
gstreamer-plugins-ugly-1.0.6-2.6.x86_64       Thu 11 Apr 2013 08:28:18 PM CEST
gstreamer-plugins-good-extra-1.0.6-2.5.x86_64 Thu 11 Apr 2013 08:28:18 PM CEST
gstreamer-plugins-bad-1.0.6-3.4.x86_64        Thu 11 Apr 2013 08:28:18 PM CEST
libgstsdp-1_0-0-1.0.6-2.4.x86_64              Thu 11 Apr 2013 08:28:17 PM CEST
gstreamer-plugins-good-1.0.6-2.5.x86_64       Thu 11 Apr 2013 08:28:17 PM CEST
libgstrtsp-1_0-0-1.0.6-2.4.x86_64             Thu 11 Apr 2013 08:28:16 PM CEST
libgstrtp-1_0-0-1.0.6-2.4.x86_64              Thu 11 Apr 2013 08:28:16 PM CEST
libgstfft-1_0-0-1.0.6-2.4.x86_64              Thu 11 Apr 2013 08:28:16 PM CEST
libgstbasecamerabinsrc-1_0-0-1.0.6-3.4.x86_64 Thu 11 Apr 2013 08:28:16 PM CEST
libgstriff-1_0-0-1.0.6-2.4.x86_64             Thu 11 Apr 2013 08:28:15 PM CEST
libgstapp-1_0-0-1.0.6-2.4.x86_64              Thu 11 Apr 2013 08:28:15 PM CEST
gstreamer-0_10-plugins-bad-lang-0.10.23-19.22.noarch Thu 11 Apr 2013 08:28:15 PM CEST
gstreamer-0_10-plugins-bad-0.10.23-19.22.x86_64 Thu 11 Apr 2013 08:28:15 PM CEST
vlc-aout-pulse-2.0.6-115.2.x86_64             Thu 11 Apr 2013 08:28:14 PM CEST
libgstpbutils-1_0-0-1.0.6-2.4.x86_64          Thu 11 Apr 2013 08:28:14 PM CEST
handbrake-gtk-0.9.8-3.3.x86_64                Thu 11 Apr 2013 08:28:14 PM CEST
gstreamer-0_10-plugins-good-0.10.31-11.21.x86_64 Thu 11 Apr 2013 08:28:13 PM CEST
libgstvdp-0_10-23-0.10.23-19.22.x86_64        Thu 11 Apr 2013 08:28:12 PM CEST
libgstbasecamerabinsrc-0_10-23-0.10.23-19.22.x86_64 Thu 11 Apr 2013 08:28:12 PM CEST
vlc-2.0.6-115.2.x86_64                        Thu 11 Apr 2013 08:28:11 PM CEST
libgstvideo-1_0-0-1.0.6-2.4.x86_64            Thu 11 Apr 2013 08:28:11 PM CEST
libgstbasevideo-0_10-23-0.10.23-19.22.x86_64  Thu 11 Apr 2013 08:28:11 PM CEST
gstreamer-0_10-plugins-ugly-0.10.19-10.18.x86_64 Thu 11 Apr 2013 08:28:11 PM CEST
gstreamer-0_10-plugin-gnomevfs-0.10.36-9.20.x86_64 Thu 11 Apr 2013 08:28:11 PM CEST
vlc-qt-2.0.6-115.2.x86_64                     Thu 11 Apr 2013 08:28:10 PM CEST
vlc-codecs-2.0.6-115.2.x86_64                 Thu 11 Apr 2013 08:28:10 PM CEST
libgstaudio-1_0-0-1.0.6-2.4.x86_64            Thu 11 Apr 2013 08:28:10 PM CEST
libgstapp-0_10-0-0.10.36-9.20.x86_64          Thu 11 Apr 2013 08:28:10 PM CEST
libgsttag-1_0-0-1.0.6-2.4.x86_64              Thu 11 Apr 2013 08:28:09 PM CEST
guvcview-lang-1.6.1-2.21.noarch               Thu 11 Apr 2013 08:28:09 PM CEST
gstreamer-0_10-plugins-base-0.10.36-9.20.x86_64 Thu 11 Apr 2013 08:28:09 PM CEST
vlc-noX-2.0.6-115.2.x86_64                    Thu 11 Apr 2013 08:28:08 PM CEST
libgstinterfaces-0_10-0-0.10.36-9.20.x86_64   Thu 11 Apr 2013 08:28:06 PM CEST
gstreamer-plugins-base-1.0.6-2.4.x86_64       Thu 11 Apr 2013 08:28:06 PM CEST
libvlc5-2.0.6-115.2.x86_64                    Thu 11 Apr 2013 08:28:05 PM CEST
guvcview-1.6.1-2.21.x86_64                    Thu 11 Apr 2013 08:28:05 PM CEST
typelib-1_0-Pango-1_0-1.32.5-3.4.2.x86_64     Thu 11 Apr 2013 08:28:04 PM CEST
systemd-sysvinit-195-13.18.1.x86_64           Thu 11 Apr 2013 08:28:04 PM CEST
pango-devel-1.32.5-3.4.2.x86_64               Thu 11 Apr 2013 08:28:04 PM CEST
libgudev-1_0-0-195-13.18.1.x86_64             Thu 11 Apr 2013 08:28:04 PM CEST
systemd-195-13.18.1.x86_64                    Thu 11 Apr 2013 08:28:03 PM CEST
libpango-1_0-0-32bit-1.32.5-3.4.2.x86_64      Thu 11 Apr 2013 08:28:02 PM CEST
libpango-1_0-0-1.32.5-3.4.2.x86_64            Thu 11 Apr 2013 08:28:02 PM CEST
aaa_base-extras-12.3-14.8.1.x86_64            Thu 11 Apr 2013 08:28:01 PM CEST
udev-195-13.18.1.x86_64                       Thu 11 Apr 2013 08:27:21 PM CEST
pango-tools-32bit-1.32.5-3.4.2.x86_64         Thu 11 Apr 2013 08:27:20 PM CEST
pango-tools-1.32.5-3.4.2.x86_64               Thu 11 Apr 2013 08:27:20 PM CEST
libibus-1_0-0-1.4.2-4.6.1.x86_64              Thu 11 Apr 2013 08:27:20 PM CEST
aaa_base-12.3-14.8.1.x86_64                   Thu 11 Apr 2013 08:27:16 PM CEST
yast2-mail-2.21.1-9.5.1.noarch                Thu 11 Apr 2013 08:27:15 PM CEST
libudev1-195-13.18.1.x86_64                   Thu 11 Apr 2013 08:27:15 PM CEST
mjpegtools-2.0.0-53.1.x86_64                  Thu 11 Apr 2013 08:27:14 PM CEST
k3b-codecs-2.0.2-15.33.x86_64                 Thu 11 Apr 2013 08:27:14 PM CEST
smplayer-0.8.4-1.5.x86_64                     Thu 11 Apr 2013 08:27:13 PM CEST
gmplayer-1.1+35127-2.23.x86_64                Thu 11 Apr 2013 08:27:13 PM CEST
libgstsignalprocessor-0_10-23-0.10.23-19.22.x86_64 Thu 11 Apr 2013 08:27:12 PM CEST
libgstphotography-1_0-0-1.0.6-3.4.x86_64      Thu 11 Apr 2013 08:27:12 PM CEST
rtmpdump-2.4.git20121102-1.1.x86_64           Thu 11 Apr 2013 08:27:11 PM CEST
k3b-2.0.2-15.33.x86_64                        Thu 11 Apr 2013 08:27:10 PM CEST
amarok-2.7.0-14.45.x86_64                     Thu 11 Apr 2013 08:27:08 PM CEST
libgstinterfaces-0_10-0-32bit-0.10.36-9.20.x86_64 Thu 11 Apr 2013 08:27:05 PM CEST
kdenlive-0.9.4-3.9.x86_64                     Thu 11 Apr 2013 08:26:53 PM CEST
libgstapp-0_10-0-32bit-0.10.36-9.20.x86_64    Thu 11 Apr 2013 08:26:51 PM CEST
libgstphotography-0_10-23-0.10.23-19.22.x86_64 Thu 11 Apr 2013 08:26:50 PM CEST
libgstcodecparsers-1_0-0-1.0.6-3.4.x86_64     Thu 11 Apr 2013 08:26:50 PM CEST
libgstcodecparsers-0_10-23-0.10.23-19.22.x86_64 Thu 11 Apr 2013 08:26:50 PM CEST
libmjpegutils-2_0-0-2.0.0-53.1.x86_64         Thu 11 Apr 2013 08:26:49 PM CEST
MPlayer-1.1+35127-2.23.x86_64                 Thu 11 Apr 2013 08:26:48 PM CEST
libvlccore5-2.0.6-115.2.x86_64                Thu 11 Apr 2013 08:26:45 PM CEST
wine-mp3-1.1.39-12.20.i586                    Thu 11 Apr 2013 08:26:44 PM CEST
handbrake-cli-0.9.8-3.3.x86_64                Thu 11 Apr 2013 08:26:43 PM CEST
mediainfo-0.7.62-1.10.x86_64                  Thu 11 Apr 2013 08:26:40 PM CEST
google-chrome-stable-26.0.1410.63-192696.x86_64 Thu 11 Apr 2013 08:26:20 PM CEST
youtube-dl-20121009-1.1.noarch                Wed 10 Apr 2013 07:00:32 PM CEST
mpg123-1.15.3-1.1.x86_64                      Sun 07 Apr 2013 07:16:34 AM CEST
gpac-0.5.0.svn4296-1.5.x86_64                 Sun 07 Apr 2013 07:16:31 AM CEST
libmpg123-0-1.15.3-1.1.x86_64                 Sun 07 Apr 2013 07:16:12 AM CEST
libslv2-9-0.6.6-3.9.x86_64                    Sun 07 Apr 2013 07:16:09 AM CEST
libgpac2-0.5.0.svn4296-1.5.x86_64             Sun 07 Apr 2013 07:16:08 AM CEST
libmpg123-0-32bit-1.15.3-1.1.x86_64           Sun 07 Apr 2013 07:16:07 AM CEST
MozillaFirefox-20.0-1.8.3.x86_64              Sun 07 Apr 2013 07:15:17 AM CEST
MozillaThunderbird-17.0.5-61.9.4.x86_64       Sun 07 Apr 2013 07:15:08 AM CEST
mozilla-nss-3.14.3-1.8.1.x86_64               Sun 07 Apr 2013 07:15:05 AM CEST
dhcp-client-4.2.5.P1-0.2.4.1.x86_64           Sun 07 Apr 2013 07:15:05 AM CEST
dhcp-4.2.5.P1-0.2.4.1.x86_64                  Sun 07 Apr 2013 07:15:05 AM CEST
mozilla-nss-certs-3.14.3-1.8.1.x86_64         Sun 07 Apr 2013 07:15:04 AM CEST
libsoftokn3-3.14.3-1.8.1.x86_64               Sun 07 Apr 2013 07:15:04 AM CEST
bind-utils-9.9.2P2-2.3.1.x86_64               Sun 07 Apr 2013 07:15:04 AM CEST
mozilla-nspr-4.9.6-1.4.1.x86_64               Sun 07 Apr 2013 07:15:03 AM CEST
libusbmuxd2-1.0.8-5.5.1.x86_64                Sun 07 Apr 2013 07:15:03 AM CEST
libfreebl3-3.14.3-1.8.1.x86_64                Sun 07 Apr 2013 07:15:03 AM CEST
bind-libs-9.9.2P2-2.3.1.x86_64                Sun 07 Apr 2013 07:15:03 AM CEST
zsh-5.0.2-2.5.1.x86_64                        Sun 07 Apr 2013 07:15:02 AM CEST
xrandr-1.4.0-4.4.1.x86_64                     Sun 07 Apr 2013 07:15:00 AM CEST
usbmuxd-1.0.8-5.5.1.x86_64                    Sun 07 Apr 2013 07:15:00 AM CEST
sysconfig-0.80.5-1.5.1.x86_64                 Sun 07 Apr 2013 07:14:58 AM CEST
libxslt1-32bit-1.1.28-3.4.1.x86_64            Sun 07 Apr 2013 07:14:57 AM CEST
libxslt1-1.1.28-3.4.1.x86_64                  Sun 07 Apr 2013 07:14:57 AM CEST
libvdpau1-0.6-2.4.1.x86_64                    Sun 07 Apr 2013 07:14:57 AM CEST
krb5-32bit-1.10.2-10.9.1.x86_64               Sun 07 Apr 2013 07:14:56 AM CEST
krb5-1.10.2-10.9.1.x86_64                     Sun 07 Apr 2013 07:14:56 AM CEST
dnsmasq-2.65-2.5.1.x86_64                     Sun 07 Apr 2013 07:14:54 AM CEST

This problem I do not have.

There is a sticky on the network manager fix in either the install forum area or the network forum area. Can you please advise if you tried the stickie fix.

wrt the sound, typically one’s sound configuration for alsa is stored in /etc/modprobe.d/50-sound.conf. It is important that backups are NOT stored in that directory (as they can be treated as real config files and not backups). A speculative guess is if you are having permission problems with sound you could add your user to group ‘audio’.

If it were me obtaining the dummy sound output, I would look at the log files. I know , its obvious to do and difficult to do at the same time, but how else to get the information to see what is happening ??? Else one is forcing users to either speculate when trying to help, or hoping someone else has experienced same problem and knows the fix.

So log files where I would start would be in ‘dmesg’ and also in /var/log/messages

If you need help / explanation as to how to open a log file to look inside, please feel free to post here and we will help as best we can.

I confess I see both sides of the viewpoint here. I’ve been using openSUSE (and before that SuSE-Pro) since 2001, and there were times in the early years (2001 to 2005) when I asked myself if another distribution might be better for me ?.In those early SuSE-Pro/openSUSE years what kept me on openSUSE was mostly the multimedia support from Packman and my liking the KDE destkop implementation of openSUSE. Now it is a host of additional factors that also keep me on openSUSE, not the least of which is knowing some members in the openSUSE community and obtaining personal support/help/information exchange at a very high degree - a degree that I would not get on a new distro because of my being new.

Almost all of my friends and colleagues use Windows or Mac, they are good people and their OS works for them. I don’t try to talk them into GNU/Linux. At the Linux User Group that I belong to, I am the only openSUSE user. All else use Ubuntu or Puppy Linux (on real old hardware). I don’t try to talk them into GNU/Linux. Rather I encourage them to stick with what they use and try to master it better.

Over the years I have tried to help users with sound, and for a while I hung out in the alsa IRC chat area. I tried to help many users of different distros at that time. I can say that other GNU/Linux distributions, on average, have as many if not more sound problems than openSUSE. Switching distributions is not always a panacea for a problem solution. It may solve a problem in one area and introduce a problem in another.

Instead I think the action you initiated in your 1st post in this forum was the smartest. Before jumping ship, try and sort the problem with help via a forum such as openSUSE. The mailing lists are also another excellent area to sort such openSUSE problems as that is where the packagers and developers mostly hang out. There is also the openSUSE irc chat area, and there is also the bug report approach, where in fact the bug report approach may be the best way to go about this. Possibly going for help earlier, before the frustration mounts to be too large, is thou a recommendation I would make.

My view is that by sticking with one distribution, whether that be Linux Mint, or Fedora, or Ubuntu, or what ever, when things get a bit rough, if one uses the ‘communication channels’ that that distro has in place BEFORE the frustration mounts, one may accomplish many things, not the least of which is solve one’s problem.

Best wishes in sorting this and my hats off to both yourself and flymail in rising about the initial rough waters to getting down to the technical to attempting to solve this problem. Lets see if we can sort this.

Thanks oldcpu. I’ve noticed you once posted a contribution concerning a similar issue :slight_smile:
http://forums.opensuse.org/english/get-technical-help-here/multimedia/440201-no-sound-only-dummy-output-pulse.html

On 2013-04-12, Shadoglare <Shadoglare@no-mx.forums.opensuse.org> wrote:
> I’m aware that there are multiple layers as well as multiple solutions,
> and that not all apps necessarily use the same ones, yes.

Sadly the multiple audio layers is something that overcomplicates (IMO) sound configuration in Linux. The layers you are
dealing with are definitely worth knowing about. If you want a good, brief explanation, have a look at
http://tuxradar.com/content/how-it-works-linux-audio-explained - sometimes they work in competition rather than
together!

> Almost - it’s the 64-bit 12.3 full release, with KDE.

Perfect :).

>
>> 1. In YaST, are there any nvidia devices listed under `Audio’.

Nope, the “AC’97” is the only device listed

Good. This means that the sound is not channeled to the wrong hardware.

  1. What application with audio are you using to test sound?

First I listen for the KDE login sound, which when I don’t hear it I
can click on the volume control tray app and see that “Dummy Output” is
the selected sound device. At this point I can test using FireFox (such
as with Youtube). or Amarok, and they act like they are playing but are
silent.

Those are good ways to test. Remember if you’re testing with a game, you may need to install OpenAL.

However I can then go into Yast → Sound, and the “AC’07” will be the
only device listed - I can then go to Other → Play Test Sound and the
test works fine. I have also selected “Set as the primary card” to see
if it would make a difference, but it didn’t.

At least this confirms that at the driver level, your hardware is reliably detected.

  1. Do you have PulseAudio enabled under YaST?

Yes, if I go to Yast → Sound → Other → PulseAudio Configuration, it
shows PulseAudio as enabled.

So the break in the Sound card->ALSA+Kernel->PulseAudio chain is likely to be at the level of PulseAudio or its
interface with ALSA.

  1. Assuming you do have PulseAudio enabled, are there any devices listed
    under pavucontrol (which sadly isn’t installed
    by default) in the `Configuration’ tab.
    >
    > I installed, ran, and under the Configuration tab it says “No cards
    > available for configuration.”

This confirms the above diagnosis.

>> 5. Is your openSUSE 12.3 fully up-to-date? If not, does running a `sudo

zypper up’ make any difference?

It is according to the update app… but I’ll run the zypper
command…
And it only found a new update for gtk-config.

OK so the issue is not resolved by updates. This kind of problem has been observed for other distributions (e.g. see
https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/322374 ). This leaves you with two options:

  1. Try and make PulseAudio work.
  2. Disable PulseAudio then uninstall it (you don’t need it to play sound).

How to accomplish 1) would be guesswork for me. If you Google ‘pulseaudio no cards available for configuration’ you will
find some potential work arounds. Looking at http://wiki.gentoo.org/wiki/PulseAudio the issue for Dummy Output only is
explained as PulseAudio unable to access the sound devices: either the the user has no permissions or another program is
blocking access. You could try:


$ fuser -v /dev/snd/*

to list potential programs - and close them. Or you could try restarting PulseAudio to try and reorder the block:


$ pulseaudio -k ; start-pulseaudio-x11

For PulseAudio, I find you have to reboot (or at least log out and in again) in order make changes take effect.
Regressive I know.

The last resort [Option 2)] is to disable and remove PulseAudio and reboot:


$ su -
$ setup-pulseaudio --disable
$ zypper rm pulseaudio
$ shutdown -r now

If by the time you reach this stage, it still fails then check your volumes in YaST.

Thank you guys for all of the input so far… unfortunately I don’t have much time to play with it this morning, but interestingly enough both the clock and sound appear to be working correctly through some sort of magical gnome intervention overnight or something (although as touched on earlier the sound issue would seem to randomly go away previously as well, so…)

I’ll have to report back on if it stays that way.

On 2013-04-12, Shadoglare <Shadoglare@no-mx.forums.opensuse.org> wrote:
>
> Thank you guys for all of the input so far… unfortunately I don’t have
> much time to play with it this morning, but interestingly enough both
> the clock and sound appear to be working correctly through some sort
> of magical gnome intervention overnight or something.
>
> I’ll have to report back on if it stays that way.

Good luck. I’m not sure about the clock but the apparent magic that got the sound working may have been the result of a
simple reboot that would have been required to see the effects of a configuration change. But if it works, don’t fix it
:).

Wellllll it worked fine again this morning, but there was another system update which I noticed included GStreamer updates as well as possibly other related stuff I didn’t catch… I’ve since rebooted and… sound doesn’t work again. sigh

When I have time to mess with it I guess I’ll have to try yanking PulseAudio as was suggested earlier :\

So tonight I decided to do the “10 boot test” to see what would happen.

10 boots, where all I did was boot up, log in, determine does the sound work yes or no, and hit reboot. No updates, no settings changes, not even loading an app aside from stuff that fires up on boot. Here are the results:

1: No. 2: No. 3: Yes. 4: No. 5: No. 6: Yes. 7: No. 8: Yes. 9: Yes. 10: No

So 60% of the time PulseAudio for some reason couldn’t see the sound card on boot.
Out of curiosity I tried manually restarting the daemon, and it gives me errors about not being able to start, though I deleted the settings file. Another reboot and I’ll probably look into just not using it as suggested above

I note this earlier post from me in this thread:

My assumption is you looked in great detail at the log files per that recommendation for each of those 10 cases, comparing them for each of the ten cases and saw no difference and concluded no one else could either ?

Edit : note there is a pastebin site for pasting things like the contents of log files: http://susepaste.org

I wasn’t even thinking about it yet - pretty much just showing that the gnomes had failed :slight_smile:

I cut out just the bits of log that mention PulseAudio -

Here’s the log entries from a boot where sound worked:

rtkit-daemon[1245]: Successfully made thread 1243 of process 1243 (/usr/bin/pulseaudio) owned by 'steve' high priority at nice level -11.
rtkit-daemon[1245]: Supervising 1 threads of 1 processes of 1 users.
systemd[1]: Started RealtimeKit Scheduling Policy Service.
steve: Try 2/8 : /proc/fs/vmblock/dev not available. sleeping for 4 seconds
steve: Try 3/8 : /proc/fs/vmblock/dev not available. sleeping for 8 seconds
hp-systray: hp-systray[1262]: error: option -s not recognized
rtkit-daemon[1245]: Successfully made thread 1308 of process 1308 (/usr/bin/pulseaudio) owned by 'steve' high priority at nice level -11.
rtkit-daemon[1245]: Supervising 4 threads of 2 processes of 1 users.
pulseaudio[1308]: [pulseaudio] pid.c: Daemon already running.
rtkit-daemon[1245]: Successfully made thread 1322 of process 1322 (/usr/bin/pulseaudio) owned by 'steve' high priority at nice level -11.
rtkit-daemon[1245]: Supervising 4 threads of 2 processes of 1 users.
pulseaudio[1322]: [pulseaudio] pid.c: Daemon already running.

And here’s the log entries from a boot where it didn’t work:

steve: Try 1/8 : /proc/fs/vmblock/dev not available. sleeping for 2 seconds
dbus-daemon[443]: dbus[443]: [system] Rejected send message, 2 matched rules; type="method_call", sender=":1.29" (uid=1000 pid=1241 comm="/usr/bin/pulseaudio --start --log-target=syslog ") interface="org.bluez.Manager" member="GetProperties" error name="(unset)" requested_reply="0" destination="org.bluez" (uid=0 pid=564 comm="/usr/sbin/bluetoothd -n ")
dbus[443]: [system] Rejected send message, 2 matched rules; type="method_call", sender=":1.29" (uid=1000 pid=1241 comm="/usr/bin/pulseaudio --start --log-target=syslog ") interface="org.bluez.Manager" member="GetProperties" error name="(unset)" requested_reply="0" destination="org.bluez" (uid=0 pid=564 comm="/usr/sbin/bluetoothd -n ")
pulseaudio[1241]: [pulseaudio] bluetooth-util.c: org.bluez.Manager.GetProperties() failed: org.freedesktop.DBus.Error.AccessDenied: Rejected send message, 2 matched rules; type="method_call", sender=":1.29" (uid=1000 pid=1241 comm="/usr/bin/pulseaudio --start --log-target=syslog ") interface="org.bluez.Manager" member="GetProperties" error name="(unset)" requested_reply="0" destination="org.bluez" (uid=0 pid=564 comm="/usr/sbin/bluetoothd -n ")
steve: Try 2/8 : /proc/fs/vmblock/dev not available. sleeping for 4 seconds
steve: Try 3/8 : /proc/fs/vmblock/dev not available. sleeping for 8 seconds
hp-systray: hp-systray[1283]: error: option -s not recognized
pulseaudio[1327]: [pulseaudio] pid.c: Daemon already running.
pulseaudio[1340]: [pulseaudio] pid.c: Daemon already running.

I wasn’t sure how to use the page you linked to so hopefully the way I pasted it in is OK (timestamps were removed in hopes of better legibility)

wrt SUSE Paste , it is incredibly easy, … copy the content that you wish to post, … paste into the ‘your paste’ box, optionally fill in the “author” and “title” name, and optionally change the default “delete after 1 week” to something a bit longer … and then press “create”. It gives you a URL where the new paste page has been created. Copy that URL. Post it here.

Its intutive and simple.

Without the timetags, I can’t tell where a new line starts, nor can I relate to where in the boot sequence the problem occurs. Nor do I know from which log file you obtained the content. IMHO its best to copy the entire /var/log/messages from the start of boot to a couple of minutes into the boot. Note /var/log/messages will have many days, so just select the relevant date.

Another useful log is ‘dmesg’. One can redirect it to a text file from within a bash shell/terminal by typing as a regular user (in one’s /home/username directory) " dmesg > dmesg-file.txt " and open dmesg-file.txt with a text editor to do the copy/paste.

Well, here is the log from a working session:
SUSE Paste

And here is the log from a failed session:
SUSE Paste

And if it’s at all helpful, here’s the dmesg log:
SUSE Paste

Initially when comparing working vs failed logs I noticed during the failed ones there were bluetooth support files that were intermixed between the lines were pulseaudio stuff was loading, so thinking that for some reason maybe the system trying to load bluetooth at the same time as the audio stuff was causing a problem, I uninstalled everything I could in regards to bluetooth and rebooted, but again it worked OK for a couple of boots and then stopped working again, so apparently it wasn’t that…

The differences I noted from your logs:
Successful

2013-04-14T18:28:12.337955-05:00 PITA rtkit-daemon[1247]: Successfully made thread 1246 of process
1246 (/usr/bin/pulseaudio) owned by 'steve' high priority at nice level -11.
2013-04-14T18:28:12.341024-05:00 PITA rtkit-daemon[1247]: Supervising 1 threads of 1 processes of 1
users.
2013-04-14T18:28:12.344334-05:00 PITA systemd[1]: Started RealtimeKit Scheduling Policy Service.
2013-04-14T18:28:13.480347-05:00 PITA steve: Try 2/8 : /proc/fs/vmblock/dev not available. sleeping
for 4 seconds
2013-04-14T18:28:17.495477-05:00 PITA steve: Try 3/8 : /proc/fs/vmblock/dev not available. sleeping
for 8 seconds
2013-04-14T18:28:20.123347-05:00 PITA rtkit-daemon[1247]: Successfully made thread 1308 of process
1308 (/usr/bin/pulseaudio) owned by 'steve' high priority at nice level -11.
2013-04-14T18:28:20.123400-05:00 PITA rtkit-daemon[1247]: Supervising 4 threads of 2 processes of 1
users.
2013-04-14T18:28:20.132855-05:00 PITA pulseaudio[1308]: [pulseaudio] pid.c: Daemon already running.
2013-04-14T18:28:20.438420-05:00 PITA rtkit-daemon[1247]: Successfully made thread 1318 of process
1318 (/usr/bin/pulseaudio) owned by 'steve' high priority at nice level -11.
2013-04-14T18:28:20.438454-05:00 PITA rtkit-daemon[1247]: Supervising 4 threads of 2 processes of 1
users.
2013-04-14T18:28:20.447409-05:00 PITA pulseaudio[1318]: [pulseaudio] pid.c: Daemon already running.

Unsuccessful:

2013-04-14T18:31:30.046135-05:00 PITA pulseaudio[1289]: [pulseaudio] pid.c: Daemon already running.
2013-04-14T18:31:30.843547-05:00 PITA pulseaudio[1305]: [pulseaudio] pid.c: Daemon already running.

I noted a few more (and I included the SUSE paste line numbers so you can better cross check what I noted):

Sound working (searching in log for keywords for sound, alsa, audio, and pulse):
SUSE Paste


**45. 2013-04-14T18:23:16.055701-05:00 PITA systemd[1]: Starting Sound Card.
46. 2013-04-14T18:23:16.055710-05:00 PITA systemd[1]: Reached target Sound Card.**

901. 2013-04-14T18:28:12.337955-05:00 PITA rtkit-daemon[1247]: Successfully made thread 1246 of process 1246 (/usr/bin/pulseaudio) owned by 'steve' high priority at nice level -11.

906. 2013-04-14T18:28:20.123347-05:00 PITA rtkit-daemon[1247]: Successfully made thread 1308 of process 1308 (/usr/bin/pulseaudio) owned by 'steve' high priority at nice level -11.

908. 2013-04-14T18:28:20.132855-05:00 PITA pulseaudio[1308]: [pulseaudio] pid.c: Daemon already running.
909. 2013-04-14T18:28:20.438420-05:00 PITA rtkit-daemon[1247]: Successfully made thread 1318 of process 1318 (/usr/bin/pulseaudio) owned by 'steve' high priority at nice level -11.
910. 2013-04-14T18:28:20.438454-05:00 PITA rtkit-daemon[1247]: Supervising 4 threads of 2 processes of 1 users.
911.  2013-04-14T18:28:20.447409-05:00 PITA pulseaudio[1318]: [pulseaudio] pid.c: Daemon already running.

Sound not working (searching in log for keywords for sound, alsa, audio, and pulse)::
SUSE Paste


995. 2013-04-14T18:31:30.046135-05:00 PITA pulseaudio[1289]: [pulseaudio] pid.c: Daemon already running.
996. 2013-04-14T18:31:30.843547-05:00 PITA pulseaudio[1305]: [pulseaudio] pid.c: Daemon already running.

wrt the dmesg log it was not clear to me under what circumstances you ran that. With sound working ? With sound not working ? As it was, I did not get any ‘hits’ on the words that I searched but given I do not know the circumstances under which dmesg was run (it will be different for each boot) I can not comment on the dmesg any more.

wrt the /var/log/messages, I noted when it works there is an entry “Starting Sound Card”. I could NOT find the same entry when sound does not work.

In an off chance that this is a permissions issue in starting your sound device that shows up randomly could you add your regular user to group audio and group pulse and group pulse-access, and then after the 1st reboot when sound does not work with those permission changes, remove them and put them back to normal. You can add permissions in YaST > Security and Users > User and Group Management , select your ‘user’ and select "Edit > Details " and then select audio, pulse, and pulse-access. Logically, since we are testing for a booting effect, a number of reboots is thus then needed to test (where after the 1st failure these extra permissions should be removed). This is a speculative effort and in truth it could be off base. If I had to bet money I would say permissions is not the issue, but I would like to remove this as a possibility.

Another dumb question - are you rebooting to MS-Windows in between GNU/Linux sessions ?

I ask because my mother has an HP PC where if she reboots from MS-Windows to GNU/Linux, often her Ethernet will not work. But if after using MS-Windows with power OFF, if she removes the power (via powerbar) from the PC, she then boots to GNU/Linux from a cold boot, her Ethernet in GNU/Linux will boot.

Surfing on her HP PC lead me to determine that residual power in the PC even when switched OFF (but still plugged in) mean that something MS-Windows setup (still resident via residual capacitance ? ) was impacting GNU/Linux boot. A reboot from GNU/Linux to GNU/Linux (with no MS-Windows in between) had no problems.

I want to remove speculation here that the method in which the boot is conducted could be playing a factor.