Input/output error when trying to use ossrecord

[igorzwx]

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.

[dogbertwrldrulr]

I did not see any ALSA files in my home dirctory and I found an ALSA directory in /etc and it was filled with a bunch of files (I can give you a complete list if it will help).

I get no audio whatsoever in or out of the card.

ossplay -vvvv gives the following:
Filelen = 19268
703.wav: Reading chunk fmt , size 16
FMT chunk: len = 16, fmt = 0x1
703.wav: Reading chunk data, size 19232
DATA chunk, Offs = 44, len = 0
Playing WAVE file 703.wav, 16 bits/mono/8000 Hz
Setup device S16_LE/1/8000
Time: 00:00.64 of 00:01.20 VU -------+ audio write: Input/output error

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.

[igorzwx]

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.

What do you mean by "clean install"?

You may try a simple test:

1. Boot Arch Linux LiveCD.
2. Remove PulseAudio
3. Download the closed source package of OSS4 (together with manual) and install it.
http://www.opensound.com/download.cgi

The (outdated) manual is here: viewtopic.php?f=3&t=3933&p=17359#p17316

[dogbertwrldrulr]

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. I then installed OSS4.2 and test it out, same issue.

Unfortunately we are stuck using CentOS, so i could run the test, but even it works, I cant use that distro for the final solution.

[igorzwx]

By a clean install I mean that we re-installed the OS from scratch.

That is why, perhaps, nothing works.

Unfortunately we are stuck using CentOS, so i could run the test, but even it works, I cant use that distro for the final solution.

You do not need to install anything on your computer. Just boot a LiveCD and make a test.

If you do not know what LiveCD is, you may ask for help on Ubuntu forum http://ubuntuforums.org/forumdisplay.php?f=326

we are stuck using CentOS

In this context, the word "we" seems to mean a kind of "secret esoteric society of CentOS fundamentalists". Right?

To avoid confusion, it might be reasonable to repeat the instruction:

You may try a simple test:

1. Boot Arch Linux LiveCD.
2. Remove PulseAudio
3. Download the closed source package of OSS4 (together with manual) and install it.
http://www.opensound.com/download.cgi

The (outdated) manual is here: viewtopic.php?f=3&t=3933&p=17359#p17316

[cesium]

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?

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).

[igorzwx]

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?

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#Install
If your user is not part of the audio group, add your user by:

Code: Select all

# gpasswd -a username audio

Code: Select all

$ man gpasswd

Maybe some SELinux permissions need to be set up?

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.

[dogbertwrldrulr]

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)

[cesium]

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...