pulseaudio backend doesn't cure crashes

Bugs that have been investigated and resolved somehow.

Moderator: GZDoom Developers

Forum rules
Please don't bump threads here if you have a problem - it will often be forgotten about if you do. Instead, make a new thread here.
Post Reply
elbeardmorez
Posts: 4
Joined: Mon May 31, 2010 2:16 pm

pulseaudio backend doesn't cure crashes

Post by elbeardmorez »

Hi,

http://www.fmod.org/forum/viewtopic.php?p=45879#45879

I've posted some backtraces to crashes in gzdoom which point to libfmodex.so as the culprit. I switched to gzdoom (v1.4.08) today in my quest to play doom again due to the painful SDL input lags that occur with vanilla zdoom. Regardless, this issue is about sound, which affected vanilla and the gl port identically.

I run a pulseaudio server and have a 3-box slackware lan. The box in question does not host the server, it is a client. There are three ways that audio SHOULD work seemlessly on linux using a pulse audio client - oss emulation, alsa-pulse plugin, and now, as per FMOD v4.31.03 development version, the new pulseaudio backend (see trivial patch below). None work correctly for me.

zdoom v2.4.1 built against FMOD v4.28.06 ..no sound at all with ANY setup
zdoom v2.4.1 built against FMOD v4.30.04 ..doesn't build
zdoom svn-r2344-2010May29 built against FMOD v4.30.04 ..OSS / ALSA issue
zdoom svn-r2344-2010May29 + PulseAudio patch built against FMOD v4.31.03 ..OSS / ALSA / PULSEAUDIO issue
In each instance the stream is initiated and works CORRECTLY, playing both music and menu sfx. However, when a new game is started, although the music continues to play fine, the first instance of a sound effect (the sound doesn't play but i'm expecting a gunshot!) consistently causes a segmentation fault.
I imagine if any FMOD developer answers the above thread they'll probably point to your implementation (Randy?!). I've faffed with every snd_ related setting available, and disabled any reverb options i can see, but i'm not sure how to progress given that i can't break into the FMOD source in a gdb session. The only question i can think to ask here, is:

why would SFX such as 'cycling a menu' work fine, and yet an in-game SFX like 'a gunshot' cause a segfault?

Any thoughts or suggestions?

Cheers.

pulseaudio patch

Code: Select all

diff -u -r svn-r2344-2010May29/src/m_options.cpp mod/src/m_options.cpp
--- svn-r2344-2010May29/src/m_options.cpp	2010-05-29 19:31:16.000000000 +0100
+++ mod/src/m_options.cpp	2010-05-31 19:51:50.000000000 +0100
@@ -1216,6 +1218,7 @@
 	{ "OpenAL",			"OpenAL (very beta)" },
 #elif defined(unix)
 	{ "OSS",			"OSS" },
+	{ "PULSEAUDIO",			"PULSEAUDIO" },
 	{ "ALSA",			"ALSA" },
 	{ "SDL",			"SDL" },
 	{ "ESD",			"ESD" },
diff -u -r svn-r2344-2010May29/src/sound/fmodsound.cpp mod/src/sound/fmodsound.cpp
--- svn-r2344-2010May29/src/sound/fmodsound.cpp	2010-05-29 19:31:16.000000000 +0100
+++ mod/src/sound/fmodsound.cpp	2010-05-31 19:52:08.000000000 +0100
@@ -162,6 +162,7 @@
 
 	// Linux
 	{ "OSS",					FMOD_OUTPUTTYPE_OSS },
+	{ "PULSEAUDIO",					FMOD_OUTPUTTYPE_PULSEAUDIO },
 	{ "ALSA",					FMOD_OUTPUTTYPE_ALSA },
 	{ "ESD",					FMOD_OUTPUTTYPE_ESD },
 	{ "SDL",					666 },
@@ -435,7 +436,7 @@
 			Owner->Sys->setStreamBufferSize(16*1024, FMOD_TIMEUNIT_RAWBYTES);
 			return result != FMOD_OK;
 		}
-		if (JustStarted && openstate == FMOD_OPENSTATE_STREAMING)
+		if (JustStarted && openstate == FMOD_OPENSTATE_PLAYING)
 		{
 			JustStarted = false;
 		}
