Hello qw people. =P
Could someone please help me? Thanks in advance.
I'm having some troubles with ezquake and ALSA sound... Already changed the s_devise value some times and snd_restart(ed), but got no luck. Here the problems I got:
With s_device set to "default" or "plug:hw" (this one is ezquake's default on my system): the sound is crackling and repeating a lot.
With s_device set to "hw:0,0" or "dmix", the sound quality is fine, but I got a delay of at least one second till it is played. I've tried to change s_mixahead but got no changes in the sound delay.

I'm no linux guru but most time I know my way around. But I don't know a shit of ALSA and those device names.

I'm using Ubuntu 7.04 and ezquake 1.8...

Just one observation about ezquake documentation: looks like most linux commands are missing there..

I had that too (10$ you have onboard sound too) and then used wine until I grabbed a cheap old Creative Soundblaster.

It would be really awesome if ezquake would use the same soundsystem like Darkplaces does, that one is übercompatible.

there's a simple hack you have to echo a statement to the procedure file, but I don't remember what was it :S

Try use OSS ,it is depricated and ALSA is much better project but Ez sux on ALSA and OSS works good .
Use this cmdline:
ezquake-gl.glx +set s_noalsa 1 +set s_device /dev/dsp +set s_khz 48

This way he wont be able to use software mixing.

With s_device set to "hw:0,0" or "dmix", the sound quality is fine, but I got a delay of at least one second till it is played. I've tried to change s_mixahead but got no changes in the sound delay.

did you try s_mixahead "0.02" or "0.002"? Please check and see (I had the similar problem until i learned i didn't try the proper values )

give http://wiki.qwdrama.com/Smooth_Quake#Linux a spin don't know what's the real problem thou.

" This way he wont be able to use software mixing. " - wrong he can change sound delay with s_mixahead and use my cmdline , default is 0.1 and it is working fine !

I experience the same problem (sound latency when using ALSA and dmix) with ezquake-gl.glx.

But I found quite a few good workarounds (the above mentioned suggestions to use OSS directly or to reduce s_mixahead are no good solution for me, because the former disables sound mixing and the latter (s_mixahead) doesn't work well enough to have virtually no lag!)

I just copy and paste now what I already wrote at the support request tracker for ezquake (sourceforge):


My article 1:

Using Alsa sound output and s_device dmix, I get an annoying sound delay, for instance when I shoot my gun its sound can still be heard for some fraction of a second, though I already no longer keep the trigger pressed down!

Using oss free (or Alsa's oss emulation) sound is okay for me, but then I lose sound mixing, which means that I cannot hear any other sounds while playing the game (sounds like instant messengers, e-mail notifications, or just background radio music etc.).

What I noticed, however, is that this doesn't seem to be a universal
problem with dmix, because other games (that allow for sdl sound output) (for instance: quakeforge) provide good sound and with no delay!
Setting SDL_AUDIODRIVER=alsa AUDIODEV=dmix in front of the quakeforge client command line makes sdl sound use alsa and dmix, while at the same time not having this alsa dmix sound delay issue.

Unfortunately, there is no SDL sound output for ezquake, or just better
alsa output (even without SDL).


I have two possible solutions/workarounds for this problem:
a) Using OSS-4 (4front's opensound system) which now became freely available does NOT have this sound lag problem! AND it permits soundmixing!

b) Due to some other problems with OSS-4, I simply run ezquake under Wine emulation (= the windows ezquake client under Wine). It works without sound delay AND with sound mixing enabled.


My article 2:

I tried a few more things:

a) If dmix gives too much sound lag in ezquake (the native Linux version, not the above mentioned way to run ezquake via Wine), you may try and edit your /usr/share/alsa/pcm/dmix.conf
I found that adding a (non-existant setting) buffer_size 2048 got rid of all sound lag in ezquake-gl.glx!

But it doesn't come without a drawback:
Now sound in mplayer and other audio applications can be slightly worse and susceptible to window switching, processor load etc.

So you could always edit dmix.conf before using ezquake and then using the original dmix.conf again!


But (apart from Wine, see above) I found a better solution which allows me to run this game natively in Linux:

b)
I just use the often bashed artsd sound daemon, which already in the past was very helpful to me when trying to run games years ago. artsd is still useful!
But back to the topic:
Just run artsd with real-time priority (artswrapper) and with a low number of fragments (option -F) and a low fragment size (option -S), for instance "6" for -F and "256 for -S.
In my case, I just use the KDE sound system with these settings (real-time priority, and the slider fully moved to the left).

Now I launch ezquake-gl.glx via artsdsp -m:

artsdsp -m ./ezquake-gl.glx +set s_noalsa 1 +set s_device "/dev/dsp"


Works like a charm for me! :-)
No more noticeable sound latency.

Hope, this helps some other Linux ezquake users.



Okay, would like to hear back from those suffering from this issue...

