Can you provide output of:

lsmod | grep snd

and check to see if there are any relevant messages in "dmesg" output.

If in doubt just upload all of dmesg output.

lsmod | grep snd

snd_usb_audio         125670  0 
snd_usbmidi_lib        24952  1 snd_usb_audio
snd_rawmidi            30569  1 snd_usbmidi_lib
snd_seq_device         14497  1 snd_rawmidi
snd_hda_codec_realtek   145436  1 
snd_hda_intel          33293  3 
snd_hda_codec         126641  2 snd_hda_intel,snd_hda_codec_realtek
snd_hwdep              17659  2 snd_usb_audio,snd_hda_codec
snd_pcm               100893  4 snd_usb_audio,snd_hda_codec,snd_hda_intel
snd_page_alloc         18484  2 snd_pcm,snd_hda_intel
snd_timer              29532  1 snd_pcm
snd                    82658  15 snd_timer,snd_pcm,snd_seq_device,snd_rawmidi,snd_usbmidi_lib,snd_usb_audio,snd_hwdep,snd_hda_codec,snd_hda_intel,snd_hda_codec_realtek
soundcore              15047  1 snd
usbcore               206950  7 ehci_hcd,usbhid,gspca_main,gspca_ov534,snd_usbmidi_lib,snd_usb_audio

Created attachment 1964 [details]
Dmesg

Hmm, the sound card module looks loaded there which differs from your initial comment.

Can you explain what is wrong seeing as the module is loaded?

If it's simply that it's "not working" rather than "not loaded", can you instead attach the output of "aplay -L", "getfacl /dev/snd/pcm*", "loginctl", "ck-list-sessions" and "pacmd ls", all run as your regular user.

@Colin Guthrie

It looks like loaded, because i tried to load module. I'll paste lsmod | grep snd and DMESG after reboot.

W.


lsmod | grep snd
snd_usb_audio         125670  2 
snd_hwdep              17659  1 snd_usb_audio
snd_usbmidi_lib        24952  1 snd_usb_audio
snd_rawmidi            30569  1 snd_usbmidi_lib
snd_seq_dummy          12798  0 
snd_seq_oss            38288  0 
snd_seq_midi_event     14899  1 snd_seq_oss
snd_seq                65651  5 snd_seq_midi_event,snd_seq_oss,snd_seq_dummy
snd_seq_device         14497  4 snd_seq,snd_seq_oss,snd_seq_dummy,snd_rawmidi
snd_pcm_oss            53624  0 
snd_mixer_oss          22309  3 snd_pcm_oss
snd_pcm               100893  2 snd_pcm_oss,snd_usb_audio
snd_page_alloc         18484  1 snd_pcm
snd_timer              29532  2 snd_pcm,snd_seq
snd                    82658  12 snd_timer,snd_pcm,snd_mixer_oss,snd_pcm_oss,snd_seq_device,snd_seq,snd_seq_oss,snd_seq_dummy,snd_rawmidi,snd_usbmidi_lib,snd_hwdep,snd_usb_audio
soundcore              15047  3 snd
usbcore               206950  7 ehci_hcd,usbhid,gspca_main,gspca_ov534,snd_usbmidi_lib,snd_usb_audio

Created attachment 1970 [details]
DMESG

aplay -L
null
    Discard all samples (playback) or generate zero samples (capture)
pulse
    PulseAudio Sound Server



getfacl /dev/snd/pcm*
getfacl: UsuniÄcie wiodÄcego '/' ze Åcieżek bezwzglÄdnych
# file: dev/snd/pcmC0D0c
# owner: root
# group: audio
user::rw-
user:wojtulas:rw-
group::rw-
mask::rw-
other::---


ck-list-sessions
Session1:
        unix-user = '500'
        realname = 'Wojtulas'
        seat = 'Seat1'
        session-type = ''
        active = TRUE
        x11-display = ':0'
        x11-display-device = '/dev/tty1'
        display-device = ''
        remote-host-name = ''
        is-local = TRUE
        on-since = '2012-04-11T13:30:05.507985Z'
        login-session-id = '4294967295'

