no sound with oss4 in enemy territory

C

cabriofahrer

I don't get any sound with oss4 in linux-enemyterritory. The terminal shows the following message:

Code: 
------- sound initialization -------
/dev/dsp: Invalid argument
Could not mmap /dev/dsp
------------------------------------

The output of ls /dev/dsp* is:

Code: 
$ ls /dev/dsp*
/dev/dsp		/dev/dsp5		/dev/dsp_in
/dev/dsp0		/dev/dsp6		/dev/dsp_mmap
/dev/dsp1		/dev/dsp7		/dev/dsp_multich
/dev/dsp2		/dev/dsp8		/dev/dsp_out
/dev/dsp3		/dev/dsp9
/dev/dsp4		/dev/dsp_ac3

I also tried this, which I found in this forum, but it does not work either. Maybe that command doesn't apply to FreeBSD 8.1/Linux-base-f10 anymore?

Code: 
# sysctl hw.snd.compat_linux_mmap=1
sysctl: unknown oid 'hw.snd.compat_linux_mmap'
 
My solution to make sound work with flash is setting up libasound stuff in /compat/linux:
Code: 
wget download.fedora.redhat.com/pub/fedora/linux/updates/11/i386/alsa-lib-1.0.23-1.fc11.i586.rpm
rpm2cpio alsa-lib-1.0.23-1.fc11.i586.rpm | cpio -idm
cp -R user/ /compat/linux/user/
cp -R lib/ /compat/linux/lib/
cp -R etc/ /compat/linux/etc/
 
I posted this problem on the 4Front forums as I hit it with RTCW on Linux a while back. Turns out that OSS4 doesn't support mmap :-)
 
adamk said:
I posted this problem on the 4Front forums as I hit it with RTCW on Linux a while back. Turns out that OSS4 doesn't support mmap :-)
Click to expand...

Well, if so, I wouldn't put a smilie after that, because this is not funny at all.
Are those people at 4front aware of the problem?
Isn't there some workaround?
I don't like that driver anyway, because it cannot be controlled by gnome-volume-monitor or the kde-mixer, and I cannot get my microphone to work either. I would not even bother using this driver if the freebsd hda-driver worked on my laptop.
 
They are aware. I believe this was a conscious decision. My understanding is that this impacts a few rather old games, and supporting it for those few games would have been more hassle than it's worth. You could ask on the 4Front forums, of course, in case I'm remembering things incorrectly.

Adam
 
My understanding is that this impacts a few rather old games, and supporting it for those few games would have been more hassle than it's worth.
Click to expand...

Well, just happens to be that those "few rather old games" like QIII and so on are among the most played by users of open-source operating systems like Linux or FreeBSD.

Meanwhile I've found this (link was mentioned in a linux forum):

http://nullkey.ath.cx/et-sdl-sound/

