cesium wrote:Maybe this is silly.. But do the symlinks to /dev/dsp* actually exist? Try running 'sudo ossdetect -d -v' followed by 'sudo ossdevlinks -v -r' to recreate all the symlinks. Also, try recording from the other pcmin*. and try comparing the ossmix output with the one from the old computer.

What is missing is a clear guide for installation and troubleshooting. Therefore, the users often fail to perform the simplest test and explain the results. This causes confusion and wasting of time.

Moreover, osstest does not report if it plays music or not, and, therefore, the hearing impaired may fail to understand whether playback works or not. This should be urgently fixed, because the number of Linux users is comparable with the number of the deaf.

You are correct, nothing works.Playback and record do not work even after a clean install.The card works with the same driver on a different HW setup.

The /dev/dsp links do exist and point correctly to the audio devices. I have tried the ossrecord directly from the devices in /dev/oss/oss_envy240/pcmin0-7.

The ossmix is identical to the old machine.

Other things we have noted that are different with this configuration are that both computers have an audio port on the video card (nVidia GTS450), but the old configuration (the one that works) doesnt have anything installed for it (lspci has it as an unknown device). The new configuration does have something installed for that device. We have yet to find a way to disable this device anywhere in CentOS. I also noted that the specific interrupt for this device is not getting any interrupts. If I run cat /proc/interrupts on the old config, I have thousands (or more depending on usage) of interrupts on a particular processor. The new configuration has 0's across the board for interrupts on that driver/device.

dogbertwrldrulr wrote:By a clean install I mean that we re-installed the OS from scratch. The install does automate our security lockdown on the system as well.

Security lockdown? Err.. what does it do? Maybe some SELinux permissions need to be set up?

dogbertwrldrulr wrote:Other things we have noted that are different with this configuration are that both computers have an audio port on the video card (nVidia GTS450), but the old configuration (the one that works) doesnt have anything installed for it (lspci has it as an unknown device). The new configuration does have something installed for that device. We have yet to find a way to disable this device anywhere in CentOS.

Hmmm.. the unknown device list in lspci got to do more with its pci id list than with what linux recognizes, so I suspect it's not a real difference. However, you could try booting to single user mode (add "single" to the boot loaders' command line), and testing there ('sudo modprobe -r nvidia nvidia_fb' if they are still present to be sure).

dogbertwrldrulr wrote:By a clean install I mean that we re-installed the OS from scratch. The install does automate our security lockdown on the system as well.

Security lockdown? Err.. what does it do? Maybe some SELinux permissions need to be set up?

dogbertwrldrulr wrote:Other things we have noted that are different with this configuration are that both computers have an audio port on the video card (nVidia GTS450), but the old configuration (the one that works) doesnt have anything installed for it (lspci has it as an unknown device). The new configuration does have something installed for that device. We have yet to find a way to disable this device anywhere in CentOS.

Hmmm.. the unknown device list in lspci got to do more with its pci id list than with what linux recognizes, so I suspect it's not a real difference. However, you could try booting to single user mode (add "single" to the boot loaders' command line), and testing there ('sudo modprobe -r nvidia nvidia_fb' if they are still present to be sure).

a kind of fundamentalist "security"...

https://wiki.archlinux.org/index.php/OSS#InstallIf your user is not part of the audio group, add your user by:

1. If it works with Arch LiveCD and does not work with CentOS, it might be a security problem, or else.

2. If the card is broken, it may not work with any LiveCD and any sound system.

3. If it is not clear whether the card is broken or not, it does not make much sense to consider any assumptions about "SELinux permissions" and any other mythology about "video cards", "hardware", and "mysterious CentOS problems".

4. In any case, it might be reasonable to create a special subforum for CentOS users and let them help each other to fix security settings and other exotic problems.

Our security lockdown is mostly for external type stuff like not letting in ssh/rsh connections. The rest is just package management and making sure we have the latest or its not installed at all.

I do have some additional information that I have found. It seems that in modern motherboards (at least Intel chipsets), that they did away with the links between the PCI bus and the processor and bridged it all through the PCI Express bus. For most applications that doesnt seem to matter, but I have found several issues where people complain about multimedia cards in the PCI slots that just dont work. It seems to be a problem with interrupt routing between the CPU and the rest of the bus. I have read a little bit about IntX emulation and MSI routing but I have no idea what they are or how they work. I do know that if I do an lspci -vv, I can see under the control section of my audio card that it lists DisINTx- as one of the parameters and that is not present on my configuration that works. Would you guys have any insight on how to swap or turn on/off INTx emulation or MSI routing?

I did try the "gpasswd -a username audio" to no effect. (and I did replace the username with my username)

Well, my onboard hdaudio has INTx- and DISINTx- too, and that doesn't prevent it from working. Then again, I do recall some drivers do fail with (actual) PCI-Express versions, so I dunno. Can you paste your kernel's .config? That must have changed during the upgrade...