Red Hat Bugzilla – Bug 124314
VIA sound card detected, but no sound
Last modified: 2015-01-04 17:06:18 EST
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 Description of problem: Just installed FC2. Everything works fine -- except I am not getting sound. I queried soundcard detection: the soundcard (VIA 8235, using kernel module snd-via82xx) is apparently detected, but when I play the test sound (KDE "soundcard detection"), all I get is static. My computer runs on an AMD Athlon XP-2200+ Before installing FC2, I had been running FC1 (and Redhat Linux 9) without any sound issues. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Boot computer 2. Run soundcard detection 3. soundcard detected, but no sound produced, just static ... no sound devices work Additional info: I don't know if this is a sndconfig problem or some other driver issue. Below is the lsmod: Module Size Used by snd_pcm_oss 40740 0 snd_mixer_oss 13824 1 snd_pcm_oss nls_cp437 5376 1 vfat 10496 1 fat 33472 1 vfat nfs 142912 1 nls_utf8 1536 2 udf 78596 0 snd_via82xx 19104 0 snd_pcm 68872 2 snd_pcm_oss,snd_via82xx snd_timer 17156 1 snd_pcm snd_ac97_codec 50436 1 snd_via82xx snd_page_alloc 7940 2 snd_via82xx,snd_pcm gameport 3328 1 snd_via82xx snd_mpu401_uart 4864 1 snd_via82xx snd_rawmidi 17184 1 snd_mpu401_uart snd_seq_device 6152 1 snd_rawmidi snd 38372 9 snd_pcm_oss,snd_mixer_oss,snd_via82xx,snd_pcm,snd_timer,snd_ac97_codec,snd_mpu401_uart,snd_rawmidi,snd_seq_device soundcore 6112 1 snd binfmt_misc 7176 1 nfsd 158496 9 exportfs 4224 1 nfsd lockd 47944 3 nfs,nfsd parport_pc 19392 1 lp 8236 0 parport 29640 2 parport_pc,lp autofs4 10624 0 sunrpc 101064 21 nfs,nfsd,lockd ppp_synctty 6016 0 ppp_async 8064 1 ppp_generic 20500 6 ppp_synctty,ppp_async slhc 5632 1 ppp_generic ipt_REJECT 4736 1 ipt_state 1536 1 ip_conntrack 24968 1 ipt_state iptable_filter 2048 1 ip_tables 13440 3 ipt_REJECT,ipt_state,iptable_filter via_rhine 15624 0 mii 3584 1 via_rhine floppy 47440 0 sg 27552 0 scsi_mod 91344 1 sg joydev 6976 0 dm_mod 33184 0 uhci_hcd 23708 0 ehci_hcd 21896 0 button 4504 0 battery 6924 0 asus_acpi 8472 0 ac 3340 0 ipv6 184288 12 ext3 102376 2 jbd 40216 1 ext3
By the way, I also installed FC2 onto my laptop (Toshiba, celeron, with Yamaha sound card) and got sound card, but no sound.
Here is some output when trying to start the artsd directly from the shell: ALSA lib pcm_hw.c:494:(snd_pcm_hw_start) SNDRV_PCM_IOCTL_START failed: Broken pipe ALSA lib pcm_hw.c:494:(snd_pcm_hw_start) SNDRV_PCM_IOCTL_START failed: Broken pipe Sometimes an additional message occurs first, stating that SNDDRV_PCM_IOCTL_PRESTART failed. It seems that this is causing the problems. Futhermore I have found that all the sound devices in /dev/ and /dev/snd have an odd security policy, that is, the owner is the single user I have created when first booting the system after installation and the group is set to root. I'd rather like it to be root/users with access modes set to 660 instead of 600 as it is now. Here is a sample output for /dev/sequencer and /dev/dsp crw------- 1 rts root 14, 3 23. Feb 22:02 /dev/dsp crw------- 1 rts root 14, 3 23. Feb 22:02 /dev/sequencer I wonder why you did that instead of crw-rw---- 1 root users 14, 3 23. Feb 22:02 /dev/dsp ? (Perhaps this needs to be relocated as another bug-report...)
Created attachment 100602 [details] output from artsd run from console plain text file of my artsd output from the console
Additional Comment #2 From Carsten Klein (carstenklein@yahoo.de) on 2004-05-26 14:25 > I wonder why you did that instead of > crw-rw---- 1 root users 14, 3 23. Feb 22:02 /dev/dsp Carsten: Thanks very much for the response. I am not clear about something, though: You asked why "I" did that? I didn't do anything beyond following the install sequence. Am I correct in reading your response as a solution/work-around? If so, can you give me some steps on how to go about this? (And please be as explicit as possible; I am not a programmer.) thanks, -j
Hi Jorge, sorry to be not so clear about who did what, I meant the people from redhat and fedora that made the security policy decisions when building the application that creates the non-root user on first start after the setup process. It really has nothing to do with (y)our problem, it is just something that struck my eye when checking the permissions on the device files in /dev. Besides that, as the user (rts, that is me) is the owner of the devices and he has both read and write priviledges being granted, everything should work fine, except when a different user than 'rts' (not root) tries to access the devices responsible for sound in- and output - in that case it will always fail as the user is not 'rts' and not in the 'root' group...but this is getting into too much detail here... As for our common problem with non-working sound daemon it seems that the problem is still somewhere else, and I hope that somebody more involved in the sound issue at either redhat or fedora will have a look at your initial bug-report. As for the output of your artsd run - most of the error message are due to a second arts daemon being already running in the background (you may check this using 'ps -A | grep artsd'). But the two lines that read : failed, are the same errors I get when trying to start artsd from the shell. I have not come up with a solution to the problem until now, I even tried to modify the modprobe.conf file to match the sample file given by VIA for RedHat 9.0, but to no avail (it is basically just some more entries (aliases) for sound services and so on).
Hi, that what I just wrote on ownership and permissions and such regarding the devices is simply not true. artsd is run in the context of the user starting the X-session and when artsd dynamically generates the required device files it assigns ownership to the user in whose context it was started. Forget what it says about permissions and ownership in the previous comments made by me. Must have been late. However, the other one is a real bug that I am also experiencing here... as does the original poster of the bug. I wonder if the above comments could be removed that display my total ignorance of the way things work in Linux ;-), in spite that I should have known better beforehand...hope my future employee does not read this ... and google does not index it...
The alsa via module supports 4 dxs channels, of which only one is active at a time. Use alsamixer to turn the dxs channel level up. It is muted by default.
Fedora Core 2 has now reached end of life, and no further updates will be provided by Red Hat. The Fedora legacy project will be producing further kernel updates for security problems only. If this bug has not been fixed in the latest Fedora Core 2 update kernel, please try to reproduce it under Fedora Core 3, and reopen if necessary, changing the product version accordingly. Thank you.