Latest alsa-driver breaks sound

[DoctrSuSE]

Hey all, hoping someone can help shed some light:

I update all of my repositories daily. Something in the last update of

alsa-driver-kmp-default (1.0.20.20090528_2.6.27.21_0.1-3.1)
alsa-driver-unstable-kmp-default (1.0.20.20090528_2.6.27.21_0.1-2.1)

broke sound on my system (made the driver, snd-intel-hda, unloadable). The previous versions, 1.0.20.20090527* worked just fine.

Removing them re-enabled sound (still via alsa 1.0.20). So I guess my real question is... what are those RPMs for exactly? What parts of drivers or functionality are they providing that aren't otherwise available?

Do I want to find a way to have them installed again? I've had them installed and updated almost daily since I installed 11.1 late last year.

Aaaanyway, insight is appreciated.

For what it's worth, my sound card is picked up as a "82801I (ICH9 Family) HD Audio Controller" and is in my Gateway P-7805u FX.

Thanks.

Edit: Also, I think the sound a little bit "tinny" sounding now... but it could just be my imagination as I am looking for problems, lol.

[oldcpu]

Originally Posted by DoctrSuSE

I update all of my repositories daily.

If you are updating daily/regularly from the build service alsa git applications, then that is a bad idea.

Originally Posted by DoctrSuSE

Something in the last update of

alsa-driver-kmp-default (1.0.20.20090528_2.6.27.21_0.1-3.1)
alsa-driver-unstable-kmp-default (1.0.20.20090528_2.6.27.21_0.1-2.1)

broke sound on my system (made the driver, snd-intel-hda, unloadable). The previous versions, 1.0.20.20090527* worked just fine.

If you had both installed at once, you are luckly it worked before. You should NOT install both at once. Remove alsa-driver-unstable-kmp-default and re-install alsa-driver-kmp-default. Ensure the alsa-driver-unstable-kmp-default is NOT re-installed. Reboot afterward to unload previous modules and load new modules.

Originally Posted by DoctrSuSE

Removing them re-enabled sound (still via alsa 1.0.20). So I guess my real question is... what are those RPMs for exactly? What parts of drivers or functionality are they providing that aren't otherwise available?

They are NOT for daily updates.

They have cutting edge changes made to alsa by the SuSE-GmbH alsa packager (who is also an alsa developer). They have not been extensively tested, and they should not be updated daily. Only update regularly from that repos if it is your intention to do daily testing of 'alpha/beta' drivers for the SuSE-GmbH packagers / alsa developer. If such testing is not your intention, then daily updates is a really really really bad idea.

[Chrysantine]

Well they sort of have that "Unstable" in them, which one might imagine is a pretty obvious sign of things to come

[DoctrSuSE]

Originally Posted by oldcpu

If you are updating daily/regularly from the build service alsa git applications, then that is a bad idea.

I'm not sure I agree, I generally enjoy seeing all of the thousands of little changes in all of the packages on a daily basis... even if it means some things are constantly fluctuating as to their functionality and stability.

Originally Posted by oldcpu

If you had both installed at once, you are luckly it worked before. You should NOT install both at once. Remove alsa-driver-unstable-kmp-default and re-install alsa-driver-kmp-default. Ensure the alsa-driver-unstable-kmp-default is NOT re-installed. Reboot afterward to unload previous modules and load new modules.

Yeah, they're both in the recommended packages list so I guess I wasn't paying enough attention when YaST installed them both upon adding the repo and performing an update (verified this behavior just now for kicks). Makes sense that you should only have one. I figure it was fine because they have virtually the same file list, and I think you really only get whichever one happens to be installed second, heh.

Originally Posted by oldcpu

They are NOT for daily updates.

They have cutting edge changes made to alsa by the SuSE-GmbH alsa packager (who is also an alsa developer). They have not been extensively tested, and they should not be updated daily. Only update regularly from that repos if it is your intention to do daily testing of 'alpha/beta' drivers for the SuSE-GmbH packagers / alsa developer. If such testing is not your intention, then daily updates is a really really really bad idea.

