No sound, only Dummy output in pulse

I am running openSUSE 11.2 with an hda-intel sound card (dell latitude d830) in x64. Pulseaudio is only giving me a “dummy” sound card, even though volume in the yast sound configuration works. Volume is definitely not muted.

Here is the requested info:

:~> rpm -qa '*alsa*'

:~> rpm -qa '*pulse*'

:~> rpm -q libasound2

:~> uname -a
Linux linux-zsl5 #1 SMP PREEMPT 2010-03-16 21:25:39 +0100 x86_64 x86_64 x86_64 GNU/Linux

:~> cat /etc/modprobe.d/50-sound.conf

options snd slots=snd-hda-intel
# u1Nb.bHIrUAw8+c5:82801H (ICH8 Family) HD Audio Controller
alias snd-card-0 snd-hda-intel

So, besides that pulseaudio is not working, what other sound issues are you having? Many of us simple do not use pulseaudio, particularly if we use the KDE desktop. Why not consider a disable of pulseaudio all together? That is what I did, and all sound works like a champ. The terminal command is:

su -
linux-si8s:/home/james # setup-pulseaudio --disable

Thank You,

There are applications I want to use, particularly kwave, that depend on pulse.

Well I am no expert by any means for the uses of pulseaudio other than a good thing to disable. However, I ran KWAVE 0.8.5 in KDE 4.4.3 and was able to record sound from my sound card, in stereo, while playing a MP3 file in Amarok. Pulseaudio is installed, but disabled as I suggested in my first message. I may not understand what you are trying to do, but strictly speaking, pulseaudio being enabled is not required to use KWAVE.

Thank You,

I tried disabling pulse and I still get no sound:

ALSA lib pulse.c:229:(pulse_connect) PulseAudio: Unable to connect: Connection refused

cannot open mixer: Connection refused

I should probably say, though, I would much rather get the system working properly rather than shutting down pulseaudio.

Did you investigate the possibility that this could be a permissions problem? One needs root permissions to run YaST, and hence the sound test there is run with root permissions. Out side of YaST one runs with average user permissions.

Try adding your user to group audio, then restart, and test.
YAST » Security and Users » User Management » “select your user” » Edit » Details » Groups » check “audio” and then click on “ACCEPT”
or run

usermod -A audio yourusername

The new group membership will be available to processes started from the next login.

I’m a bit puzzled by this from the script:

!!Soundcards recognised by ALSA

 0 [Intel          ]: HDA-Intel - HDA Intel
                      HDA Intel at 0xf6ffc000 irq 21
 1 [Em28xxAudio    ]: Empia Em28xx AudEm28xx Audio - Em28xx Audio
                      Empia Em28xx Audio

The script notes 2 audio devices, yet your /etc/modprobe.d/50-sound.conf config file is configured for only one. What more can you tell us about your hardware here ?

Is it possible you have your desktop configured for the wrong sound device?

I had already added myself to the audio, pulse, and pulse-access groups.

The second “sound card” is a usb tv tuner. It only provides sound capture, not sound output, and as far as I can tell it is not defined as the default card anywhere. Pulse does recognize it for capture, but I haven’t been using it of course because it is not a real sound card. Pulse does not recognize my hda-intel card, though. So I really have three devices, a “dummy” output, “dummy” capture, and the em28xx capture device. The modprobe device is my hda-intel card, which is also the only device listed in yast, but alsa seems to correctly identify both, while pulse only identifies the em28xx device. And yast is able to correctly play test sounds, so its identification of the hda-intel card must be correct.

if you think it a pulse audio problem, as an interim solution, you could open up a Terminal session and enter su - and then the password.

At the terminal prompt enter this command (with root permissions).

setup-pulseaudio --disable

test, if that does not work, then restart and test again.

If that does not work, then you MUST enable it again with (with root permissions):

setup-pulseaudio --enable

in either case (whether it works or does not work) you still need to sort out why pulse is not working for you.

Also, does a simple speaker test work if run in a terminal with root permissions?

As I said in post #5, that didn’t work. I posted an error message there.

