CS1.6 crashes after recent commits

[shoober420]

I update OpenAL from master regularly, almost daily. I noticed recently CS1.6 had been crashing. I thought it was an issue elsewhere, until I put my custom “asound.conf” in the /etc directory to disable all resampling from any audio source.

Upon placing it in /etc, CS1.6 launched successfully again. I’ll post my asound.conf when I get home.

So some background on this, CS1.6 sound files are native 22khz. My sound card, the ASUS Xonar Essence STX supports sample rates between 44.1khz-192khz. This leaves CS1.6 native 22khz files unsupported, meaning a reliance on resampling.

Using my asound.conf file with CS1.6 results in high pitched audio, because of mismatching sample rates. If I had a sound card that supported 22khz, I would be ok, but that’s not the case.

So when loading up CS1.6 without my asound.conf to disable resampling, CS1.6 now crashes. I must use my asound.conf no resample script to bypass OpenALs resampling and prevent from crashing.

I noticed there are some recent sample rate commits, I’m sure they are responsible. I’ve been meaning to mention this anyway.

Is there a way for OpenAL to take unsupported sample rates, 22khz in this case, and automatically resample to 44.1khz if need be, and make it an option? Of course if ones sound card supports said sample rate, then ignore the resample, hence making it an option.

[kcat]

I update OpenAL from master regularly, almost daily. I noticed recently CS1.6 had been crashing. I thought it was an issue elsewhere, until I put my custom “asound.conf” in the /etc directory to disable all resampling from any audio source.

asound.conf is for ALSA's device configuration. It shouldn't have much to do with a game unless something was preventing the game from accessing a device.

So some background on this, CS1.6 sound files are native 22khz. My sound card, the ASUS Xonar Essence STX supports sample rates between 44.1khz-192khz. This leaves CS1.6 native 22khz files unsupported, meaning a reliance on resampling.

That's completely normal. Most apps in the last 20 to 30 years that do their own mixing (and a number that don't) has had to rely on resampling their sounds. Even Doom from 1993 did resampling. The quality of the resampling can vary between apps, but they haven't been able to rely on outputting to specific sample rates for a quite a while now.

Is there a way for OpenAL to take unsupported sample rates, 22khz in this case, and automatically resample to 44.1khz if need be

It already does. When an app loads a sound, it tells OpenAL its sample rate, and OpenAL will resample it as needed for the output.

[shoober420]

@kcat

Yes, I know Quake does it too, well, at least the source ports incorporate a built in resampler. Funny thing is, GoldSrc doesn’t. If I use my asound.conf script which disables ALSA resampling systemd wide, GoldSrc will actually run at native 22khz, making the sound effects high pitched.

Where as Quake for example, with its built in resampler, which you can control via console, it’s uneffected. Are you saying this is an issue with GoldSrc? It’s just funny that recent OpenAL commits have caused CS1.6 to crash, and it’s the only game I can’t use my asound.conf file to disable ALSA resampling with.

I’m almost for certain GoldSrc relies on ALSA resampling and doesn’t have its own resampler.

[kcat]

Can you provide a backtrace for the crash? A trace log from OpenAL Soft (set the ALSOFT_LOGLEVEL environment variable to 3, to log to stderr)? Looking at the asound.conf may help to see what ALSA is being configured for.

I would assume also, you don't have PulseAudio installed?

[shoober420]

So I would say all the modern games I play, run native 44.1khz+. As for the classics, the source ports provide built in resamplers. This would be Quake and Doom for example, which will convert its 8khz or 22khz audio files to 44.1khz respectfully. I use tyrquake for the Quake (software mode), and Chocolate Doom for the Doom series.

GoldSrc seems to be the only engine which doesn't include a built in resampler. This may very well be my fault. I made a issue on the GoldSrc GitHub about native sound playback, which was granted. But, little did I know, my sound card didn't support 22khz, only 44.1khz-192khz.

I assumed 22khz would be supported. I was wrong. Although this card, which I thought was audiophile grade, isnt what I learned it to be at all (especially when it comes to the bit rate that is).

This card, as well as certain Soundblaster cards need a bit resampler, as they dont support TRUE 24bit audio. The 24bit audio files need resampled to 32bit. Very odd, and I feel RIPPED OFF AS FUCK.

Heres the contents of my asound.conf file. Bear in mind, I use an ASUS Xonar Essense STX card. Also, I should have mentioned that I'm not using Pulseaudio.