Same as above... I am cool with the shakiness of such behavior, generally speaking.

Aaaanyway, so I get that they're updated and additional drivers versus what's in the kernel. I suppose they've just broken something in that driver.

I've already uninstalled both (as I said, that is how I was able to regain sound) and tried each of the RPMs on their own (stable and unstable) and neither work. I tried to find versions from 5-27 or earlier but still 1.0.20 and struck out so far (but only really looked briefly).

Ahh well, I still cannot figure out if the "tinnyness" is in my head or if it is really there, lol. I guess every couple of days I will try reinstalling the stable RPM and see if it works yet.

Edit: Oh, also... thanks for the response.

[DoctrSuSE]

Originally Posted by Chrysantine

Well they sort of have that "Unstable" in them, which one might imagine is a pretty obvious sign of things to come

Only one of them does, not both.

[oldcpu]

Originally Posted by DoctrSuSE

I'm not sure I agree, I generally enjoy seeing all of the thousands of little changes in all of the packages on a daily basis...

IMHO if that is the case, you should set up your software package manage to NOT delete the rpms after an installation, but rather keep them on your hard drive (you can later go and move or delete them manually at your leisure).

That way you have a working alsa rpm that you can roll back to.

From what I read now, you do not do that, and I definitely disagree with the approach you have adopted, as it is risky and puts in place nothing that I can see (ie keeping the last working rpm version) to mitigate the risk.

But each to their own.

... Best wishes in sorting this.

[DoctrSuSE]

Originally Posted by oldcpu

IMHO if that is the case, you should set up your software package manage to NOT delete the rpms after an installation, but rather keep them on your hard drive (you can later go and move or delete them manually at your leisure).

That way you have a working alsa rpm that you can roll back to.

Yeah, I agree that that would probably be a good idea.

Originally Posted by oldcpu

From what I read now, you do not do that, and I definitely disagree with the approach you have adopted, as it is risky and puts in place nothing that I can see (ie keeping the last working rpm version) to mitigate the risk.

Yeah, my way isn't for everyone, of course... but that's the beauty of choice, eh? Although, like I said, I do agree that I should consider keeping past RPM versions... just for the sake of convenience. The risk is not a big deal to me, I've never had a problem I couldn't figure out or work around in some manner. Even here, I still have sound, all is well... just don't have either of those RPMs installed.

Originally Posted by oldcpu

... Best wishes in sorting this.

Thanks for the feedback, sorry that my philosophy is not in line with yours, hehe. Not too much to sort out since I have sound and I have pretty much concluded that the "tinnyness" is all in my head after some testing. Maybe literally in my head, huh? haha.

Well, take care.

[oldcpu]

Originally Posted by DoctrSuSE

Thanks for the feedback, sorry that my philosophy is not in line with yours, hehe. Not too much to sort out since I have sound and I have pretty much concluded that the "tinnyness" is all in my head after some testing. Maybe literally in my head, huh?

No worries. I think you are likely pretty knowledgeable in this, and I hope you stick around and contribute. We can definitely use knowledgeable users in sound , to help those less knowledgeable users whose PC's sound is not automatically configured upon installation.

[DoctrSuSE]

This seems to be what is happening with either of those RPMs installed... I am investigating the issue:

ALSA /usr/src/packages/BUILD/alsa-driver/pci/hda/../../alsa-kernel/pci/hda/hda_intel.c:2372: no codecs found!
HDA Intel 0000:00:1b.0: PCI INT A disabled

That happens anytime it tries to load the snd-hda-intel driver.

[oldcpu]

Originally Posted by DoctrSuSE

This seems to be what is happening with either of those RPMs installed... I am investigating the issue:

ALSA /usr/src/packages/BUILD/alsa-driver/pci/hda/../../alsa-kernel/pci/hda/hda_intel.c:2372: no codecs found!
HDA Intel 0000:00:1b.0: PCI INT A disabled

That happens anytime it tries to load the snd-hda-intel driver.

Is this from your dmesg? What hardware audio codec does your PC have?