@@ -486,7 +487,7 @@
 
 		if (FMOD_OK == Stream->getOpenState(&openstate, &percentbuffered, &starving))
 		{
-			stats = (openstate <= FMOD_OPENSTATE_STREAMING ? OpenStateNames[openstate] : "Unknown state");
+			stats = (openstate <= FMOD_OPENSTATE_PLAYING ? OpenStateNames[openstate] : "Unknown state");
 			stats.AppendFormat(",%3d%% buffered, %s", percentbuffered, starving ? "Starving" : "Well-fed");
 		}
 		if (Channel == NULL)
backtraces etc


#pulseaudio server produces an unhelpful buffer underrun error

>>>
>>>
>>> I: module-suspend-on-idle.c: Sink sblive51 idle for too long, suspending ...
D: sink.c: Suspend cause of sink sblive51 is 0x0004, suspending
I: alsa-sink.c: Device suspended...
I: client.c: Created 4 "Native client (TCP/IP client from 10.0.0.2:44520)"
I: protocol-native.c: Client authenticated anonymously.
D: protocol-native.c: Protocol version: remote 16, local 16
D: protocol-native.c: SHM possible: no
D: protocol-native.c: Negotiated SHM: no
D: module-augment-properties.c: Looking for .desktop file for gzdoom
I: client.c: Freed 4 "FMOD Ex Enumerator"
I: protocol-native.c: Connection died.
I: client.c: Created 5 "Native client (TCP/IP client from 10.0.0.2:44521)"
I: protocol-native.c: Client authenticated anonymously.
D: protocol-native.c: Protocol version: remote 16, local 16
D: protocol-native.c: SHM possible: no
D: protocol-native.c: Negotiated SHM: no
D: module-augment-properties.c: Looking for .desktop file for gzdoom
I: client.c: Freed 5 "FMOD Ex Enumerator"
I: protocol-native.c: Connection died.
I: client.c: Created 6 "Native client (TCP/IP client from 10.0.0.2:44522)"
I: protocol-native.c: Client authenticated anonymously.
D: protocol-native.c: Protocol version: remote 16, local 16
D: protocol-native.c: SHM possible: no
D: protocol-native.c: Negotiated SHM: no
D: module-augment-properties.c: Looking for .desktop file for gzdoom
D: module-stream-restore.c: Not restoring device for stream
sink-input-by-application-name:FMOD Ex App, because already set.
D: sink.c: Suspend cause of sink sblive51 is 0x0000, resuming
I: alsa-sink.c: Trying resume...
D: alsa-util.c: Maximum hw buffer size is 341 ms
D: alsa-util.c: Set buffer size first, period size second.
D: alsa-sink.c: hwbuf_unused=0
D: alsa-sink.c: setting avail_min=1
I: alsa-sink.c: Resumed successfully...
D: module-suspend-on-idle.c: Sink sblive51 becomes idle, timeout in 5 seconds.
I: alsa-sink.c: Starting playback.
I: (alsa-lib)pcm_hw.c: SNDRV_PCM_IOCTL_START failed
D: module-suspend-on-idle.c: Sink sblive51 becomes busy.
I: resampler.c: Forcing resampler 'copy', because of fixed, identical sample
rates.
D: resampler.c: Channel matrix:
D: resampler.c: I00 I01
D: resampler.c: +------------
D: resampler.c: O00 | 1.000 0.000
D: resampler.c: O01 | 0.000 1.000
D: resampler.c: O02 | 1.000 0.000
D: resampler.c: O03 | 0.000 1.000
D: resampler.c: O04 | 0.500 0.500
D: resampler.c: O05 | 0.000 0.000
I: remap.c: Using generic matrix remapping
I: resampler.c: Using resampler 'copy'
I: resampler.c: Using s16le as working format.
D: memblockq.c: memblockq requested: maxlength=33554432, tlength=0, base=12,
prebuf=0, minreq=1 maxrewind=0
D: memblockq.c: memblockq sanitized: maxlength=33554436, tlength=33554436,
base=12, prebuf=0, minreq=12 maxrewind=0
I: sink-input.c: Created input 1 "Mixer Stream" on sblive51 with sample spec
s16le 2ch 48000Hz and channel map front-left,front-right
I: sink-input.c: media.name = "Mixer Stream"
I: sink-input.c: application.name = "FMOD Ex App"
I: sink-input.c: native-protocol.peer = "TCP/IP client from 10.0.0.2:44522"
I: sink-input.c: native-protocol.version = "16"
I: sink-input.c: application.process.id = "3918"
I: sink-input.c: application.process.user = "root"
I: sink-input.c: application.process.host = "elservo"
I: sink-input.c: application.process.binary = "gzdoom"
I: sink-input.c: window.x11.display = ":1.0"
I: sink-input.c: application.language = "C"
I: sink-input.c: application.process.machine_id = "elservo"
I: sink-input.c: module-stream-restore.id =
"sink-input-by-application-name:FMOD Ex App"
I: protocol-native.c: Requested tlength=85.33 ms, minreq=10.67 ms
D: protocol-native.c: Adjust latency mode enabled, configuring sink latency to
half of overall latency.
D: memblockq.c: memblockq requested: maxlength=16384, tlength=23296, base=4,
prebuf=21252, minreq=2048 maxrewind=0
D: memblockq.c: memblockq sanitized: maxlength=16384, tlength=16384, base=4,
prebuf=14340, minreq=2048 maxrewind=0
I: protocol-native.c: Final latency 185.33 ms = 64.00 ms + 2*10.67 ms + 100.00
ms
D: protocol-native.c: max_request changed, trying to update from 16384 to 23296.
D: protocol-native.c: Failed to increase tlength
D: core-subscribe.c: Dropped redundant event due to change event.
D: protocol-native.c: Requesting rewind due to end of underrun.
D: alsa-sink.c: Requested to rewind 57600 bytes.
D: alsa-sink.c: Limited to 57600 bytes.
D: alsa-sink.c: before: 4800
D: alsa-sink.c: after: 4244
D: alsa-sink.c: Rewound 50928 bytes.
D: sink.c: Processing rewind...
D: sink-input.c: Have to rewind 50928 bytes on render memblockq.
D: source.c: Processing rewind...
D: protocol-native.c: Underrun on 'Mixer Stream', 0 bytes in queue.
D: protocol-native.c: Requesting rewind due to end of underrun.
D: alsa-sink.c: Requested to rewind 8352 bytes.
D: alsa-sink.c: Limited to 8352 bytes.
D: alsa-sink.c: before: 696
D: alsa-sink.c: after: 696
D: alsa-sink.c: Rewound 8352 bytes.
D: sink.c: Processing rewind...
D: sink-input.c: Have to rewind 8352 bytes on render memblockq.
D: source.c: Processing rewind...