pcm.STX {
type hw
card "STX"
}

ctl.!default {
type hw
card "STX"
}

pcm.!default {
type plug
slave {
pcm "STX"
rate "unchanged"
}
}

I will post the logs later, I want to play some CS1.6 lolol

[kcat]

I assumed 22khz would be supported. I was wrong. Although this card, which I thought was audiophile grade, isnt what I learned it to be at all (especially when it comes to the bit rate that is).

In general, "audiophile grade" stuff tends to be normal stuff wrapped up in marketing, or stuff that's much higher priced than the quality improvement it actually provides. It can be difficult to find things that actually have better quality for an appropriate price. I will say, though, that if you're serious about getting top quality, don't get a sound card you plug into you motherboard; although relatively minor, they do have perceptible noise from electrical interference. Also, unless you're doing audio production work, it's useless to have anything above 48khz for playback.

This card, as well as certain Soundblaster cards need a bit resampler, as they dont support TRUE 24bit audio. The 24bit audio files need resampled to 32bit. Very odd

Not really that odd. 24-bit audio has the same issue as 24-bit video, namely it's packed inefficiently. Unless the app is just bit-copying the file data to the device (and not doing anything else, including mixing or applying gain adjustments), common processors can't efficiently deal with 24-bit samples since there's no native 3-byte type. Such samples have to be loaded into a 32-bit register to be worked on anyway, causing more work to read and write only 24 bits of them. A device that didn't accept 32-bit samples for 24-bit output would be the odd one (they no doubt exist, but wouldn't be nice to use from a program's perspective).

Heres the contents of my asound.conf file. Bear in mind, I use an ASUS Xonar Essense STX card. Also, I should have mentioned that I'm not using Pulseaudio.

I don't think this is doing what you expect. It's creating an "STX" pcm as a hardware device using the STX card. It's then defining the "default" pcm as a plugin device using the STX pcm as its output, setting the output device's rate to "unchanged". This doesn't prevent the resampler plugin from being used, as far as I can tell, just creating an STX pcm and overriding the default pcm to use it without changing the hardware rate.

[shoober420]

I have a lot of vinyl rips that are 96khz and 192khz, so serious audio playback is above redbook.

That’s interesting about the 24bit thing though. I never knew about that. I was looking at external DACs that support true 24bit audio playback, and 96/192khz. They exists for sure. I can see the method you described above to lazily support 24bit as a cheaper alternative for cheap DACs (adding eight zeros to the end of a 24bit stream).

Oddly enough, when I open alsamixer, with or without my asound.conf, STX is the default name for my PCM. Although I may change the “default” value to “front” and see what happens. That’s the setting I use in Deadbeef.

I can assure you this asound.conf does indeed disable ALSA resampling system wide.

[kcat]

I can see the method you described above to lazily support 24bit as a cheaper alternative for cheap DACs (adding eight zeros to the end of a 24bit stream).

Nothing "lazy" about it. In fact, the hardware has to do more work, however small; skip 1 byte for every 3. Supporting 32-bit samples isn't for the convenience of the card itself, but for the convenience of the host system that wants to give samples to the card (rather than make the program do more work to inefficiently generate and feed 24-bit samples to the card, the card can take 32-bit samples that the program more easily produced and simply ignore 8 bits of it). In the end, the 24 most significant bits are passed into the DAC and converted to an analog signal, covering the same exact dynamic range either way.

I can assure you this asound.conf does indeed disable ALSA resampling system wide.

Perhaps when using the "default" device I suppose. But certainly not when opening "plug:" or "plughw:"devices. Either way, it should have no bearing on OpenAL Soft, which should happily accept any (reasonable) sample rate ALSA says the card is using.

[shoober420]

Yes, I’m just saying that without my asound.conf no resampling script, CS1.6 crashes with the recent commits.

Although you explaining the script further, instigates me to tweak it to ensure optimal configuration.

I’ll post those OpenAL logs when I get home from work.

[shoober420]

Hey good sir, I just did a git pull from master, and your recent commits have fixed CS1.6 from crashing. Thank you very much. My apologize for not getting those logs posted, I’ve been busy as work.

I think I’m going to ask Valve to add a built in resampler, similar to what quakespasm/vkQuake does to remedy my asound.conf issue, so I can always leave it in the /etc directory, even if I play CS1.6.

Thanks again @kcat