This is a problem that is occurring with recent Wary builds, or more correctly recent builds from Woof.
I found out why. The pup_event backend code that loads the modules is taking longer to load the snd_* modules.
When /etc/init.d/10alsa executes, it runs 'lsmod' to test if any snd_* modules have loaded. Sometimes they have not yet loaded, and the code in 10alsa to unmute sound does not get run.
Testing Wary 097 booting from live-CD, I did not get the "woof woof" as sound was muted, and I traced this back to the test in '10alsa' -- no snd_* modules had loaded.
However, booting Wary 097 from a USB stick, I did get "woof woof".
I have implemented a solution, although I think this is a bad hack. In /etc/init.d/10alsa I have inserted some sleeps:
[ "`lsmod | grep '^snd_'`" = "" ] && sleep 0.5 #101113
[ "`lsmod | grep '^snd_'`" = "" ] && sleep 1 #101113
[ "`lsmod | grep '^snd_'`" = "" ] && sleep 3 #101113
if [ "`lsmod | grep '^snd_'`" != "" ];then
rm -f /var/lock/subsys/alsasound 2> /dev/null #or alsa will not start.
#sometimes these don't all load...
if [ ! -f /etc/asound.state ];then
#try and set all levels workable...
#set_mixers #in functions4puppy4
#101015 BK had to add ,0 after Front...
amixer -s -q <<EOF
set Master 75% unmute
set Master -12dB
set 'Master Mono' 75% unmute
set 'Master Mono' -12dB
set Front,0 75% unmute
set Front,0 -12dB
set PCM 90% unmute
set PCM 0dB
set Synth 90% unmute
set Synth 0dB
set CD 90% unmute
set CD 0dB
set Mic 0% mute
set PCM,1 90% unmute
set PCM,1 0dB
set Wave 100% unmute
set Music 100% unmute
set AC97 100% unmute
set 'Master Digital' 75% unmute
set DAC 90% unmute
set DAC -12dB
set DAC,0 90% unmute
set DAC,0 -12dB
set DAC,1 90% unmute
set DAC,1 -12dB
set Headphone 75% unmute
set Headphone -12dB
set Playback 100% unmute
set "SB Live Analog/Digital Output Jack" off
set "Audigy Analog/Digital Output Jack" off
It would probably be better to put in some code to wait for snd_* modules to complete loading in /etc/rc.d/rc.sysinit, as that is where I already have code that waits for USB and PCMCIA modules to complete loading.
But for now I have just done a quick fix.
Comments:Posted on 13 Nov 2010, 12:02 by BarryK
Grrrr, no woof woof
I rebuilt Wary 097 with the modified /etc/init.d/10alsa, burnt to CD, booted with "pfix=ram".
So, I thought great, I'll release this, upload to ibiblio.org. Which I did.
But then I tested again. Booted up live-CD with "pfix=ram", this time no "woof woof" ....aaaaargh!
After bootup, although no "woof woof" and 10alsa did not unmute, after bringing up the mixer I was able to unmute it.
So, althought Wary 097 is uploaded, I won't announce it. I want to experiment more with this ALSA problm, will probably upload 098 tonight.
Posted on 13 Nov 2010, 15:06 by Sage
...expediency might suggest 0.9.7.1 in case you run out of third line digits?
Posted on 13 Nov 2010, 16:32 by BarryK
I found that those sleeps that I have shown above, 0.5, 1, 3, are not enough. The snd_* modules are either already loaded, or take somewhat longer than 4.5 seconds after 10alsa starts.
The problem is, booting up on the same hardware, I should get consistent results, but I don't. Most of the time snd_* modules are loaded and 10alsa unmutes the sound, without needing those sleeps. But sometimes snd_* modules get delayed.
The problem is, I now can't make it happen. I have created another 10alsa with more sleeps and logging of what is happening, but now it is working, snd_* modules already loaded, every time I do a pfix=ram bootup.
...so, aaaaargh again!
Posted on 13 Nov 2010, 18:41 by 01micko
re Murphies Law
More sneaky reporting....
The video upgrade wizard does indeed select an appropriate driver for me now :) ... but wget only downloads the webpage with all the links to Wary pets from ibiblio.. http://distro.ibiblio.org/pub/linux/distributions/quirky/pet_packages-wary5/..so the variable mustn't be getting carried through.
Taking a look now.
Posted on 13 Nov 2010, 18:44 by Sage
Sound & fury
What happens if you switch off on-board sound and stick in a PCI sound card? Command routing and timing for on-board kit is not something I know anything about. Must admit to being lazy when running modern kit and just use the green sound plug on the board with an external amplifier. This is really dumb, despite most of the world doing it. The old Creative 128 PCI (or even ISA) sound card is always going to be the best option, whether one plugs the OP into speakers direct or the hi-fi. Maybe their timing differs; but that may not help apart from providing a guide to code mods?
If this issue continues to prove intractable, I can dig out a range of older HW and discrete sound cards to test any .iso s you want to send me (wrong guy to ask to add lines of code!). However, nearly all previous versions of P, W & Q didn't give any 'woof woof' problems unless you'd deliberately disabled it.
Posted on 13 Nov 2010, 18:57 by BarryK
Testing a special 097 CD with logging in /etc/init.d/10alsa, booting up on another PC that was previously giving problems with sound, sound now is un-muted and the log shows that the snd_* modules were not loaded, it did 'sleep 0.5' and on the next test snd_* modules were loaded.
I will test on more PCs.
Posted on 13 Nov 2010, 19:24 by BarryK
re wget problem
So, I got part way there!
Great if you could study the code and figure out why wget is getting the wrong information.
The code is at /usr/local/video_upgrade.
Posted on 13 Nov 2010, 19:49 by 01micko
re re wget problem
Ok, at line 70 there is an escape missing.. the $1 must be escaped or else we get PET="" in our /tmp/petupgradevideo.sh. That would affect everything. Whwn I added that escape char the driver downloaded and installed fine.. but (see next paragraph)
Another issue, nVidia specific, the driver nvidia-256.53-k188.8.131.52-w5.pet is catastrophic for me, even if I test X from xorgwizard. Just a black screen, no recovery. The driver I posted is Ok for me http://www.murga-linux.com/puppy/viewtopic.php?t=61763, but like I said, foe me. It does work for Jim1911, but he does have very similar hardware to me. Zigbert did post something but it seemed a little ambiguous to me. Your drive may well work for him.
Posted on 13 Nov 2010, 20:50 by 01micko
re re re wget problem
Ok, I'm now on my P3 with the Vanta nvidia card and the TI network card (I think you remember it ;) ). Sns connected with Ndiswrapper without a hitch, pfix=ram.
Same result with video_upgrade. Nothing, Added the backslash like so:
PET=\"\$1\" #ex: xorg_upgrade_intel-2.10.0-w5.pet
at line 70.
Upgrade, download and install worked perfectly.. I can probably run Compiz on this old bus now, :D .
Posted on 14 Nov 2010, 6:19 by BarryK
re re re re wget problem
Thanks so much for that!
I will leave the nVidia upgrade PETs as they are for now, see if anyone else complains about that 256* one.
...though, I wonder, if I did replace 256* PET, what else besides yours would be needed?
Posted on 14 Nov 2010, 11:15 by 01micko
re x5 wget problem
"..though, I wonder, if I did replace 256* PET, what else besides yours would be needed? "
I think there a 96.* version that supports MX400 and MX440 cards, and quite a few others. They were popular in their day. Then there is the 176 (?) version that covers in between. It's strange because 256 should work with my card. 260 is just the latest upgrade from 256 so all the same cards should be supported and perhaps some newer ones, not sure.
Posted on 14 Nov 2010, 14:23 by Sage
Yes, 01micko, I see a lot of MX400 cards. They were very popular and are still about. They seem unbreakable and work with most kit. I keep some for testing when all else fails. Chasing one's tail with some of the junk, ATI or nV, soldered onto the board is a recipe for a headache. When on-board video was introduced way back, it was only intended for proprietary rubbish to make more profit from those whose demands were modest. Anyone with nouse would switch it off and stick in a proper card or most likely build their own box from respectable parts.
Having said all that, I cannot get a picture on my TV with any driver in recent Wary, Q & P from my on-board chip except using NOP & VESA. Suppose I'll have to take my own advice...