This has happened to me too after an update some time last Saturday (7th April)

I have tested with a system using snd-hda-intel and tonight I completed testing on a system with onboard via82xx and an exernal snd-emu10k1. This latter machine was first tried with the onboard sound disabled (normal for this m/c) and then with both sound cards enabled.

In every case the system boots with no soundcard modules loaded. They may be modprobed after boot and the sound will work.

In every case the soundcard modules are loaded during boot in the normal way if the /etc/modprobe.d/snd-oss.conf file is disabled/removed.

Richard

CC: (none) => richard.j.walker

I should add that /etc/modprobe.d/snd-oss.conf is /etc/sound/profiles/alsa/snd-oss.conf and thus contains:

install snd /sbin/modprobe --first-time --ignore-install --all snd snd_pcm_oss
snd_seq_oss snd_mixer_oss

This looks to be the same bug as https://bugs.mageia.org/show_bug.cgi?id=5285

Interesting Richard. This could be a change after switching to kmod rather than module-init-tools.

I've removed the snd_mixer_oss from the snd-oss.conf file as it is pulled in as a dep already of snd_pcm_oss. This makes the line complete without error for me, but I have to admit I wasn't able to reproduce the core problem.

That said, can you try with latest sound-scripts-0.62-3.mga2 (ensure the snd-oss.conf file is properly linked into modprobe.d folder again after manual tweaks!) and let me know if it solves the problem?

Status: NEW => ASSIGNED
Assignee: bugsquad => mageia

OK Colin, all updated. No change, That's the short version.
More in a moment. Need coffee.

R

I spent all night (and part of this morning) on the two-card m/c trying to nail down a suspicion that the precise order and content of .conf files in /etc/modprobe.d is significant. Two things started me thinking this:
(1) putting snd-hda-intel into /etc/modprobe.preload worked on the original test system
(2) transferring a working arrangement from the two-soundcard system back to the original test system failed
(3) the original system was working when I went to bed and wasn't working when I started up an hour or two ago.

I found that by re-ordering the .conf files and changing the number of options assigned to devices in .conf files and by adding/removing sound-slot-n entries in /etc/modprobe.conf it was possible to affect whether I would get sound on the next boot - but not in any predicable way. This suggests that the effect is time-senstitive, or more likely μ-time-sensitive.

For example, when I started this session sound was absent (only the snd_*_oss stuff was loaded). The modprobe.d directory had
00_modprobe.conf
01-snd-emu10k1.conf
03-snd-hda-intel.conf
blacklist-compat.conf
blacklist-mga.conf
ipw-no-associate.conf
lockd.drakx.conf
saa7134.conf
snd-via82xx.conf
@yy-snd-oss.conf
zz-snd-oss.conf

(The zz-snd-oss.conf is a local copy with the single line commented)
(The yy-snd-oss.conf is the renamed link to the active /etc/alternatives/soundprofile/snd-oss.conf)

To get it to work again on a cold machine I renamed the hda file to plain snd-hda-intel.conf and added a "beep_mode=1,0" option to it. The one-line file now reads:

options snd-hda-intel beep_mode=1,0 patch=hda-alc662-cdin.fw,hda-alc662-cdin.fw id=Mobo,Vobo index=0,1

(The second card is the hdmi on the graphics card - not used)

I then re-booted and got my sound back.

On reading your message I went hunting for a mirror with the updates and installed them. The only change I made was to remove my yy-snd-oss.conf leaving the new link (to /etc/sound/profiles/current/snd-oss.conf !). 

The re-boot was mute. I tried more tentative "tuning". I removed de-activating comments from 01-snd-emu10k1.conf and snd-via82xx.conf and re-linked to your new snd-oss.conf via /etc/alternatives.
The re-boot was with sound. Hooray!