Would this work for FreeBSD, too? (I'm on my windows-machine right now.^^)
 
Get verbose boot output via sysctl(8) tool:
# sysctl debug.bootverbose=1
Reload sound and snd_hda module using kldload(8) and kldunload(8):
# kldunload snd_hda && kldunload sound
# kldload sound && kldload snd_hda
Take console output:
# dmesg > /tmp/post_me_somewhere.txt
Upload relevant dmesg(8) output (in this case file above) somewhere.
Write new post in current thread with link to uploaded file.
 
Well, I'm trying to upload my dmesg output as a .txt-file, but this is the message that I get:

"dmesg-verbose.txt:
Your file of 29.1 KB bytes exceeds the forum's limit of 19.5 KB for this filetype."

So what should I do? I think a limitation of that kind for tiny .txt-files is a little exagerated...
 
Are you sure that you removed stuff not relevant to snd_hda?
There is plenty of other sites where you can upload text files.
 
richardpl said:
Are you sure that you removed stuff not relevant to snd_hda?
There is plenty of other sites where you can upload text files.
Click to expand...

Yes, I am. I commented out 'oss_enable="YES"' in my rc.conf and rebooted the machine. Then I kldloaded snd_hda. In the end I've uploaded a compressed file here.
 

Attachments

I will attempt to read snd_hda(4) and try to decipher something from verbose output you uploaded.

You could do the same. There is probably no need for constant rebooting - just modify/add hint values with kenv(8) and reload snd_hda(4) module.

Was it really hard to remove lines from dmesg output not relevant to this subject?

As you may already noticed I'm not paid here to help random posters - so do not expect anything from me.
 
Oh, I'm sorry, I misunderstood you then about what you meant by "removing everything not relevant to snd_hda". I thought this referred to removing oss4 first...
Well Thank you, but man snd_hda is a little over my level of understanding.
But in the dmesg output you will see something about "aborting" and all values to the jacks are "zero", which actually cannot be. Also note what other poeple wrote in the original thread about that. So I think snd_hda is somehow not capable of detecting the hardware properly. Therefore I doubt that man snd_hda can help.
 
I only see that all colors are unknovn. snd_hda(4) was unable to decipher anything and so all input/output stuff got disabled.

As was already mentioned in that thread start adding quirks for gpioX, same advice is in BUGS section of snd_hda(4)
 
Please help me out a little bit more here, as I don't know exactely what to do.
Should I try putting e.g.

Code: 
hint.hdac.0.config="gpio0"

in device.hints trying with different values for gpio from 0 to 7? Is the syntax even correct like that?
Or should it be

Code: 
hint.hdac.-1.config="gpio0"

because of

Code: 
# sysctl hw.snd.default_unit
hw.snd.default_unit: -1
?

Or what would you exactely put in device.hints in my case?
 
I can't help you if you can't help yourself.

I already mentioned that you do not need to reboot machine all the time and edit device.hints all the time - that is extremly boring and frustrating task.

Because you have only one sound card attached to you machine, it will have unit number 0, for example pcm0, and you also have only one hardware audio controller: hdac0.

Command # sysctl hw.snd.default_unit which you are constantly reapeating is useless at current stage, and looking at your dmesg output you should not care about it at all.

So hint should be set in a way similar to this:
# kenv hint.hdac.0.config="your home work"

And snd_hda(4) should be reloaded:
# kldunload snd_hda
# kldload snd_hda
 
Well, thank you so much for the rebooting hint first of all.
I tried to change all values for gpio from 0 to 7 as you advised, but that wouldn't change anything, verbose dmesg output would always be the same, also no mixer was available in /dev/.

I started thinking that maybe I could assign stuff in order to "override Bios-settings" as described in snd_hda (knowing that my problem is that the bios does not provide any useful settings to snd_hda at all) and see what happens. According to the dmesg output I thought that "nid24" would be the right thing to play with, as it appears several times listed and as "selected" in brackets. So it turned out that a

# kenv hint.hdac.0.cad0.nid24.config="as=1 seq=0"

would list a "mixer0" in /dev/, but I no sound yet.

I also tried with "nid29" as in the verbose dmesg output it said something about "speaker", but that didn't do the trick either.

Well, in the end a

# kenv hint.hdac.0.cad0.nid20.config="as=15 seq=15"

worked! I got sound on my laptop speakers and also when plugging in headphones into the headphone jack. Gnome-volume-control worked (without input, of course) and even enemy territory had sound right away.

Allright, this only works with "as=15" and "seq=15". Changing values here e.g "as=1" or "seq=0" does not work eihter. Why is that? Why does it work with "nid20"? What is it that I have really done here? Could you please give me an interpretation on this?

Also, the next thing I would like to do is configure my microphone. I've got a built-in microphone and a microphone jack also. Is any of the information provided by the dmesg output useful for that in any way?
 
I'm not developer/maintainer/contributor for snd_hda. And I never actually explored such code at all - maybe I would if I had problem.

I don't know anything about how this crappy hardware attaches and have not motivation to find out.

Try googling for people with similar microphone problem like your - I remmember reading something from mailing lists.

I had problem with VOIP in tremfusion - record volume was zero, so I could not yell at other gamers.
 
You must log in or register to reply here.
Back
Top