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.
If you are updating daily/regularly from the build service alsa git applications, then that is a bad idea.
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.
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.
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.
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.
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.
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.
Yeah, I agree that that would probably be a good idea.
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.
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.
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.
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.
