Created attachment 306740 [details]
lshal -lu

output of:
for i in $(hal-find-by-capability --capability alsa); do lshal -lu $i; done

Note that:
* the Intel sound card is bundled with the motherboard and not used,
* the PCI SoundBlaster sound card should be used instead.

> Steps to Reproduce:
> 1. aplay -D hw:1 /usr/share/sounds/startup3.wav    ### works
> 2. aplay -D hw:0 /usr/share/sounds/startup3.wav    ### doesn't work
> 3. paplay /usr/share/sounds/startup3.wav           ### doesn't work

Please elaborate what you mean by "doesn't work". Does it fail with some
message? Is it that you just don't hear anything? Just saying that it doesn't
work doesn't help much.

There is no heuristic to identify which sound card you'd like to use by default.
Maybe PA chose the wrong one? Please start pavucontrol and move the playback
stream to the right device and mark the right device as "default" there.

Yes, "doesn't work" means "doesn't produce sound" in this context.

I'll try using "pavucontrol" to specify which device to use. In Fedora 8, the 
device was specified using "system-config-soundcard". I wasn't aware there's a 
new graphical program to configure audio. Although I do understand it's not 
really a Fedora bug, this still looks like a documentation issue.

I've read the Fedora 9 Release Notes and they do say that "system-config-
soundcard" has been removed:
http://docs.fedoraproject.org/release-notes/f9/en_US/sn-PackageNotes.html#sn-
sound-card-utility-changes

* There's not a single word about "pavucontrol" in the release notes, just a 
vague reference to "PulseAudio tools".

* Neither the KDE nor the Gnome audio settings dialogs are able to specify 
which device to use. Users shouldn't need to start a different "pavucontrol" 
program - which doesn't even appear in the menus as far as I can see.

* Maybe a symlink "system-config-soundcard" -> "pavucontrol" should be added 
during a transition period, since in Fedora 8 one would use "system-config-
soundcard" to specify a device.

Created attachment 306894 [details]
Screenshot of pavucontrol

Here is how pavucontrol looks like on my computer. The information is not
useful, it's too complicated: what does "ALSA PCM on front:1 (Intel ICH5) via
DMA" mean to a casual user?

The SoundBlaster card does not seem appear in pavucontrol. Unless the "ALSA PCM
on front:0 (ADC Capture/Standard PCM Playbak) via DMA" is related to the
SoundBlaster card?

Yes, the one that is not ICH is most likely your SB. Please try that.

Yes, those strings are not very explicative, but we get them from ALSA, so
please file a bug against ALSA if you are not happy with those strings.

I was able to get the Sound Blaster card to work only once, by selecting "ALSA
PCM on front:0 (ADC Capture/Standard PCM Playbak) via DMA". Then Pulse Audio
stopped producing sound again, with no apparent reason :-( The situation now is:
1. aplay -D hw:0 /usr/share/sounds/startup3.wav    ### produces sound
2. aplay -D hw:1 /usr/share/sounds/startup3.wav    ### doesn't produce sound
3. paplay /usr/share/sounds/startup3.wav           ### doesn't produce sound

Devices 0 and 1 have been inverted. Sound Blaster now being the default is
device 0. I'll continue investigating...

In the meantime, here are a few suggestions:

* The Fedora documentation is not up-to-date. For example:
http://fedoraproject.org/wiki/Releases/FeaturePulseaudio
Also I believe the release notes should refer explicitly to "pavucontrol":
http://docs.fedoraproject.org/release-notes/f9/en_US/sn-PackageNotes.html#sn-sound-card-utility-changes

* I'm not sure about your suggestion to file a bug against ALSA. I must admit I
don't know much about ALSA, but it looks like I'm able to retrieve a decent
sound card description using the ALSA "amixer" command. See below. If so, this
is not an ALSA issue. I'm relunctant to file a bug against ALSA: they'll most
probably tell me this a "pavucontrol" issue. Would you have arguments to
convince them this is an ALSA issue?

$ amixer -c 0 info
Card hw:0 'Live'/'SB Live 5.1 [SB0220] (rev.10, serial:0x80651102) at 0xdf80,
irq 20'
  Mixer name    : 'eMicro EM28028'
  Components    : 'AC97a:454d4328'
  Controls      : 216
  Simple ctrls  : 38
$ 
$ amixer -c 1 info
Card hw:1 'ICH5'/'Intel ICH5 with AD1985 at irq 17'
  Mixer name    : 'Analog Devices AD1985'
  Components    : 'AC97a:41445375'
  Controls      : 50
  Simple ctrls  : 35
$ 


A bug should probably be filed against ALSA, so that ALSA eventually returns
descriptions that make sense. Unfortunately I don't know enough about ALSA to
file such a bug: from a use point of view, I just see "pavucontrol" display
maningless strings in the user interface, such as "ALSA PCM on front:0 (ADC
Capture/Standard PCM Playbak) via DMA".
Which ALSA command line should I run to display the incriminated strings and
file a bug report with ALSA?

Still struggling with sound:

* I'm setting the SoundBlaster card as the default using "pavucontrol", but
"pavucontrol" keeps forgetting this setting from session to session.

* I'm still unable to produce sound using PulseAudio. I'm able to produce sound
usign Alsa:
1. aplay -D hw:0 /usr/share/sounds/startup3.wav    ### doesn't produce sound
2. aplay -D hw:1 /usr/share/sounds/startup3.wav    ### produces sound
3. paplay /usr/share/sounds/startup3.wav           ### doesn't produce sound


By the way, when starting KDE, I get in /var/log/messages:
Jun  4 07:23:13 localhost pulseaudio[2497]: module-x11-xsmp.c: X11 session
manager not running.
Jun  4 07:23:13 localhost pulseaudio[2497]: module.c: Failed to load  module
"module-x11-xsmp" (argument: ""): initialization failed.
Sometimes after a few hours of operation KDE's Phonon complains that PulseAudio
is not working properly and falls back on the SoundBlaster card (can't remember
the exact wording). After that I do get sound under KDE. Not sure what triggers
Phonon detecting PulseAudio is not working.

ALSA device ids are not stable. They depend on the initialization order of the
driver during bootup. Don't rely on the numbers. PA uses the HAL device UDI to
identify the device which should be stable between reboots.

The issue that PA fails to save the default device is because PA gets killed by
libX11 when X goes down before we have time to save the data. module-x11-xsmp is
supposed to work around this issue. However, It seems it isn't loaded properly
on KDE. It's a KDE setup issue. No idea about this. 

Yes, ALSA supplies good names for some subdevices, but not for all. If the PCM
device description are not good enough for you, then please file a bug against
alsa, not PA.

Hmm, I am closing this bug now, since the only bug remaining is a KDE setup
issue, no real bug in PA.

I've added to my TODO list to add a simple heuristic to PA to prefer PCI devices
over USB devices when both are available and no default device has been saved
before.

This is a KDE bug according to the PulseAudio specialist.

Rex this has been determined to be a KDE issue.  You or Kevin want to take a
stab at it.

The problem is that module-x11-xsmp fails to load. I guess this simply doesn't 
work in KDE and we need a module-x11-ksmserver instead?

I'm not sure if I follow the logic of module-x11-xsmp not loading to be a kde bug.  I haven't seen any evidence of that (yet).  Imo, those better qualified to fully diagnose this are certainly folks who have sufficient pulseaudio-fu, which unfortunately rules out most/all fedora's kde maintainers.

KDE seems to start PA before XSMP is available which causes that module to load.

Also, we now use a different method to get the device strings (we use the description of the card, not the PCM device). Those strings are still crappy on some devices, but it's a bit better.

Can this bug be closed now?

module-x11-xsmp fails to load even when I try loading it when KDE is already running, it's not a problem of startup order, it's that XSMP doesn't work at all in KDE. I'm not sure if that's expected.

PS: Well, I'd say it's not expected, ksmserver (the KDE session manager) speaks XSMP. So it looks like there's a bug on one of the ends.

PPS: PA claims: "module-x11-xsmp.c: X11 session manager not running."
(Sorry for the triple post. ;-) )

PA checks whether $SESSION_MANAGER is set. Is it for you?

Yes, it's set, to local/unix:@/tmp/.ICE-unix/PID,unix/unix:/tmp/.ICE-unix/PID where PID is the PID of ksmserver, it differs between my 2 machines.

*** Bug 441506 has been marked as a duplicate of this bug. ***

Hmmm, I think it is a startup order issue after all: in KDE, PA is started from /etc/kde/env/pulseaudio.sh, which is started before ksmserver, so it doesn't see the SESSION_MANAGER variable. It's set in the environment of pacmd, but not in the one of the server.

http://git.0pointer.de/?p=pulseaudio.git;a=blob;f=src/modules/module-x11-xsmp.c;h=e9efa09659875a4dffd4d644e4f294168cc97af8;hb=refs/heads/tags/release-0.9.10

That's where that error is printed. (look for pa__init()). It's a simple check for the env var. If it isn't set we bail out. KDE should start PA with that env var set.

In rawhide the startup of PA is completely different btw. What still stays true though is that PA should be started with $SESSION_MANAGER initialized properly.
PA will now be started from an XDG desktop file /etc/xdg/autostart/pulseaudio.desktop which will run a shell script start-pulseaudio-x11 which starts PA and registers the local session with XSMP to it.

So we can drop kde-settings-pulseaudio now? Because /etc/xdg/autostart is also read by KDE.

I'm not sure why we aren't using /etc/xdg/autostart for PA at the moment, maybe because it was getting started after aRts in F8? Hopefully that shouldn't be an issue anymore in F9 and later, unless some of the KDE 3 systray applets are firing up aRts.

I guess we should try using /usr/share/autostart (or /etc/xdg/autostart with "OnlyShowIn=KDE;") in F9's kde-settings-pulseaudio. (I wouldn't touch F8 now though, the risk of it breaking aRts is too high.)

I don't really know what kde-settings-pulseaudio does.

But yes, the idea is that we have the same startup mechanism for all desktops, as long as they support XDG autostart. 

I hope that KDE runs XDG autostart programs after setting $SESSION_MANAGER. If that's the case then we should be comptible without any further change.

If it doesn't set SESSION_MANAGER not much is lost however, since CK support in PA does most of the stuff the XSMP would do anyway. So even if the XSMP module is not loaded because SESSION_MANAGER is not set nothing too bad should happen.

Having said this, of course it is much better if SESSION_MANAGER is set properly. And I would consider it a bug in KDE if it initializes XDG autostart without setting that env var first.

> I don't really know what kde-settings-pulseaudio does.

kde-settings-pulseaudio is what starts PA in KDE in Fedora 8 and 9. It contains a single file /etc/kde/env/pulseaudio.sh with the following contents:
#!/bin/sh

if [ -x /usr/bin/pulseaudio ]; then
  /usr/bin/pulseaudio -D
fi

The startkde script sources everything in /etc/kde/env before starting up ksmserver.


> I hope that KDE runs XDG autostart programs after setting $SESSION_MANAGER.
> If that's the case then we should be comptible without any further change.

Yes, /etc/xdg/autostart is run from within ksmserver, so it sees $SESSION_MANAGER. /etc/kde/env, however, is run before ksmserver is even started.


So I think kde-settings-pulseaudio can be dropped in F10, and that should solve the XSMP problems. I'm not sure what to do about F9 though (and I don't want to change F8, it's too risky a change this late in F8's lifecycle, due to the interaction with aRts).

(In reply to comment #25)

> So I think kde-settings-pulseaudio can be dropped in F10, and that should solve
> the XSMP problems. 

Yes, I think so too.

> I'm not sure what to do about F9 though (and I don't want to
> change F8, it's too risky a change this late in F8's lifecycle, due to the
> interaction with aRts).

I have no good either. If $SESSION_MANAGER isn't set while PA is started up, module-x11-xsmp will not load, regardless if you load it at PA's startup or afterwards. Not loading XSMP will cause PA to be forcibly terminated when X logs out. Doing that will result in lost settings in PA, like default device info and stuff (in newer pa we save those settings much earlier so this wouldn't apply anymore).

Hmm, is there a way you can tell KDE to call "pactl exit" before logging out? If so that would be a simple alternative the xsmp module.

I just dropped the /etc/kde/env/pulseaudio.sh hack from the Rawhide kde-settings-pulseaudio, it should no longer be needed now that PA autostarts through /etc/xdg/autostart.

I'm still not sure what to do with F9 though (would copying the /etc/xdg/autostart file from Rawhide and putting an OnlyShowIn=KDE; on it (or just copying it to /usr/share/autostart, which should have the exact same effect) work?), and I definitely won't change F8 now (because KDE 3 starts up aRts early, which IIRC was the exact reason why we set up PA to start that early (when we don't even have a session manager running yet), it was getting started too late for aRts to output to it otherwise).

Fixed in Rawhide now, we'll see what to do with this in F9.

Looks like this is actually a duplicate of bug 438284. A fix in PulseAudio was pushed in F9.

*** This bug has been marked as a duplicate of bug 438284 ***