[dr_lex (old)]

A bit of Googling later...
OK, the problem seems to be the VIA sound. But there is a workaround, next to either stripping the music from the pk3 files (which is a bad idea) or installing a PCI sound card:
http://www.accidenta...om_problems.php

Or in short:
1. Make sure you've got aRts installed. You'll soon know if you haven't.
2. Change your quake3 startup script (/usr/local/games/quake3 for me). Where it reads "./quake3.x86 $*" change it to to "artsdsp -m ./quake3.x86 $*"
3. Run 'artsd -F 6 -S 256', and keep it running...
4. Start Quake 3!

I squeezed the arts stuff in the quake3 script too, with a 'killall artsd' in front. In other words, this is my quake3 script:

#!/bin/sh
cd "/opt/quake3"
export LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:"
killall artsd                      #new
artsd -F 3 -S 256 &                #new
exec artsdsp -m ./quake3.x86 "$@"  #modified

As you can see, I lowered the value for -F (fragments), because I had the feeling there was some delay in the sound. 3 was the lowest value without crackling sound, but for your setup a higher value may be necessary.

Happy fragging!

[mitsubishi]

here it goes up to -F 2 -S 256 but only god knows the way that limit works. I get a different limit when running alsa or oss or another card on alsa or oss. or another kernel. whatever.. I usually run it only when I need it since it loads the cpu. I've realized the marginal delay of some msecs doesn't matter since, if you're playing and listening to an mp3 or talking to ts2 or whatever, it won't matter having some msecs delay, would it.

[dr_lex (old)]

[quote name='"fs"]I've realized the marginal delay of some msecs doesn't matter since' date=' if you're playing and listening to an mp3 or talking to ts2 or whatever, it won't matter having some msecs delay, would it.[/quote']
Yeah, and if you're using speakers, every ±30cm of distance between them and your ears introduces 1msec of delay anyway

[a BigRubberCock (old)]

Hey guys. I had a similar problem and solved it quite simply with the use of "q3jack"...

I made a quick post about it here:

http://www.forums.ur...opic.php?t=5319

Using this, I just played tonight for about 3 hours straight without any problems...and it did not require enabling / disabling direct access to the drivers by way of the sound config files under /proc.


Hope this helps

[a BigRubberCock (old)]

I'm guessing the problem at hand isn't a lack of alsa or oss drivers, but the fact that Q3 attemts direct hardware access via OSS --mmap

Pushing the sound through multiple driver layers that are processed in userspace can only create undesired latency in the sound and much more overhead in processing.

If you see the following at the beginning of your game session log, I recommend the q3jack over the other methods for both efficiency and ease of implementation:

------- sound initialization -------
Could not mmap dma buffer PROT_WRITE|PROT_READ
trying mmap PROT_WRITE (with associated better compatibility / less performance code)
/dev/dsp: Input/output error
Could not mmap /dev/dsp
------------------------------------

Cheers.