Trouble is, I get the feeling if I look at it the wrong way when I next boot, it will be mute again.

What I need is a way to get some log message about the failure to activate the sound module and see what escuse it comes up with. Is there any way to make modprobe more verbose? Actually, that would likely slow things down enough for the module loadng to work :-)

Anyway, I'll test anything you throw at me.

Richard

Just for completeness, the current modprobe.d layout is:

00_modprobe.conf
01-snd-emu10k1.conf
blacklist-compat.conf
blacklist-mga.conf
ipw-no-associate.conf
lockd.drakx.conf
saa7134.conf
snd-hda-intel.conf
@snd-oss.conf
snd-via82xx.conf
zz-snd-oss.conf

R

Oh boy, is it fragile? Having completed the above report I set about transferring the "working" arrangement of module configurations to another Cauldron install. I am keeping the snd-oss.conf file active as its removal leaves a working system. Of course, it didn't work so I went back to tweaking the things I have become accustomed to tweak. The exception being that I removed the superfluous snd-mixer-oss from snd-oss.conf but did not yet fetch your updates. 

A few re-boots later I got it to work again and then updated ONLY the alsa-related stuff (leaving behind some apparently irrelevant updates):

lib64alsa-plugins-pulseaudio-1.0.25-3.mga2.x86_64 installed
alsa-plugins-pulse-config-1.0.25-3.mga2.noarch installed
timezone-6:2012c-1.mga2.x86_64 installed
lib64alsa-plugins-1.0.25-3.mga2.x86_64 installed
lib64alsa-plugins-jack-1.0.25-3.mga2.x86_64 installed
sound-scripts-0.62-3.mga2.noarch installed

After sorting out the extra snd-oss.conf entry in modprobe.d I re-booted and sound is again broken.

A few more tweaks and re-arrangements and eventually I get the sound back. It even survivs a second reboot! Then I installed the remaining updates (with the exception of lxdm and lxdm-theme-mageia, but that is a whole other problem):

lib64mpg123_0-1.13.8-1.mga2.x86_64 installed
mpg123-1.13.8-1.mga2.x86_64 installed
lib64oxygen-gtk3-1:1.0.3-1.mga2.x86_64 installed
oxygen-gtk3-1:1.0.3-1.mga2.x86_64 installed
mpg123-jack-1.13.8-1.mga2.x86_64 installed
bootsplash-3.3.9-1.mga2.noarch installed
dracut-017-5.mga2.noarch installed
rsyslog-5.8.10-1.mga2.x86_64 installed
lib64SDL1.2_0-1.2.14-10.mga2.x86_64 installed
lib64oxygen-gtk-1.2.3-1.mga2.x86_64 installed
oxygen-gtk-1.2.3-1.mga2.x86_64 installed
lib64SDL-devel-1.2.14-10.mga2.x86_64 installed
gawk-4.0.1-1.mga2.x86_64 installed

I knew dracut was coming so I took the opportunity to remove an unused kernel-desktop then re-booted.

And that's where I am now. Soundlessly silent and really looking forward to another half-hour of re-booting while I find the new magic sequence.

Richard

PS. There is no excuse for "escuses" and "predicable" would normally be predictable, but the stupid speelchucker in my browser (?) keeps flagging me as an illiterate American ! So I tend to ignore red underlines - there are so many of them.

That was more than half an hour and I nearly resorted to deleting snd-oss.conf, but in the end it worked when I activated some option lines in an un-needed bt878.conf AND added snd-hda-intel to /etc/modprobe.preload.

I guess this means that there is still a way to go...
I hope I haven't hi-jacked Wojtulas bug. It would be invaluable to know how much of the above corresponds with his findings.

After I #modprobe snd_hda_intel and relog sound from Firefox work, but in skype, VLC and kde sounds don't work. In kcmshell4 default audio device (called "default") doesn't work. When I press "test" kde notification shows me Audio device default does not work.

I am no Pulseaudio expert, in fact I am not sure if I have ever actually used it for anything, but if your problem is like mine then I start to wonder a few things;

On my systems (tried two so far, one with two different installations so that makes three in total) removal of /etc.modprobe.d/snd-oss.conf results in the sound modules loading correctly on the next boot. The target of my /etc.modprobe.d/snd-oss.conf link is for a plain Alsa system. The Pulse add-on does not (I believe) load the oss modules, in fact it blacklists them.

If your problem matches mine in the significance of the odd modules being loaded then I suspect you are not using pulse on your kde desktop. I have discovered (to my chagrin) that many sound applications, not just KDE or Gnome oriented ones, are being shipped with a convenience preference for pulse (I hesitate to call it a "requirement" as I know of no applications which fail to function in the absence of pulse). Unless you take steps to reconfigure them to work with Alsa devices they will not just work out-of-the-box. 

The description of your difficulty with some applications suggests this might be the case; ie. You have disabled pulse, so you have the oss module-loading version of snd-oss.conf and consequent failure of the soundcard driver modules to load, and difficulty getting kde sound apps to work when you manually load the drivers.


O N  T H E  O T H E R  H A N D ....

If you are using pulse AND removing your snd-oss.conf file does not get the soundcard driver modules to load on boot, AND even with pulse running you still have difficulties with kde (etc) apps, then I might have hi-jacked your bug as we might have different causes for our problems.

Did you follow all that? I wrote it and I'm not sure if I do :~)

Pulse is certainly the default and lots of applications will simply not work without it these days and this will be a continuing trend. If you have a specific and valid reason not to use the default and recommended setup, then fair enough, but I would strongly recommend using PA (as I am upstream maintainer of PulseAudio, I doubt this comes as a surprise!).

However, I'd like to know exactly what causes this problem.

I'm wondering if the oss modules are somehow loaded via some other route and this modprobe approach is just prone to failure.

I wonder if we can simply use osspd under plain alsa too rather than the snd modules... this might solve the problem, but perhaps open others... probably not one for this time around. Also, I could just put a "; /bin/true" on to the end of the modprobe line in the snd-oss.conf file to mask any errors... that might be a better plan.

Can you test to see if the following in /etc/sound/profiles/alsa/snd-oss.conf works for you:

install snd /sbin/modprobe --first-time --ignore-install snd && (/sbin/modprobe --all snd_pcm_oss snd_seq_oss; /bin/true)


Cheers

Sorry I meant:

install snd /sbin/modprobe --first-time --ignore-install snd && { /sbin/modprobe
--all snd_pcm_oss snd_seq_oss; /bin/true }

I am glad you corrected that :) On the other hand I haven't a clue what the difference is :(
Installing some updates now so I'll re-boot a couple of times and try your mod.

R

OK, tried it a couple of times. The biggest difference is that lsmod | grep snd reveals only 1 Alsa module loaded : snd_page_alloc. Not sure why that loaded when nothing else did. Surely it only loads as a dependency of some other module; snd_pcm perhaps? Might there be other ways to get this one loaded?

There seems to be a syntax error somewhere, according to the command line errors I got when I tried to modprobe snd-hda-intel. Transcribing here:

[root@Tureen ~]# modprobe snd-hda-intel
sh: -c: line 1: syntax error: unexpected end of file
libkmod: command_do: Error running install command for snd
ERROR: could not insert 'snd_hda_intel': Operation not permitted
[root@Tureen ~]#

I have double-checked the snd-oss.conf file for typos - none found!

This should be correct syntax (all on one line):

install snd /sbin/modprobe --first-time --ignore-install snd && { /sbin/modprobe --all snd_pcm_oss snd_seq_oss; /bin/true; }

(note I've added a final ; after the true. Also the difference from before is in the type of brackets - curly braces, rather than normal parenthesis.

Col

Oh and if that doesn't work, try this:

install snd /sbin/modprobe --first-time --ignore-install snd && { /sbin/modprobe --all snd_pcm_oss snd_seq_oss || :; }

Now you're jest showin' off!

OK, that boot completed with sound running.
All sound modules loaded, including the oss ones.

What did that do? Fix the problem or hide it, or put it in the spotlight so we can see it better?

By the way, the version with the colon works just as well

Yeah, the colon version and the /bin/true version should have been equiv, just wasn't 100% sure of which syntax might work best.

So the general principle behind the change is that the installation of the snd module would not be held up or made problematic if the oss compatibility modules were somehow already loaded or pulled in as deps etc. So it separates out the two operations.

I'll go ahead and commit this change. Hopefully you'll end up with a clean system and no modprobe.preload left over to confirm all is working once the update makes it through (sound-scripts-0.62-4.mga2)

@Wojtulas: Can you confirm if you are using an ALSA or PulseAudio-based setup? (or simply if the fixes submitted above "just work" for you too?)

UPDATE

On the second hardware system with a Cauldron using your modified file I still cannot get one of the soundcards to initialise. Same symptoms as before; I can modprobe snd-via82xx from the command line to get it working.

More hardware info:

The onboard audio is snd-via82xx (AC97 so I give it index=1)
The pci card audio is snd-emu10k1 and is much more capable so it gets index=0
There is also saa7134_alsa, but it has always initialised. It is index=2

Hmmm, this gives me a thought.

I wonder if the problem further manifests itself when there are >1 sound cards. e.g. each module is loaded and tries to load "snd" but fails all except the first one.... thus basically one of the sound modules loads OK, but after that it fails.

We can work around this by simply removing the "--first-time" argument from the rule. It does mean we'll try and load the oss ones again too each time, but that should be silently ignored anyway. Can you test?


(as a side note regarding the index= argument, have you tried this alternative syntax for the ordering? https://bugs.mageia.org/show_bug.cgi?id=4688#c1 (obviously I typo'ed and used the word "options" twice - ignore one of them). It should work even when you have >1 card of the same driver (at least kinda!))

OK, up and running with two soundcards!

 Are we really doing this or is there really a ghost in the machine?

Email response problem - this didn't send so repeating it here. it goes between comments 32 and 33

Date: Tue, 17 Apr 2012 01:39:54 +0100
Subject: Re: [Bug 5329] Soundcard doesn't work after latest update
Straight away. Trouble is the 2-card system, after updating (including
 your soundscripts update) rebooted to complete silence! Neither card
 initialised - just the oss stuff.

 Removing --first-time and rebooting now

As to the slots= solution: It would probably work on a static installation for me too, but since I am passing other options to the modules it seems reasonable to keep all the "decisions" for a card in one place. Furthermore, I can have (do have) 4 sound card modprobe.d conf files with more than 1 index=0 and the cards actually present in the current machine will initialise correctly. Admittedly, there can still be an ordering issue if two different machines use different priorities for the same driver:-(

The Cauldron systems are on USB drives and can find themselves on a variety of hardware hosts.

Last thought for the night: Is there any way I can get more information in the log about what happens when hardware is detected and modules loaded?

(In reply to comment #33)
> OK, up and running with two soundcards!
> 
>  Are we really doing this or is there really a ghost in the machine?

So does this mean things are working? (I'm just wondering if you mean that two sound cards is a good thing - you've previously mentioned three, but I guess you might not be considering the saa as a "card" in the above sentence)

Correct - my sloppy bad. The TV card Alsa driver always loads - possibly because some benevolent agent always puts it it modprobe.preload. I now have Working sound on two hardware platforms, one with two sound cards + TV Alsa and the other with one sound card (on board).

The next thing I'll try is a USB Video/Sound capture device and one of those Maplins USB record players.

Later though - am at work now.

Richard

I've pushed the fix now, so this should be OK and I'll close this bug. Feel free to shout if this is not the case for you.

Thanks for helping debug.

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