And I would still welcome development of better alsa output in ezquake (a better snd_alsa.c providing less sound latency, while at the same time not disabling sound mixing).


sempron

Do you mind writing exactly how to make this work.

I know how to setup alsa in kernel, but your userspace tool seems to be nice.

What solution are you especially interested in? :-)

I would suggest, try out opensound first.
Maybe you don't have the problems with a second sound card that I experienced. At any rate, the opensound solution works perfectly for my first (and primary) sound card.

And the latency is very low, lower than with artsd, I would say.

Go to www.opensound.com and download the stable 4.0 release.
Installation is quite easy and can easily be reversed, if you happen to dislike it...

If you have any further questions, I may be able to help you.

Meanwhile, I found even more good solutions:
Using the jackd sound server and oss2jack.
But installation can be somewhat tricky, you have to compile a kernel module (kfusd) and I had to tweak the sources a bit in order to get it compiled!


So, why not try opensound first?


Good luck
sempron


EDIT1:

If you just want to try out the artsd sound server workaround first...

Launch the KDE sound system, provided that you use KDE. Select "real-time priority" and move the slider completely to the left (getting the lowest latency).
If not, you have to install the artsd package.

Then, manually launch artsd like this:

artswrapper -F 6 -S 256 -u -a alsa -r 48000 &

Or just experiment with the paramters (especially F and S).


Launch ezquake-gl.glx via artsdsp -m:

artsdsp -m ezquake-gl.glx....


But anyway, try opensound first?
Tell me if it works for you, please.

I want to stick with alsa. Using OSS4 is NICE but that's _not_ what im looking for.

Alsa info:
alsa-lib-1.0.14a-i486-1
alsa-oss-1.0.14-i486-1
alsa-utils-1.0.14-i486-1
uname -a
Linux darkstar 2.6.21.5-vanilla #4 Wed Sep 5 16:23:50 Local time zone must be set--see zic manua i686 Intel(R) Pentium(R) M processor 1.50GHz GenuineIntel GNU/Linux

Lspci:

UPDATE:
raket@darkstar:~$ artswrapper -F 6 -S 256 -u -a alsa -r 48000
>> running as realtime process now (priority 50)

raket@darkstar:~/quake1$ artsdsp -m ./ezquake.x11 +set s_noalsa 1 +set s_device "/dev/dsp"


Still that 1 second sound delay (although - now sound doesnt sound fucked up)

hhhahahaha Linux and sound, will they ever fix it? It's so ridiculous so many people saying Linux is so nice but I see they still haven't fixed the problem of running software mixing on cheap-o sfx cards, why the hell even Windows 95 does the job?

BESIDES, why ever hack with laggy inefficient daemons when there's a simple fix you have to echo something into /proc/ of alsa's file giving access to ezQuake :|, I can't remember it anymore but it's surely somewhere

To repeat myself:

echo "ezquake.gl-glx 0 0 direct" > /proc/asound/card0/pcm0p/oss

is NOT an adequate solution!

You lose sound mixing if you do this.

Okay, if you don't care about background sounds (like instant messenger signals or new e-mail sounds etc.), you are free to do that, but I dislike it.


Sorry to hear that the artsdsp way doesn't work for some people; personally, it works quite well for me, but like I said, OSS4 is better (very much like windows latencies)...

So there is jackd which is well-known to have better (lower) latencies than artsd; unfortunately, you would have to use an older kernel in order to get oss2jack compiled! I still use kernel 2.6.16 for various reasons, the more recent kernels cannot be used with oss2jack.

But oss2jack is a very nice solution:
You can use any oss application (like quake3 or other games), make them talk to jackd and have really low latencies and good sound mixing.


But as to the above criticism of Linux:

This is not correct, the root of the problem is with inefficient alsa code in ezquake. I don't have any sound lag at all when I use other programs with ALSA, like aprq2 (very nice quake2 client). There is something seriously wrong in the alsa output of ezquake. Unfortunately, I wasn't able yet to mix the ezquake sources with alsa code from other games. But anyway, my solutions (oss2jack, artswrapper or oss4) DO work for me.


What also works like a charm
(seriously lacking good documentation - it took me quite some time to dig this out):

Use two different dmix.conf files and launch ezquake-gl.gx by using an environment variable:
ALSA_CONFIG_PATH=/usr/share/alsa/alsa-alternative.conf (or something like this).

alsa-alternative.conf is just a copy of alsa.conf, but you have to edit it to point at a different cards/aliases.conf

and:
aliases-alternative.conf is just a copy of aliases.conf that you also have to edit:
look for:
<confdir:pcm/dmix.conf>

and change it to:

<confdir:pcm/dmix-alternative.conf>

and finally:
dmix-alternative.conf is a copy of dmix.conf, but with a new entry:
buffer_size 2048

This overrides the default value (for me, at least) of 4096, and you will get no noticeable latency any more


