martouf 0 Posted August 27, 2004 gradually, the layers of the Vidalia are revealed.. I thought you were running FC2? not FC2+updates. ok, well, in that case choice #1 isn't available, exactly. Trying to get the job done with pre-packaged stuff and not build from source... You've compensated for me missing a vital cpio param, that's good, but my bad. You've copied the alsasound script to where it needs to be, that's good. You skipped the "Ensure init can find alsasound" part, not so good. ;( Plan A Rebooting won't do anything if init can't find the appropriate Sxxalsasound entry which will cause it to start up the sound system. 'S' is for 'S'tart and 'K' is for 'K'ill, and the 'xx' number is for sequencing. You can easily test just the alsasound script as root (here are examples): "/etc/init.d/alsasound start" "/etc/init.d/alsasound status" "/etc/init.d/alsasound stop" Double-clicking on a shell script file (hence the 'sh' abbr) won't necessarily do anything good. In this alsasound case, it's expecting a parameter. Make those entries for init, then (as root) "telinit 1". Once you've reached runlevel 1 (wait for it), then "telinit 5". If you want to save time waiting for X Windows to start, then "telinit 3". (how to test this stuff without rebooting) Plan B edit modprobe.conf, making changes only within the curly braces (the '{' and '}' chars). rip out the aumix stuff to put in the alsactl stuff in its place. ( don't forget to "cp /etc/modprobe.conf /etc/modprobe.conf.saved-just-in-case" before you start editing ) Share this post Link to post
Beej-in-GA 0 Posted August 29, 2004 Originally posted by martouf: Quote: gradually, the layers of the Vidalia are revealed.. I thought you were running FC2? not FC2+updates. ok, well, in that case choice #1 isn't available, exactly. Trying to get the job done with pre-packaged stuff and not build from source... You've compensated for me missing a vital cpio param, that's good, but my bad. You've copied the alsasound script to where it needs to be, that's good. You skipped the "Ensure init can find alsasound" part, not so good. ;( Plan A Rebooting won't do anything if init can't find the appropriate Sxxalsasound entry which will cause it to start up the sound system. 'S' is for 'S'tart and 'K' is for 'K'ill, and the 'xx' number is for sequencing. You can easily test just the alsasound script as root (here are examples): "/etc/init.d/alsasound start" "/etc/init.d/alsasound status" "/etc/init.d/alsasound stop" Double-clicking on a shell script file (hence the 'sh' abbr) won't necessarily do anything good. In this alsasound case, it's expecting a parameter. Make those entries for init, then (as root) "telinit 1". Once you've reached runlevel 1 (wait for it), then "telinit 5". If you want to save time waiting for X Windows to start, then "telinit 3". (how to test this stuff without rebooting) Plan B edit modprobe.conf, making changes only within the curly braces (the '{' and '}' chars). rip out the aumix stuff to put in the alsactl stuff in its place. ( don't forget to "cp /etc/modprobe.conf /etc/modprobe.conf.saved-just-in-case" before you start editing ) Hi Martouf, Sorry I thought I made it clear what kernel I was running. My Bad. Regarding Plan A: Which init file is it that I must edit, how do I edit it, and what is it that I should type? I assume that somewhere I have to put in the string "Sxxalsasound" but I don't know where and do use the XX or is there an actual number I should put instead? Regarding Plan B: I'll be switched if I can figure that file out. It looks to me like it tells something to start and then immediately tells it to ignore it. True? Do I get this right? If I take out the reference to the aumix stuff and put in "alsactl -F restore" between th { and } then that will work? Your friend, Beej Share this post Link to post
martouf 0 Posted August 29, 2004 guess I'm being as clear as the Savannah after a big rain storm.. Plan A needed your referring back to an earlier post.. the one with the Ensure init can find alsasound section in it.. no matter, though, I'll repeat it here: Ensure init can find alsasound To check to be sure all of the right file links have been made, do "find /etc/rc.d/rc* -name \*alsa\*". You should have pairs of files which look like "Sxxalsasound" and "Kxxalsasound" (where 'xx' are digits) in at least 'rc2.d', 'rc3.d' and 'rc5.d'. (the /etc/rc.d/rcX.d dirs correspond to init runlevels - see /etc/inittab for more info). If you need to create the links for init's benefit, then do: Quote: ln -sf /etc/init.d/alsasound /etc/rc2.d/S12alsasound ln -sf /etc/init.d/alsasound /etc/rc2.d/K10alsasound ln -sf /etc/init.d/alsasound /etc/rc3.d/S12alsasound ln -sf /etc/init.d/alsasound /etc/rc3.d/K10alsasound ln -sf /etc/init.d/alsasound /etc/rc5.d/S12alsasound ln -sf /etc/init.d/alsasound /etc/rc5.d/K10alsasound YMMV: might need to use /etc/rc.d/rcX.d/ instead. check before you attempt this. In Other Words If you run the 'find' command above, and don't find pairs of files with names like "[sK][0-9][0-9]alsasound" (in regexp form) then you'll need to create them using the 'ln' commands listed above. After they've been created, and only then, will the alsasound script be called by init when your system changes run levels and automatically start/stop your sound system. Still with me on this? as for the stuff in the curly braces, the ">/dev/null 2>&1" is confusing you? all that means is to redirect stdout to /dev/null and combine stdout and stderr. IOW: send any output it might generate to /dev/null. make it silent. but still do something - just prevent it being able to complain if it can't. Share this post Link to post
Beej-in-GA 0 Posted August 30, 2004 Originally posted by martouf: Quote: guess I'm being as clear as the Savannah after a big rain storm.. Plan A needed your referring back to an earlier post.. the one with the Ensure init can find alsasound section in it.. no matter, though, I'll repeat it here: Ensure init can find alsasound To check to be sure all of the right file links have been made, do "find /etc/rc.d/rc* -name \*alsa\*". You should have pairs of files which look like "Sxxalsasound" and "Kxxalsasound" (where 'xx' are digits) in at least 'rc2.d', 'rc3.d' and 'rc5.d'. (the /etc/rc.d/rcX.d dirs correspond to init runlevels - see /etc/inittab for more info). If you need to create the links for init's benefit, then do: Quote: ln -sf /etc/init.d/alsasound /etc/rc2.d/S12alsasound ln -sf /etc/init.d/alsasound /etc/rc2.d/K10alsasound ln -sf /etc/init.d/alsasound /etc/rc3.d/S12alsasound ln -sf /etc/init.d/alsasound /etc/rc3.d/K10alsasound ln -sf /etc/init.d/alsasound /etc/rc5.d/S12alsasound ln -sf /etc/init.d/alsasound /etc/rc5.d/K10alsasound YMMV: might need to use /etc/rc.d/rcX.d/ instead. check before you attempt this. In Other Words If you run the 'find' command above, and don't find pairs of files with names like "[sK][0-9][0-9]alsasound" (in regexp form) then you'll need to create them using the 'ln' commands listed above. After they've been created, and only then, will the alsasound script be called by init when your system changes run levels and automatically start/stop your sound system. Still with me on this? as for the stuff in the curly braces, the ">/dev/null 2>&1" is confusing you? all that means is to redirect stdout to /dev/null and combine stdout and stderr. IOW: send any output it might generate to /dev/null. make it silent. but still do something - just prevent it being able to complain if it can't. Hi Martouf, After reading your post, doing pennance by banging my head on the tiled concrete floor of my office, invoking the help of the computer Gods, and offering a Jolt/Coffee mix sacrifice to the Mother Goddess. I typed in the incantation you specified, and for good measure shook a bag of Dark Chocolate/almond nuggets at the cpu case. Then I tried the telinit test you provided and lo and behold it bloody WORKED!!!!!!!!!!!!!! I did do a second find out of curiosity and was rewarded with a long list of files. You expected as much, right? Now can you tell me what all that ln -sf stuff is? Oh and BTW, This problem is solved for this kernel. Do you think I will have to do it again for a future update of FC2? Thanks for your help and I am sorry that I took up so much of your time. You are ACES in my book! Best Regards, Beej Share this post Link to post
olagarde 0 Posted September 26, 2004 An interesting twist ... did a kitchen sink FC2 install, the audigy 2 zs is detected and cd player works, but alsa/mplayer/xmms/etc attempts, including the 'test' from the boxed "Soundcard Detection" result in a heavy buzz. No errors in the logs for the driver loads, module loads, device init, or access attempts. No indication that the kernel, drivers, oss/alsa subsystems, or applications have detected anything wrong. Also checked the alsa and vol mixers. And moved the dvd (holding the audio cd) from the audigy digital in to aux and cdin ports, no change. And checked for misplaced dev symlinks and/or oddly configured dev nodes in the various apps. And yes, it works just fine under win2k and os2/warp. Ideas appreciated .... Creative Audigy 2 ZS Tyan Tiger MPX S2466 Athelon MP 2800+ dual Fedora Core 2 plus bits (below) alsa-utils-1.0.3-1 alsa-lib-1.0.3a-2 Module Size Used by snd_pcm_oss 45220 0 snd_mixer_oss 17792 3 snd_pcm_oss snd_emu10k1 77572 3 snd_rawmidi 21792 1 snd_emu10k1 snd_pcm 76420 2 snd_pcm_oss,snd_emu10k1 snd_timer 22404 1 snd_pcm snd_seq_device 10120 2 snd_emu10k1,snd_rawmidi snd_ac97_codec 54916 1 snd_emu10k1 snd_page_alloc 12036 2 snd_emu10k1,snd_pcm snd_util_mem 7168 1 snd_emu10k1 snd_hwdep 10372 1 snd_emu10k1 snd 43876 12 snd_pcm_oss,snd_mixer_oss,snd_emu10k1,snd_rawmidi,snd_pcm,snd_timer,snd_seq_device,snd_ac97_codec,snd_util_mem,snd_hwdep soundcore 10336 3 snd Additional stuff I've added: ./tv/xaw/v4l-conf-3.73-0.i386.rpm ./tv/xaw/libquicktime-0.9.3-1.1.fc2.fr.i586.rpm ./tv/xaw/tv-fonts-1.1-0_3.rhfc2.at.noarch.rpm ./tv/xaw/zvbi-0.2.8-1.1.fc2.fr.i386.rpm ./tv/xaw/xawtv-3.93-15.rhfc2.at.i386.rpm ./tv/tvtime/tvtime-0.9.12-5.i386.rpm ./wine/wine-20040914-1fc2winehq.athlon.rpm ./tk/tk-devel-8.4.5-8.i386.rpm ./tk/tk-8.4.5-8.i386.rpm ./filesystem/kernel-ntfs-smp-2.6.5-1.358.i686.rpm ./graphics/freeglut-devel-2.2.0-0.11.fr.i386.rpm ./graphics/freeglut-2.2.0-0.11.fr.i386.rpm ./edonkey/edonkeyclc-1.0.2-1.i386.rpm ./edonkey/ed2k-gtk-gui-0.6.3-2.i386.rpm ./video/mplayer/mplayer-1.0-0.10.pre4.1.fc2.fr.i386.rpm ./video/mplayer/lirc-0.6.6-2.1.fc2.fr.i386.rpm ./video/mplayer/libpostproc-1.0-0.10.pre4.1.fc2.fr.i386.rpm ./video/mplayer/mplayer-fonts-1.1-2.fr.noarch.rpm ./video/mplayer/mplayer-skins-1.3-3.fr.noarch.rpm ./video/mplayer/lzo-1.08-3.1.fc2.fr.i386.rpm ./video/mplayer/faad2-2.0-1.1.fc2.fr.i386.rpm ./video/xine/libdvdplay-1.0.1-4.1.fc2.fr.i386.rpm ./video/xine/libdvdcss-1.2.8-4.1.fc2.fr.i386.rpm ./video/xine/libdvdread-0.9.4-5.1.fc2.fr.i386.rpm ./video/xine/libdvdcss-devel-1.2.8-4.1.fc2.fr.i386.rpm ./video/xine/libdvdread-devel-0.9.4-5.1.fc2.fr.i386.rpm ./video/xine/lame-3.96-1.1.fc2.fr.i386.rpm ./video/xine/libmad-0.15.1b-2.1.fc2.fr.i386.rpm ./video/xine/libdvdnav-devel-0.1.9-3.1.fc2.fr.i386.rpm ./video/xine/libdvdplay-devel-1.0.1-4.1.fc2.fr.i386.rpm ./video/xine/xine-0.99.1-1.1.fc2.fr.i386.rpm ./video/xine/xine-lib-devel-1.0.0-0.13.rc4a.1.fc2.fr.i386.rpm ./video/xine/xine-lib-1.0.0-0.13.rc4a.1.fc2.fr.i386.rpm ./video/xine/libdvdnav-0.1.9-3.1.fc2.fr.i386.rpm ./video/common/libfame-devel-0.9.1-1.1.fc2.fr.i386.rpm ./video/common/xvidcore-devel-1.0.0-1.1.fc2.fr.i386.rpm ./video/common/xvidcore-1.0.0-1.1.fc2.fr.i386.rpm ./video/common/aalib-1.4.0-5.1.fc2.fr.i386.rpm ./video/common/libfame-0.9.1-1.1.fc2.fr.i386.rpm ./video/common/aalib-devel-1.4.0-5.1.fc2.fr.i386.rpm Share this post Link to post
Spoilage 0 Posted October 2, 2004 I had a problem with my Audigy 2 ZS not working on Fedora Core 3 test 1 (Fedora Core version 2.90). The solution was to unplug my USB logitech 3000 webcam before booting my system. Share this post Link to post