D: protocol-native.c: Underrun on 'Mixer Stream', 0 bytes in queue.

D: alsa-sink.c: Requested to rewind 57600 bytes.
D: alsa-sink.c: Limited to 57600 bytes.
D: alsa-sink.c: before: 4800
D: alsa-sink.c: after: 4296
D: alsa-sink.c: Rewound 51552 bytes.
D: sink.c: Processing rewind...
D: source.c: Processing rewind...
D: module-suspend-on-idle.c: Sink sblive51 becomes idle, timeout in 5 seconds.
D: module-suspend-on-idle.c: Sink sblive51 becomes idle, timeout in 5 seconds.
D: core.c: Hmm, no streams around, trying to vacuum.
I: sink-input.c: Freeing input 1 "Mixer Stream"
I: client.c: Freed 6 "FMOD Ex App"
I: protocol-native.c: Connection died.
I: module-suspend-on-idle.c: Sink sblive51 idle for too long, suspending ...
D: sink.c: Suspend cause of sink sblive51 is 0x0004, suspending
I: alsa-sink.c: Device suspended...


#gdb backtrace when attached to the segfaulted process AFTER the error! ..seems
to give different stack info this way

0xb7036a04 in __lll_lock_wait () from /lib/libpthread.so.0
(gdb) bt
#0 0xb7036a04 in __lll_lock_wait () from /lib/libpthread.so.0
#1 0xb7031fab in _L_lock_844 () from /lib/libpthread.so.0
#2 0xb7031e3b in pthread_mutex_lock () from /lib/libpthread.so.0
#3 0xb6e848ca in FMOD_OS_CriticalSection_Enter () from
/usr/local/lib/libfmodex.so
#4 0xb6e75737 in FMOD::SystemI::stopSound () from /usr/local/lib/libfmodex.so
#5 0xb6e68644 in FMOD::SampleSoftware::release () from
/usr/local/lib/libfmodex.so
#6 0xb6e6a3b3 in FMOD::Sound::release () from /usr/local/lib/libfmodex.so
#7 0x082afab1 in S_UnloadSound ()
#8 0x082a4308 in ?? ()
#9 0x08104abd in call_terms ()
#10 0xb6b6aeaf in exit () from /lib/libc.so.6
#11 0xb7469115 in ?? () from /usr/lib/libgdk-x11-2.0.so.0
#12 0x00000001 in ?? ()
#13 0xb749a418 in ?? () from /usr/lib/libgdk-x11-2.0.so.0
#14 0x086bb2f0 in ?? ()
#15 0x0000000b in ?? ()
#16 0x08bbbc30 in ?? ()
#17 0x08a0e5d8 in ?? ()
#18 0xb785fff4 in ?? () from /lib/ld-linux.so.2
#19 0xb6996024 in ?? () from /opt/xorg//lib/libX11.so.6
#20 0x00000005 in ?? ()
#21 0xb1410b28 in ?? ()
#22 0x08a0e5d8 in ?? ()
#23 0xb70a7538 in ?? () from /usr/local/lib/libSDL-1.2.so.0
#24 0x08bb9e50 in ?? ()
#25 0x00000000 in ?? ()

#gdb backtrace from PULSEAUDIO output segfault

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1322497168 (LWP 3455)]
0xb6a6adce in memset () from /lib/libc.so.6
#0 0xb6a6adce in memset () from /lib/libc.so.6
#1 0xb6cfdd8d in FMOD::DSPFilter::read () from /usr/local/lib/libfmodex.so
#2 0xb6cfd7c5 in FMOD::DSPFilter::read () from /usr/local/lib/libfmodex.so
#3 0xb6cfd7c5 in FMOD::DSPFilter::read () from /usr/local/lib/libfmodex.so
#4 0xb6cfd7c5 in FMOD::DSPFilter::read () from /usr/local/lib/libfmodex.so
#5 0xb6cfd7c5 in FMOD::DSPFilter::read () from /usr/local/lib/libfmodex.so
#6 0xb6d0530a in FMOD::DSPSoundCard::read () from /usr/local/lib/libfmodex.so
#7 0xb6d18011 in FMOD::Output::mix () from /usr/local/lib/libfmodex.so
#8 0xb6d3e2be in FMOD::OutputPulseAudio::updateMixer () from
/usr/local/lib/libfmodex.so
#9 0xb6d3706d in FMOD::Thread::callback () from /usr/local/lib/libfmodex.so
#10 0xb6ee39a0 in start_thread () from /lib/libpthread.so.0
#11 0xb6ace0de in clone () from /lib/libc.so.6
The program is running. Quit anyway (and detach it)? (y or n) Detaching from
program: /root/desktop/gzdoom/1.4.08.r811/
build/gzdoom, process 3452


#gdb backtrace from OSS output segfault

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1322247312 (LWP 3624)]
0xb6b24dce in memset () from /lib/libc.so.6
#0 0xb6b24dce in memset () from /lib/libc.so.6
#1 0xb6db8d8d in FMOD::DSPFilter::read () from /usr/local/lib/libfmodex.so
#2 0xb6db87c5 in FMOD::DSPFilter::read () from /usr/local/lib/libfmodex.so
#3 0xb6db87c5 in FMOD::DSPFilter::read () from /usr/local/lib/libfmodex.so
#4 0xb6db87c5 in FMOD::DSPFilter::read () from /usr/local/lib/libfmodex.so
#5 0xb6db87c5 in FMOD::DSPFilter::read () from /usr/local/lib/libfmodex.so
#6 0xb6dc030a in FMOD::DSPSoundCard::read () from /usr/local/lib/libfmodex.so
#7 0xb6dd3011 in FMOD::Output::mix () from /usr/local/lib/libfmodex.so
#8 0xb6df5c26 in FMOD::OutputOSS::updateMixer () from
/usr/local/lib/libfmodex.so
#9 0xb6df206d in FMOD::Thread::callback () from /usr/local/lib/libfmodex.so
#10 0xb6f9e9a0 in start_thread () from /lib/libpthread.so.0
#11 0xb6b880de in clone () from /lib/libc.so.6
The program is running. Quit anyway (and detach it)? (y or n) Quitting: Can't
detach LWP 3625: No such process

#gdb backtrace from ALSA output segfault

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1321665680 (LWP 3474)]
0xb6b35dce in memset () from /lib/libc.so.6
#0 0xb6b35dce in memset () from /lib/libc.so.6
#1 0xb6dc8d8d in FMOD::DSPFilter::read () from /usr/local/lib/libfmodex.so
#2 0xb6dc87c5 in FMOD::DSPFilter::read () from /usr/local/lib/libfmodex.so
#3 0xb6dc87c5 in FMOD::DSPFilter::read () from /usr/local/lib/libfmodex.so
#4 0xb6dc87c5 in FMOD::DSPFilter::read () from /usr/local/lib/libfmodex.so
#5 0xb6dc87c5 in FMOD::DSPFilter::read () from /usr/local/lib/libfmodex.so
#6 0xb6dd030a in FMOD::DSPSoundCard::read () from /usr/local/lib/libfmodex.so
#7 0xb6de3011 in FMOD::Output::mix () from /usr/local/lib/libfmodex.so
#8 0xb6e079e2 in FMOD::OutputALSA::updateMixer () from
/usr/local/lib/libfmodex.so
#9 0xb6e0206d in FMOD::Thread::callback () from /usr/local/lib/libfmodex.so
#10 0xb6fae9a0 in start_thread () from /lib/libpthread.so.0
#11 0xb6b990de in clone () from /lib/libc.so.6
The program is running. Quit anyway (and detach it)? (y or n) Detaching from
program: /root/desktop/gzdoom/1.4.08.r811/
build/gzdoom, process 3468
elbeardmorez
Posts: 4
Joined: Mon May 31, 2010 2:16 pm

Re: pulseaudio backend doesn't cure crashes

Post by elbeardmorez »

must have been automatically logged out prior to posting this.. who is 'Ransom Nabberbury'? :D
Gez
 
 
Posts: 17938
Joined: Fri Jul 06, 2007 3:22 pm

Re: pulseaudio backend doesn't cure crashes

Post by Gez »

At the moment, only FMOD Ex 4.26 is officially supported. While it can compile with later version, it doesn't work. See this changelog entry.

As for Ransom Nabberbury, the forum has a plugin that automatically gives a unique identifier per thread to anonymous posters.
User avatar
Xaser
 
 
Posts: 10774
Joined: Sun Jul 20, 2003 12:15 pm
Contact:

Re: pulseaudio backend doesn't cure crashes

Post by Xaser »

Wasn't it suggested a while back to add somewhere in the source which version of FMOD Ex is required? Did this ever make it in, by chance? There needs to be some reliable way to check for this if there isn't already, to avoid these sorts of problems.
Gez
 
 
Posts: 17938
Joined: Fri Jul 06, 2007 3:22 pm

Re: pulseaudio backend doesn't cure crashes

Post by Gez »

Yes, there is a text file.
http://mancubus.net/svn/zdoom/zdoom/tru ... ersion.txt

It just says that it only compiles with versions from 4.22 to 4.28. It doesn't say that sound is missing on 4.28 though. ;)

Sure, it would be nice if the issues could be solved, but it would be nicer if Firelight could refrain from changing their API all the time.
User avatar
Siggi
Posts: 3288
Joined: Sun Oct 03, 2004 8:57 am
Preferred Pronouns: They/Them
Location: South Africa

Re: pulseaudio backend doesn't cure crashes

Post by Siggi »

elbeardmorez wrote:must have been automatically logged out prior to posting this.. who is 'Ransom Nabberbury'? :D
Ok, I think I've fixed this little blunder for you.
elbeardmorez
Posts: 4
Joined: Mon May 31, 2010 2:16 pm

Re: pulseaudio backend doesn't cure crashes

Post by elbeardmorez »

Hi.

OK, i went backwards. With ZDoom v2.4.1 FMOD v4.26.00 doesn't compile out of the box neither does v4.24.37. I had to modify ~5 files to add an extra 'int loopstart' parameter to the LoadSoundRaw declarations. Then it compiled!

[off topic: what is with that input lag anyway ..it occasionally sorts itself out for a few seconds but then it's right back up there at ~0.5 seconds delay for either mouse or keyboard input - making zdoom unusable for me :( ]

Anyway, YES, this version doesn't crash when i fire a gun ..but ..it also doesn't play any in-game SFX. No gun-shots, no 'you picked up a..' sounds. This again leads me to ask
why would SFX such as 'cycling a menu' work fine, and yet an in-game SFX like 'a gunshot' cause a segfault ...just not work?
Also, i don't know if it's at all related, but when the midi device is set to FMOD, i get nothing, but 'OPL Synth Emulation' is great.

Note that it was the fact that the 'supported' v4.28.06 didn't work out of the box that set me on this mad mission. From there i pressumed it was pulseaudio related and from there i managed to find a few threads (the TeamSpeak 3 thread) mentioning that FMOD devs may end up implementing a proper pulse backend. Well they did, so i can't see any harm in zdoom adding the trivial pulseaudio backend enabling patch should this issue eventually get resolved.

Regardless, i think this thread should serve as a highlight that going forward with newer (v4.28.xx +) versions of FMOD, zdoom has sound problems with all pulse related backends ..and that will affect a fair few people i imagine*.

Thanks.

ps. Siggi, thanks.

*or it could just me my setup that's shafted ..but 'everything else' works fine :D
User avatar
InsanityBringer
Posts: 3392
Joined: Thu Jul 05, 2007 4:53 pm
Location: opening the forbidden box

Re: pulseaudio backend doesn't cure crashes

Post by InsanityBringer »

I have no idea what the process would be on linux, but I did actually encounter the same "no sound" issue, but that was because I put the improper fmodex.dll file into my zdoom directory. (I used 4.26 instead of 4.24 which I built with)
elbeardmorez
Posts: 4
Joined: Mon May 31, 2010 2:16 pm

Re: pulseaudio backend doesn't cure crashes

Post by elbeardmorez »

Hi again,
why would SFX such as 'cycling a menu' work fine, and yet an in-game SFX like 'a gunshot' cause a segfault (FMOD v4.28.06+) ...just not work? ..be unaudible?!
DOOM2 wad -> new game -> collect chainsaw -> use it in the small quiet echoey start location ..and bingo, the faintest sound ever! STAT SOUND in the console also shows that channel(s) are being filled when i shoot / chainsaw.

So at least for the FMOD i'm now running (v4.24.37) ..the issue boils down to gain control from the software mixer. Again, it seems strange that menu sounds don't have this problem, but i suppose a guess would be that these sounds don't need to be mixed.

No idea where to go from here.
User avatar
randi
Site Admin
Posts: 7749
Joined: Wed Jul 09, 2003 10:30 pm
Contact:

Re: pulseaudio backend doesn't cure crashes

Post by randi »

elbeardmorez wrote:With ZDoom v2.4.1 FMOD v4.26.00 doesn't compile out of the box neither does v4.24.37. I had to modify ~5 files to add an extra 'int loopstart' parameter to the LoadSoundRaw declarations.
You shouldn't need to edit anything. It builds fine on my system (Ubuntu 10.04 on an Inspiron 6000 laptop) as-is with 4.26. My Linux directory source layout looks like this:
~/zdoom - SVN checkout directory
~/zdoom/release - Build directory
~/zdoom/debug - Same
~/fmodapi42606linux - FMOD package unextracted.

Any version of 4.26 will work; I just haven't updated it in a while since my Linux machine is mostly not used for coding. 4.28 will work, too, but has strange directionality issues with the sound. 4.30 crashes.

I have note installed FMOD. I let CMake find it inside the ~/zdoom directory and use it from there. Did you install it and now have conflicting headers and system libraries?
elbeardmorez wrote:[off topic: what is with that input lag anyway ..it occasionally sorts itself out for a few seconds but then it's right back up there at ~0.5 seconds delay for either mouse or keyboard input - making zdoom unusable for me :( ]
I have no input lag and have never heard of such a thing. If you think it's sound-related, you can run with -nosound to decide one way or the other.
elbeardmorez wrote:Also, i don't know if it's at all related, but when the midi device is set to FMOD, i get nothing, but 'OPL Synth Emulation' is great.
You need to provide FMOD with DLS instruments. I no of know Linux distribution that provides them, so you need to take them from Windows or a Mac, then set snd_midipatchset to tell FMOD where to find them.
elbeardmorez wrote:Note that it was the fact that the 'supported' v4.28.06 didn't work out of the box
It should work fine, though again, not as well as 4.26 due to stereo separation issues.
elbeardmorez wrote:From there i pressumed it was pulseaudio related
It has nothing to do with the sound output system. 4.30 doesn't like the way I modify the DSP graph for the underwater reverb, for some reason. Since it still crashes, I suppose I should make a small test case and put it up at the FMOD forum so they can see what's up.
elbeardmorez wrote:Regardless, i think this thread should serve as a highlight that going forward with newer (v4.28.xx +) versions of FMOD, zdoom has sound problems with all pulse related backends
Again, it has nothing to do with Pulse Audio.
Post Reply

Return to “Closed Bugs [GZDoom]”