So by setting an environment variable (ALSA_CONFIG_PATH) you are able to still keep your original dmix.conf and /usr/share/alsa tree, but you can use different configuration settings according to your needs.


I know that all this sounds like a lot of annoying work, but it is worth it.

This doesn't make one blind to the fact, however, (like I said) that the real problem is with ezquake's alsa code.


sempron

Yes, ezQuake'S sound code sucks. Darkplaces for example is a piece of cake (=works just fine) with sound in Linux. I have no mixing with ezQuake (and my "new" soundcard) yet, gotta try some of the great ideas in this thread somewhen.

gawksane: Stop trolling.

Actually, ezQuake is the only Quake client that has properly working sound for me, 'out-of-the-box'.

Which is just *part* of the reason that alsa sucks donky balls.
Personally I have found the exact oposite.

EZQuake 1754 has broken alsa support. It does not work on the majority of cards.
Alsa has broken oss support.

If ezquake 1754 does give you perfect sound in linux then you should consider yourself very lucky. If other engines don't work, then you need to upgrade your version of alsa (note that this will break ezquake1754...)

Following on from what sempron said, gnome users may find that esddsp works better than artsdsp.
Another alternative, it seems is to prefix your quake commandline with:
LD_PRELOAD=libaoss.so

Alsa is a joke. I really don't see how the various linux distributions came to use it (meaning oss is a defective pile of emulated poo that either crashes your application or simply pretends to implement features which just return errors).
The number of programs there are with a defective implementation of alsa should be considered a warning.
If they'd only updated the linux oss implementation instead of started alsa, then we would have a) more portable sound. b) more functional sound. c) less cpu intensive sound. d) lower latency sound. e) sound without added noise!


And using alsa directly, you gain 1 second latency, or loose sound mixing... Unless there's some secret undocumented device name that you're not telling me at least.

Just think, if you weren't required to have that security module, you could be using a version of quake with working sound!

For me, aoss ezquake-gl.glx (which is just like using LD_PRELOAD=libaoss.so) does not work, I get a segmentation fault.



Did you try any of my suggestions?

I don't get any relevant lag when using those methods, especially when using opensound-4 or oss2jack or when using a different dmix.conf via environment variable ALSA_CONFIG_PATH (with different buffer size and/or period size).

So whatever one can say about ALSA, the problem cannot solely be ALSA's fault, because there are other games that do not have this delay issue, out of the box - as I told you, aprq2 (quake2 client) does not have this problem for me.

If we can't hope for better ALSA code in ezquake, it should have SDL sound output, at least... Many times SDL saved me in the past, when I had problems with sound. Of course, SDL by itself only wraps around ALSA or OSS or openal etc. But it works quite well for me, usually.

Undoubtedly, it is sad that one has to use such more or less complicated tricks to get sound working all right...


sempron

Just curious...
Do you experience any kind of sound delay?
And I take it, you are using ALSA, right?


By the way, what about sound output in quakeforge, did you check those clients out (qw-client-glx, qw-client-sgl)?


sempron

This is how I did.

make a file in your home-directory with the name .asoundrc (note the dot) and put this in:


then you start ezQuake with +set s_khz 48 +set s_device default

"+set s_khz 48 +set s_device default" will fix the bad sound and the code in .asoundrc will fix the delay. It works for me...

disten, your .asoundrc works, of course. And it is one way to achieve good (low) sound latency.

But:
In my opinion, it is much better to use the environment variable (see above in my post) to call a different (alternative) dmix.conf.

Reason:
With your .asoundrc, you use a buffer size of 1024, which is good for ezquake, but which is less adequate for good sound output in general, like for web radio etc.
I also suppose that when switching from the GUI to a virtual text console and/or back you get minor sound stuttering issues when listening to music.

Using no .asoundrc at all (and you don't need one any longer with recent ALSA versions) you are not limited by its buffer size setting of 1024, but use a default setting of 2048 which gives better sound and sound that is less susceptible to console switching and processor load etc.

But if it works sufficiently well for you, it is okay, sure!

In my case, I much prefer the environment variable and I absolutely don't need an .asoundrc. Just pointing the environment variable at the corresponding dmix.conf does the trick for me (low latency sound in ezquake) while at the same time keeping a default buffer size setting for the rest of my computer needs (not using ezquake, but listening to music files, for instance).


Anyway, there are several ways to work around the real problem.
And I repeat myself once again:
ALSA by itself is not the real (or only) problem, because I get low delay sound output in other ALSA games (one example being darkplaces, which has as little sound lag as I get under Windows XP, while at the same time NOT disabling sound mixing!). So darkplaces and other games prove that it is possible to get good sound mixing and low latency even with ALSA.
The real problem must be ALSA code in ezquake.


Regards
sempron

I understand that this thread has been rather dead for a few years...
But the simplist fix for the issue in nQuake with the alsa lack of sound is to install the Aoss wrapper and execute your game with the aoss /usr/games/ezquake-gl.glx command.