A patch to fix the problem with popping audio under Linux

[NagaHuntress]

I've created a patch to fix the problem where audio would sometimes start popping/crackling when the game starts. And in the cosole this would be seen repeated:

snd_pcm_writei 4096 frames failed: Broken pipe

preparing audio device for output

I have a feeling that this fix is more of a kludge that works around the issue, rather than fixes it at the source. However, it does appear to work well enough to mask the problem.

Changes:
-If a call to snd_pcm_writei() returns an EPIPE error it will re-prepare the connection and then try to send the audio data again, but it will also try to send a partial duplicate. The number of frames duplicated is set by 's_alsa_underrun_extrafill'.


I've only tested it on Linux Mint 17.2, 64 bit.

 

tdm-linux-sound-fix.txt

[SteveL]

Is there any chance this is related to #4148 do you think? That happened a lot at map start, and randomly at other times. The bug is still in the current TDM 2.03 release, but it'll be fixed in the next version.

 

The bug was in the calculation of 3d sound propagation, so only happened during play. If your bug happens on menu screens, that'd be different. What the bug does is cause the result of a division-by-zero (a NaN) to be fed into the sound card.

[NagaHuntress]

No, it's an unrelated bug. This bug had a random chance of happening, but when it did, it would manifest immediately or within seconds of the game starting/restarting.

[NagaHuntress]

It's more likely to be related #4104 but their report doesn't mention if they tried playing past the title screen, as in my experience, the crackling/popping extened all other audio in the game and missions.

[OrbWeaver]

Good to see somebody working on the Linux issues. I suppose the "gold standard" solution to this issue would be to add full PulseAudio support (for better or worse, PA is now the standard on Linux desktops), but obviously that would require somebody with a lot of time and familiarity with PulseAudio client development.

[Tels]

In the patch, the CVAR added should be some sort of integer and capped to some sabe values, like mininum 256 (or something > 0) and maximum (4096?). Otherwise a wrong setting of that variable could cause havoc.

[NagaHuntress]

Hmm... you're correct in that there should be a minimum. The maximum is capped at how ever many frames are available, so at most it can only send double the amount of data available.

[Tels]

I forgot the specifics, but it is possible to declare CVARS as int (so nobody can set it to "4.5" or even "abc" and add min/max values.

[SteveL]

I forgot the specifics, but it is possible to declare CVARS as int (so nobody can set it to "4.5" or even "abc" and add min/max values.

CVAR_INTEGER in the flags. But I see from the tracker update that NagaHuntress got to it already.

[NagaHuntress]

I've figured out how to set the CVar as an integer and how to clamp it's range. I've uploaded a new patch to the bug tracker.

[SteveL]

Thanks again for another patch. Committed at rev 6529.

 

I can't test-compile code hidden from my MS system by compiler switches, but I'll ask grayman for the release packaging software so I can check the build works with any changes. I'm a bit clueless around OSes.

[Tels]

I've figured out how to set the CVar as an integer and how to clamp it's range. I've uploaded a new patch to the bug tracker.

 

Thank you kindly.

[Parker]

Thanx for your fix! Unfortunately I do not know how implement it (copy it somewhere I gues?!). Fortunately I found out that I have to switch my card to 44.1 Khz before starting the game. There're diferent ways to do that on Linux, so maybe that might help someone.

 

I use an E-MU1212m with a creative chipset and the emu10k1 driver, btw.