Ok, the information that you sent the exact commands I recommended (in post#10 ) is NOT in post#5. I do not know how anyone could possibly be certain you sent those commands that I recommended.

No, it doesn’t. I get the same error I mentioned before with pulse off, and no sound with pulse on. If I try to select the intel alsa pcm directly, I get this:

# aplay -D front -twav
aplay: main:608: audio open error: Device or resource busy

I understand. I did and it didn’t work.

It says the device is busy.

What is using the application that is using the audio device?

What is the output of the following in a terminal to see what applications have sound related files open:

lsof /dev/dsp* /dev/audio* /dev/mixer* /dev/snd/*

note the syntax of /dev/snd/* is DELIBERATELY different from the others in that command line.

What happens if you type in a terminal:

su -c 'rcalsasound restart'

and enter root password? The intent being to force a restart of alsa and break the hold of any application on your audio device. You MUST then restart your mixer as a regular user. kmix in KDE and possibly alsamixer in Gnome.

# lsof /dev/dsp* /dev/audio* /dev/mixer* /dev/snd/*
sd_espeak 2450 root  mem    CHR  116,4          5794 /dev/snd/pcmC0D0p
sd_espeak 2450 root    9r   CHR  116,2      0t0 5523 /dev/snd/timer
sd_espeak 2450 root   10u   CHR  116,4      0t0 5794 /dev/snd/pcmC0D0p
sd_espeak 2450 root   11u   CHR  116,8      0t0 5816 /dev/snd/controlC0
kmix      3655 todd   12u   CHR  116,8      0t0 5816 /dev/snd/controlC0
pulseaudi 3684 todd   20u   CHR 116,10      0t0 6159 /dev/snd/controlC1

After I restart alsa using the command you gave I get I get this error:

# aplay -twav
ALSA lib pulse.c:229:(pulse_connect) PulseAudio: Unable to connect: Connection refused

aplay: main:608: audio open error: Connection refused

Which is the same error I get when I turn pulse off. If I manually turn pulse back on by just running “pulseaudio” I get no sound from “aplay -twav” or “aplay -D front -twav” and I have this now:

lsof /dev/dsp* /dev/audio* /dev/mixer* /dev/snd/*
pulseaudi 8270 todd   20u   CHR 116,10      0t0  6159 /dev/snd/controlC1
pulseaudi 8270 todd   28u   CHR  116,8      0t0 50933 /dev/snd/controlC0
pulseaudi 8270 todd   35u   CHR  116,8      0t0 50933 /dev/snd/controlC0
kmix      8381 todd   12u   CHR  116,8      0t0 50933 /dev/snd/controlC0

You did not mention you had speech-dispatcher installed.

It looks to me like it is buggy.

It has seized your audio device and it is refusing to share it.

For example, I note this debien bug report: #577217 - speech-dispatcher locks main audio pcm preventing other apps to use sound - Debian Bug report logs](

Now I know NOTHING about speech-dispatcher, but my recommendation is you completely remove it, and then restart, and try again from the VERY beginning.

Thanks, that seems to have fixed it.

Great! Glad to read you have audio back.

Sorry to read you had to remove speech-dispatcher to get the audio back, … but well done in your determination to solve the problem.

hi, maybe for the next one that comes across this problem:

Two days ago, I enabled pulseaudio on my openSuSE 11.3, KDE 4.5.3, Kernel:
For a long time I was troubled by skype not being able to detect the sound coming from the microphone from my headset (or any headset for that matter).
After I enabled the pulseaudio support this worked fine. Yesterday it was working fine two, and I started liking the way pulseaudio works.
Today, after I booted up my laptop (old FJC lifebook E 8020), and after I logged into my KDE, there was no sound and I had the dummy output problem as well.
I didn’t troubleshoot a lot, because I got the inspiration to open the YaST sound module, and try to play a test sound. So I did, and as if pulseaudio waited for a push, it all started working as before, without further intervention from my side.

I am posting this, because it solved my problem and it is really a minor bother to do that. We will see tomorrow I guess if it will still work :wink: