Bug 2966

Hi,
I am using ALSA too and I cannot reproduce.

Is it still valid with the current Cauldron?

If yes, please tell what you get by typing: "alsamixer". It should be the same issue as above.

Also, could you attach the output of "lspci" and "lsmod" and are you using pulseaudio?

Cheers,
Chris.

CC: (none) => dirteat

Ok, cleaning my install I can indeed reproduce. That's what you said a wrong link in libalsa-data. I have fixed it.

Please wait the new libalsa-data-1.0.24.1-7.mga2 lands on the repos and reopen the bug if this still does not work.

Chris.

Status: NEW => RESOLVED
Resolution: (none) => FIXED

This is not the correct fix. I have reverted the patch for now.

The update-alternatives system is used to ensure that a valid file is picked and this link should then automatically flip from the alsa soundprofile to the pulse soundprofile automatically.

So the symlink should (and does) point to the "current" sound profile.

In the libalsa-data's %post script, you can see that it calls update-alternatives with a priority of 10. This should be sufficient to create the symlink for the "current" sound profile.

When experiencing this problem it would be interesting to know what the output of:

update-alternatives --display soundprofile

says.

Specifically it would be interesting to know where the /etc/sound/profile/current symlink points to (or if it even exists).

Draksound GUI for disabling pulseaudio will internally call update-alternatives for you, but I wonder if it is somehow breaking things on install?

If you remove (or do not install) the package "pulsaudio-client-config" then then an automatic alternatives (i.e. not manually set via draksound) should just flip happily between PA and non PA profiles.



For reference, on my system here:
[colin@jimmy alsa-plugins]$ update-alternatives --list soundprofile
/etc/sound/profiles/alsa
/etc/sound/profiles/pulse
[colin@jimmy alsa-plugins]$ update-alternatives --display soundprofile
soundprofile - status is auto.
 link currently points to /etc/sound/profiles/pulse
/etc/sound/profiles/alsa - priority 10
/etc/sound/profiles/pulse - priority 20
Current `best' version is /etc/sound/profiles/pulse.
[colin@jimmy alsa-plugins]$ ls -l /etc/sound/profiles
total 12
drwxr-xr-x 2 root root 4096 Oct 10 00:55 alsa/
lrwxrwxrwx 1 root root   30 May 14  2010 current -> /etc/alternatives/soundprofile/
drwxr-xr-x 2 root root 4096 Oct 20 18:24 pulse/
-rw-r--r-- 1 root root 1075 Sep 19 19:06 README
[colin@jimmy alsa-plugins]$ ls -l /etc/alternatives/soundprofile
lrwxrwxrwx 1 root root 25 Oct 20 18:25 /etc/alternatives/soundprofile -> /etc/sound/profiles/pulse/


I'm not sure what the specific problem is, but it could be related to draksound messing things up during install perhaps?

Not sure, but feel free to ping me on IRC to discuss further.

Status: RESOLVED => REOPENED
CC: (none) => mageia
Resolution: FIXED => (none)

I had a thought that it could have been due to setting the profile manually to PA, then removing the pulseaudio-client-config package which may have left things in a broken state.

But it seems update-alternatives is quite happy with that sequence of events:


[root@jimmy ~]# update-alternatives --set soundprofile /etc/sound/profiles/pulse
Using `/etc/sound/profiles/pulse' to provide `soundprofile'.
[root@jimmy ~]# update-alternatives --display soundprofile
soundprofile - status is manual.
 link currently points to /etc/sound/profiles/pulse
/etc/sound/profiles/alsa - priority 10
/etc/sound/profiles/pulse - priority 20
Current `best' version is /etc/sound/profiles/pulse.
[root@jimmy ~]# rpm -e --nodeps pulseaudio-client-config
Removing manually selected alternative - switching to auto mode
[root@jimmy ~]# update-alternatives --display soundprofile
soundprofile - status is auto.
 link currently points to /etc/sound/profiles/alsa
/etc/sound/profiles/alsa - priority 10
Current `best' version is /etc/sound/profiles/alsa.
[root@jimmy ~]# urpmi pulseaudio-client-config


    http://ftp.mandrivauser.de/mirrors/Mageia/distrib/cauldron/x86_64/media/core/release/pulseaudio-client-config-1.1-1.mga2.x86_64.rpm
installing pulseaudio-client-config-1.1-1.mga2.x86_64.rpm from /var/cache/urpmi/rpms                                                                                                  
Preparing...                     
      1/1: pulseaudio-client-config
                                 
[root@jimmy ~]# update-alternatives --display soundprofile
soundprofile - status is auto.
 link currently points to /etc/sound/profiles/pulse
/etc/sound/profiles/alsa - priority 10
/etc/sound/profiles/pulse - priority 20
Current `best' version is /etc/sound/profiles/pulse.


and all is well.

So no idea what is wrong, but this system has been in use for quite some time, so I don't think it's fundamentally flawed. I did change things not too long ago to do things differently in the alsa-lib side as an upstream patch which prevents us hacking it so much downstream, and this necessitated the empty file for the alsa-default.conf in the alsa sound profile, but this shouldn't be affecting things now.



The problem did exist in our package a while ago when this file was not present, but I fixed it in:
http://svnweb.mageia.org/packages/cauldron/libalsa2/current/SPECS/libalsa2.spec?r1=144501&r2=145632
which is before this bug was opened.

I can only presume that the original poster had the buggy package and had not updated his system for a while.

If you (Chris) can remember the sequence of events you went through to reproduce the bug that didn't require manually messing with the alternatives stuff, then please let us know!


All the best.

Hi Colin,
sorry for the mess, but still I don't undersand why my fix was not ok. In the spec file:

%{_sbindir}/update-alternatives \
  --install %{_sysconfdir}/sound/profiles/current %{alt_name} %{_sysconfdir}/sound/profiles/alsa %{alt_priority}

you run update alternative to install in etc/sound/profiles/alsa

while the link later is done from /etc/sound/profiles/current. So no chance it will work no?

ln -s %{_sysconfdir}/sound/profiles/current/alsa-default.conf %{buildroot}%{_datadir}/alsa/alsa.conf.d/99-default.conf


Sorry again, I am padawab :)

Sorry, I did not answer you last question. Yes indeed, to reproduce the bug I removed the pulseaudio-client-config package. So, as the reporter, the link was pointing to nothing.

Then I tried to force reinstall of libalsa-data with --replacepkg but it did not fix the pb.

No worries :)

Let me explain:

We have a system called "soundprofiles". This is a system such that you can easily reconfigure your system to use different approaches to sound output. At the momeent this basically boils down to alsa or PA (tho' there might be some jack profiles too for e.g. Sound Studio applications - I don't know).

So we have alsa and pulse profiles. These are stored in /etc/sound/profiles/alsa and /etc/sound/profiles/pulse respectively. One of them has to be the current profile the user has selected (or has been selected for them) The current profile will also be available via a symlink /etc/sound/profiles/current.

This means that the path /etc/sound/profiles/current/alsa-default.conf will change depending on which sound profile you have selected. You will either get the alsa-default.conf file from the alsa sound profile or the one from the pulse sound profile.

Now, all the files in the directory /usr/share/alsa/alsa.conf.d/ are parsed by alsa-lib when reading in it's config. This means that alsa-lib will autmatically read the appropriate alsa-default.conf file for the sound profile you have selected.

This is why the symlink MUST point to /etc/sound/profiles/current/alsa-default.conf


You changed the package such that the file ALWAYS pointed to the alsa-default.conf file from the alsa sound profile, regardless what profile the user picked via update-alternatives. This would have broken all sound output from alsa apps in the default configuration (which is to use pulseaudio).


So, going back to the problem, you need to find out what is wrong with your /etc/sound/profiles/current symlink and find out why it's not pointing to the alsa sound profile and thus why there is no file: /etc/sound/profiles/current/alsa-default.conf. This file should always be found regardless of which sound profile you pick (although it will of course be a different file, both profiles should have it).

If in doubt, post the output of the various update-alternatives --list and --display and the ls -l commands I included in my first comment and it'll hopefully point at what is wrong on your setup.

Like I say I don't think there is actually a bug here, just a result of either manual fiddling. The original bug I think was due to an outdated package (although it would have had to be about three weeks out of date when reported... no way to tell tho' as the reporter didn't include what package version they were using).

HTHs

(In reply to comment #6)
> Sorry, I did not answer you last question. Yes indeed, to reproduce the bug I
> removed the pulseaudio-client-config package. So, as the reporter, the link was
> pointing to nothing.
> 
> Then I tried to force reinstall of libalsa-data with --replacepkg but it did
> not fix the pb.

I tried that also in comment 4, but the result was that the alternatives system just worked.


[root@jimmy ~]# rpm -e --nodeps pulseaudio-client-config
Removing manually selected alternative - switching to auto mode

This then restored the link to the alsa sound profile.


I'll try a few more combinations here, but ultimately it smells like a problem in the alternatives scripts unless, you removed the rpm with the --noscripts option in which case it's expected to leave your system in a broken state.

Sorry for spamming, but I tried a all the combinations of removing the pulseaudio-client-config package (after running "update-alternative --set ..." for all combinations of auto, alsa and pulse) and the update alternatives scripts always worked properly and never resulted in a broken link.

If the link does break due to manual intervention then this command fixes it back up:
  update-alternatives --auto soundprofile

If you can work out a sequence of events that does cause the link to get broken, then I'd be interested in knowing what that sequence is.

Ooops. Thanks for the explanations CoMaster, I understand. In my (little) mind I reverted the meaning of "current" and "alsa" because the "current" supposedly created by update-alternative was indeed not there.

I'll try to reproduce again on my system and let you know.

Cheers

That's pulseaudio-client-config, not its removal, but install.

1) Remove everything related to sound (I got an almost empty distro :)

2) install alsa

everything is good:
>ll /etc/sound/profiles
 current -> /etc/alternatives/soundprofile/

>ls /etc/alternatives/soundprofile/
alsa-default.conf  profile.conf  snd-oss.conf

3) install pulseaudio-client-config

>ls /etc/alternatives/soundprofile/
profile.conf  snd-oss.conf

It is killing alsa-default.conf. I can have a look and report to you on IRC before actually screwing up again?

When it's failing at that last example (with the missing alsa-defaut.conf) what is the output of:

ls -l /etc/alternatives/soundprofile (note the lack of trailing /)
update-alternatives --display soundprofile
rpm -V pulseaudio-client-config
rpm -V libalsa-data

Actually the missing alsa-default.conf is likely due to the following package not being installed:
 alsa-plugins-pulse-config

This would be automatically installed by
 alsa-plugins-pulseaudio

But it's not required anywhere specifically.


Now the question is where to require this... perhaps in pulseaudio-client-config, but that might create some nasty circular deps....

Hmmm, interesting conundrum.

OK, I think a requires in pulseaudio-client-config on alsa-plugins-pulseaudio makes sense actually. Don't think there will be any specific problems as it already suggests it.

Note that the %mklibname bit is to ensure the right architecture of plugins is definitely installed rather than just the generic "alsa-plugins-pulseaudio" name which could be satisfied by 32 bit package on a 64 bit system.

Ok, I can do the modifs ?

However, even with this, the dependency are not enough for a working system. All progs (like play from sox or alsamixer still fail) due to missing
libalsa-plugins-pulseaudio and pulseaudio. But as far as I check, requiring dependencies to them will create loops.

Is is possible to add them as Suggests?

I think if pulseaudio-client-config required alsa-plugins-pulseaudio which in turn requires alsa-plugins-pulse-config, then all the deps are OK no?

So I *think* all that's needed is this:

Index: SPECS/pulseaudio.spec
===================================================================
--- SPECS/pulseaudio.spec	(revision 168918)
+++ SPECS/pulseaudio.spec	(working copy)
@@ -194,6 +194,7 @@
 %package client-config
 Summary: Client configuration for PulseAudio clients
 Group: System/Libraries
+Requires: alsa-plugins-pulseaudio
 Requires(post): ccp
 Requires(post): update-alternatives
 Requires(postun): update-alternatives


Or am I missing something? If you agree, feel free to commit.

Col

Ok, it is on the repos (I don't have the right to submit it to the bs though). So this should not happen anymore with new installs.

Now, for people having already the problem, either they don't want to use pulse at all and "urpme pulseaudio-client-config" should fix it. Or they want to use alsa under pulse and "urpmi alsa-plugins-pulseaudio" should fix it too I guess.

Do we close it?

Chris.

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

CC: (none) => krytarowski

Chris, did you get my mail about the svn propedits to fix up the changelogs?

If not here it is again:
> just done the modifs in alsa-plugins and pulseaudio, they are on the
> repos. Let me know if I screwed up.

Yeah both changes look fine, but there is no need for them to be SILENT
in the commit message - they are valid changes and solve a problem. You
should mention the bug # in the commit message too for future reference.

To fix up the messages, use:

svn propedit --revprop -r xxxx svn:log "Commit message"

Where xxxx is the commit revision number.

Once you've done that I'll push them to the build system

Sorry Colin, I missed your email. Job done, the logs should be ok now!

Cheers,
Chris.

OK, both pkgs pushed now too :)

Guess we can close, but we do still need to ensure that PA alsa-plugins are included in install... not quite sure why they were missed :s

Status: REOPENED => RESOLVED
Resolution: (none) => FIXED