Audio (SoundEffect and Song) on Mac Failing

[fna-xna]

Audio (SoundEffect and Song) on Mac Failing

[flibitijibibo]

Are you using a 32-bit or 64-bit runtime? For Song, you may need to add to your DYLD_LIBRARY_PATH if you're running from an IDE.

[prime31]

I am using a 32-bit runtime (IntPtr.Size is 4). Setting the DYLD_LIBRARY_PATH gets vorbis loaded up which leads to this crash and stack trace:

ARB_debug_output not supported!
GREMEDY_string_marker not supported!
IGLDevice: OpenGLDevice
OpenGL Device: Intel(R) Iris(TM) Graphics 6100
OpenGL Driver: 2.1 INTEL-10.14.66
OpenGL Vendor: Intel Inc.
MojoShader Profile: glsl120
Stacktrace:

  at <unknown> <0xffffffff>
  at (wrapper managed-to-native) Vorbisfile.ov_read (intptr,intptr,int,int,int,int,int&) <0x00015>
  at Microsoft.Xna.Framework.Media.Song.QueueBuffer (object,System.EventArgs) <0x00117>
  at Microsoft.Xna.Framework.Audio.DynamicSoundEffectInstance.Play (bool) [0x00150] in /Users/desaro/Documents/dev/MonoGame/Nez.FNA.Branch/FNA/src/Audio/DynamicSoundEffectInstance.cs:269
  at Microsoft.Xna.Framework.Media.Song.Play () [0x00043] in /Users/desaro/Documents/dev/MonoGame/Nez.FNA.Branch/FNA/src/Media/Xiph/Song.cs:246
  at Microsoft.Xna.Framework.Media.MediaPlayer.PlaySong (Microsoft.Xna.Framework.Media.Song) [0x00021] in /Users/desaro/Documents/dev/MonoGame/Nez.FNA.Branch/FNA/src/Media/MediaPlayer.cs:329
  at Microsoft.Xna.Framework.Media.MediaPlayer.Play (Microsoft.Xna.Framework.Media.Song) <0x001f3>

Native stacktrace:


Debug info from gdb:

(lldb) command source -s 0 '/tmp/mono-gdb-commands.dOwqCf'
Executing commands in '/tmp/mono-gdb-commands.dOwqCf'.
(lldb) process attach --pid 13920
Process 13920 stopped
* thread #1: tid = 0x78de54, 0x9269acee libsystem_kernel.dylib`__wait4 + 10, name = 'tid_50b', queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
    frame #0: 0x9269acee libsystem_kernel.dylib`__wait4 + 10
libsystem_kernel.dylib`__wait4:
->  0x9269acee <+10>: jae    0x9269acfe                ; <+26>
    0x9269acf0 <+12>: calll  0x9269acf5                ; <+17>
    0x9269acf5 <+17>: popl   %edx
    0x9269acf6 <+18>: movl   0x1090132f(%edx), %edx

Executable module set to "/Library/Frameworks/Mono.framework/Versions/4.4.1/bin/mono32".
Architecture set to: i386-apple-macosx.
(lldb) thread list
Process 13920 stopped
* thread #1: tid = 0x78de54, 0x9269acee libsystem_kernel.dylib`__wait4 + 10, name = 'tid_50b', queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
  thread #2: tid = 0x78de55, 0x9269a3ea libsystem_kernel.dylib`__psynch_cvwait + 10
  thread #3: tid = 0x78de73, 0x926934d6 libsystem_kernel.dylib`semaphore_wait_trap + 10, name = 'tid_1603'
  thread #4: tid = 0x78de74, 0x9269ad5e libsystem_kernel.dylib`__workq_kernreturn + 10
  thread #5: tid = 0x78de75, 0x9269b7fa libsystem_kernel.dylib`kevent_qos + 10, queue = 'com.apple.libdispatch-manager'
  thread #6: tid = 0x78de76, 0x9269a646 libsystem_kernel.dylib`__recvfrom + 10, name = 'tid_1507'
  thread #7: tid = 0x78dee2, 0x9269ad5e libsystem_kernel.dylib`__workq_kernreturn + 10
  thread #8: tid = 0x78dee4, 0x9269ad5e libsystem_kernel.dylib`__workq_kernreturn + 10
  thread #9: tid = 0x78deed, 0x9269ad5e libsystem_kernel.dylib`__workq_kernreturn + 10
  thread #10: tid = 0x78df25, 0x926934ee libsystem_kernel.dylib`semaphore_timedwait_trap + 10
  thread #11: tid = 0x78df26, 0x9269349a libsystem_kernel.dylib`mach_msg_trap + 10, name = 'com.apple.audio.IOThread.client'
(lldb) thread backtrace all
* thread #1: tid = 0x78de54, 0x9269acee libsystem_kernel.dylib`__wait4 + 10, name = 'tid_50b', queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
  * frame #0: 0x9269acee libsystem_kernel.dylib`__wait4 + 10
    frame #1: 0x901ee7dc libsystem_c.dylib`waitpid$UNIX2003 + 48
    frame #2: 0x001b752d mono32`mono_handle_native_sigsegv(signal=11, ctx=0x007e7fe0, info=0x007e7fa0) + 541 at mini-exceptions.c:2348 [opt]
    frame #3: 0x002075a2 mono32`mono_arch_handle_altstack_exception(sigctx=<unavailable>, siginfo=<unavailable>, fault_addr=<unavailable>, stack_ovf=0) + 162 at exceptions-x86.c:1107 [opt]
    frame #4: 0x000f9d33 mono32`mono_sigsegv_signal_handler(_dummy=<unavailable>, _info=<unavailable>, context=<unavailable>) + 467 at mini-runtime.c:2888 [opt]
    frame #5: 0x9980e79b libsystem_platform.dylib`_sigtramp + 43
    frame #6: 0x09f99e7a libvorbis.0.dylib`vorbis_synthesis_halfrate_p + 10
    frame #7: 0x09b90c66 libvorbisfile.3.dylib`_fetch_and_process_packet + 534
    frame #8: 0x09b91346 libvorbisfile.3.dylib`ov_read_filter + 86
    frame #9: 0x09b9194b libvorbisfile.3.dylib`ov_read + 75
    frame #10: 0x09be4b48
    frame #11: 0x09be47c8
    frame #12: 0x09be342a
    frame #13: 0x09be2a18
    frame #14: 0x09be2484
    frame #15: 0x09be152c
    frame #16: 0x09bbb714
    frame #17: 0x09b54791
    frame #18: 0x09b54184
    frame #19: 0x09ae076c
    frame #20: 0x07c02902
    frame #21: 0x07c023dc
    frame #22: 0x0074a628
    frame #23: 0x0074a34c
    frame #24: 0x0074a543
    frame #25: 0x000fd567 mono32`mono_jit_runtime_invoke(method=<unavailable>, obj=<unavailable>, params=<unavailable>, exc=<unavailable>) + 951 at mini-runtime.c:2578 [opt]
    frame #26: 0x002d5b86 mono32`mono_runtime_invoke(method=0x7b9e7ec0, obj=<unavailable>, params=<unavailable>, exc=<unavailable>) + 150 at object.c:2897 [opt]
    frame #27: 0x002dbb41 mono32`mono_runtime_exec_main(method=0x7b9e7ec0, args=<unavailable>, exc=0x00000000) + 401 at object.c:4223 [opt]
    frame #28: 0x002db8f8 mono32`mono_runtime_run_main(method=0x7b9e7ec0, argc=<unavailable>, argv=<unavailable>, exc=<unavailable>) + 632 at object.c:3837 [opt]
    frame #29: 0x0017b975 mono32`mono_jit_exec(domain=<unavailable>, assembly=<unavailable>, argc=<unavailable>, argv=<unavailable>) + 213 at driver.g.c:1031 [opt]
    frame #30: 0x0017de3c mono32`mono_main [inlined] main_thread_handler + 8396 at driver.g.c:1091 [opt]
    frame #31: 0x0017de04 mono32`mono_main(argc=<unavailable>, argv=<unavailable>) + 8340 at driver.g.c:2162 [opt]
    frame #32: 0x000ee7a1 mono32`main [inlined] mono_main_with_options(argc=4, argc=4, argc=4, argv=0xbff1489c, argv=0xbff1489c, argv=0xbff1489c) + 33 at main.c:28 [opt]
    frame #33: 0x000ee780 mono32`main(argc=4, argv=0xbff1489c) + 1184 at main.c:177 [opt]
    frame #34: 0x000ee2d5 mono32`start + 53

  thread #2: tid = 0x78de55, 0x9269a3ea libsystem_kernel.dylib`__psynch_cvwait + 10
    frame #0: 0x9269a3ea libsystem_kernel.dylib`__psynch_cvwait + 10
    frame #1: 0x9b936538 libsystem_pthread.dylib`_pthread_cond_wait + 757
    frame #2: 0x9b938276 libsystem_pthread.dylib`pthread_cond_wait$UNIX2003 + 71
    frame #3: 0x003372eb mono32`thread_func [inlined] mono_os_cond_wait(mutex=0xb00810b0) + 18 at mono-os-mutex.h:105 [opt]
    frame #4: 0x003372d9 mono32`thread_func(thread_data=0x00000000) + 457 at sgen-thread-pool.c:118 [opt]
    frame #5: 0x9b935780 libsystem_pthread.dylib`_pthread_body + 138
    frame #6: 0x9b9356f6 libsystem_pthread.dylib`_pthread_start + 155
    frame #7: 0x9b932f7a libsystem_pthread.dylib`thread_start + 34

  thread #3: tid = 0x78de73, 0x926934d6 libsystem_kernel.dylib`semaphore_wait_trap + 10, name = 'tid_1603'
    frame #0: 0x926934d6 libsystem_kernel.dylib`semaphore_wait_trap + 10
    frame #1: 0x002d346e mono32`finalizer_thread [inlined] mono_os_sem_wait(flags=MONO_SEM_FLAGS_ALERTABLE) + 14 at mono-os-semaphore.h:72 [opt]
    frame #2: 0x002d3460 mono32`finalizer_thread [inlined] mono_coop_sem_wait(flags=MONO_SEM_FLAGS_ALERTABLE) + 10 at mono-coop-semaphore.h:40 [opt]
    frame #3: 0x002d3456 mono32`finalizer_thread(unused=0x00000000) + 118 at gc.c:711 [opt]
    frame #4: 0x002ac9d9 mono32`start_wrapper [inlined] start_wrapper_internal + 540 at threads.c:717 [opt]
    frame #5: 0x002ac7bd mono32`start_wrapper(data=<unavailable>) + 29 at threads.c:764 [opt]
    frame #6: 0x003669bd mono32`inner_start_thread(arg=<unavailable>) + 349 at mono-threads-posix.c:92 [opt]
    frame #7: 0x9b935780 libsystem_pthread.dylib`_pthread_body + 138
    frame #8: 0x9b9356f6 libsystem_pthread.dylib`_pthread_start + 155
    frame #9: 0x9b932f7a libsystem_pthread.dylib`thread_start + 34

  thread #4: tid = 0x78de74, 0x9269ad5e libsystem_kernel.dylib`__workq_kernreturn + 10
    frame #0: 0x9269ad5e libsystem_kernel.dylib`__workq_kernreturn + 10
    frame #1: 0x9b93534b libsystem_pthread.dylib`_pthread_wqthread + 1289
    frame #2: 0x9b932f56 libsystem_pthread.dylib`start_wqthread + 34

  thread #5: tid = 0x78de75, 0x9269b7fa libsystem_kernel.dylib`kevent_qos + 10, queue = 'com.apple.libdispatch-manager'
    frame #0: 0x9269b7fa libsystem_kernel.dylib`kevent_qos + 10
    frame #1: 0x9c1b87ea libdispatch.dylib`_dispatch_mgr_invoke + 234
    frame #2: 0x9c1b83be libdispatch.dylib`_dispatch_mgr_thread + 52

  thread #6: tid = 0x78de76, 0x9269a646 libsystem_kernel.dylib`__recvfrom + 10, name = 'tid_1507'
    frame #0: 0x9269a646 libsystem_kernel.dylib`__recvfrom + 10
    frame #1: 0x901ee9df libsystem_c.dylib`recv$UNIX2003 + 55
    frame #2: 0x001ee328 mono32`socket_transport_recv(buf=<unavailable>, len=<unavailable>) + 168 at debugger-agent.c:1129 [opt]
    frame #3: 0x001df0d3 mono32`debugger_thread [inlined] transport_recv(len=11) + 29 at debugger-agent.c:1514 [opt]
    frame #4: 0x001df0b6 mono32`debugger_thread(arg=0x00000000) + 1494 at debugger-agent.c:9617 [opt]
    frame #5: 0x003669bd mono32`inner_start_thread(arg=<unavailable>) + 349 at mono-threads-posix.c:92 [opt]
    frame #6: 0x9b935780 libsystem_pthread.dylib`_pthread_body + 138
    frame #7: 0x9b9356f6 libsystem_pthread.dylib`_pthread_start + 155
    frame #8: 0x9b932f7a libsystem_pthread.dylib`thread_start + 34

  thread #7: tid = 0x78dee2, 0x9269ad5e libsystem_kernel.dylib`__workq_kernreturn + 10
    frame #0: 0x9269ad5e libsystem_kernel.dylib`__workq_kernreturn + 10
    frame #1: 0x9b93534b libsystem_pthread.dylib`_pthread_wqthread + 1289
    frame #2: 0x9b932f56 libsystem_pthread.dylib`start_wqthread + 34

  thread #8: tid = 0x78dee4, 0x9269ad5e libsystem_kernel.dylib`__workq_kernreturn + 10
    frame #0: 0x9269ad5e libsystem_kernel.dylib`__workq_kernreturn + 10
    frame #1: 0x9b93534b libsystem_pthread.dylib`_pthread_wqthread + 1289
    frame #2: 0x9b932f56 libsystem_pthread.dylib`start_wqthread + 34

  thread #9: tid = 0x78deed, 0x9269ad5e libsystem_kernel.dylib`__workq_kernreturn + 10
    frame #0: 0x9269ad5e libsystem_kernel.dylib`__workq_kernreturn + 10
    frame #1: 0x9b93534b libsystem_pthread.dylib`_pthread_wqthread + 1289
    frame #2: 0x9b932f56 libsystem_pthread.dylib`start_wqthread + 34

  thread #10: tid = 0x78df25, 0x926934ee libsystem_kernel.dylib`semaphore_timedwait_trap + 10
    frame #0: 0x926934ee libsystem_kernel.dylib`semaphore_timedwait_trap + 10
    frame #1: 0x9c1be881 libdispatch.dylib`_dispatch_semaphore_wait_slow + 212
    frame #2: 0x9c1be7a4 libdispatch.dylib`dispatch_semaphore_wait + 37
    frame #3: 0x9c1b82f9 libdispatch.dylib`_dispatch_worker_thread + 159
    frame #4: 0x9b935780 libsystem_pthread.dylib`_pthread_body + 138
    frame #5: 0x9b9356f6 libsystem_pthread.dylib`_pthread_start + 155
    frame #6: 0x9b932f7a libsystem_pthread.dylib`thread_start + 34

  thread #11: tid = 0x78df26, 0x9269349a libsystem_kernel.dylib`mach_msg_trap + 10, name = 'com.apple.audio.IOThread.client'
    frame #0: 0x9269349a libsystem_kernel.dylib`mach_msg_trap + 10
    frame #1: 0x92692884 libsystem_kernel.dylib`mach_msg + 68
    frame #2: 0x95ec98ac CoreAudio`HALB_MachPort::SendMessageWithReply(unsigned int, unsigned int, unsigned long, unsigned long, mach_msg_header_t*, bool, unsigned int) + 140
    frame #3: 0x95ec2ab2 CoreAudio`HALB_MachPort::SendSimpleMessageWithSimpleReply(unsigned int, unsigned int, int, int&, bool, unsigned int) + 72
    frame #4: 0x95ec0f20 CoreAudio`HALC_ProxyIOContext::IOWorkLoop() + 1392
    frame #5: 0x95ec0894 CoreAudio`HALC_ProxyIOContext::IOThreadEntry(void*) + 156
    frame #6: 0x95ecc9ec CoreAudio`___ZN19HALC_ProxyIOContextC2Emj_block_invoke + 20
    frame #7: 0x95ec07b9 CoreAudio`HALB_IOThread::Entry(void*) + 71
    frame #8: 0x9b935780 libsystem_pthread.dylib`_pthread_body + 138
    frame #9: 0x9b9356f6 libsystem_pthread.dylib`_pthread_start + 155
    frame #10: 0x9b932f7a libsystem_pthread.dylib`thread_start + 34
(lldb) detach

=================================================================
Got a SIGSEGV while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries 
used by your application.
=================================================================

Process 13920 detached
(lldb) quit
Abort trap: 6
``

Any other ideas what could be happening here?

[flibitijibibo]

Can you try the 64-bit runtime instead? As of Mono 4 32-bit OSX is kind of hosed for whatever reason; it used to work in 2.10.x but I found that alBufferData in particular gets a corrupted parameter list only in 32-bit OSX. On the bright side, requiring 64-bit on OSX is hardly a requirement anymore... :P

[prime31]

Bingo! Switching to 64-bit did the trick. Many thanks for that tip! I don't know why I got it in my head that FNA needed to be run in 32-bit.

Last audio related question: it looks like SoundEffect.CreateInstance is WeakRefing the SoundEffectInstance. Doing that means if it drop out of scope it dies and doesnt get played. Is that by design or a bug?

[flibitijibibo]

It is by design for XNA accuracy only; that said, the accuracy details have made the SFI management pretty fragile. From what I can tell there's a link between SoundEffects and their instances, but I don't exactly know how. Instances are GC'd when dropped by the game, but when you dispose a SoundEffect, the Instances get disposed as well! So I had to find a way to link the two without creating a hard ref, with the exception of internally-managed Instances created by SoundEffect.Play().

It's something I want to test more aggressively, but part of what makes this hard to test is that it depends on the GC, so we have to find some setup that we can put together that behaves consistently (GC.Collect would help put a deadline on certain behaviors, at least).

[LennardF1989]

I have these exact same issues on Mac 10.11.6 - Game fully works, but whenever I try to load a song, it crashes with the DllNotFoundException Prime mentioned. I tried running from the terminal with mono64 and setting the DYLD_LIBRARY_PATH to my game folder as suggested, but it still crashes none-the-less.

EDIT: Nevermind, I messed up my path... verified using cd $DYLD_LIBRARY_PATH - works on mono64. Wondering if MonoKickstart is 64-bit tho?

EDIT EDIT: Not sure about the answer, precompiled MonoKickstart is Universal. Is it possible for the Mac to have two binaries just like Linux has, or wouldn't it make a difference? Weird thing in the stacktrace below is that we're back at the ov_fopen error which was bound to the DllNotFoundException - but even after hardcoding my DYLD path in the MonoKickstart bash-script, it still won't work :/

Assertion failed: (0), function amd64_patch, file mini-amd64.c, line 478.
Stacktrace:

  at <unknown> <0xffffffff>
  at Vorbisfile.ov_fopen (string,intptr&) <0x0001c>
  at Microsoft.Xna.Framework.Media.Song..ctor (string) <0x000b0>

[LennardF1989]

@flibitijibibo Ok, this is EXTREMELY silly. As a last attempt at figuring out what was happening in MonoKickstart, I decide to modify the Vorbisfile.cs. In the stacktrace above you can see it never ever hits the INTERNAL_ov_fopen, so things go wrong before even attempting to call a PInvoke.

I found out it calls the AllocVorbisFile method and had an "Ahh!"-moment: MonoKickstart probably makes it allocate a wrong amount of memory. In order to test this, I simply added a bunch of FNALoggerEXT.LogInfo. Compiled, ran the code, jumped to my terminal to see what would happen and... music started playing after showing the logs. WHAT?!

I removed all logs, it stopped working again. Added back a single log at the top of AllocVorbisFile, it worked. Moving the log outside of AllocVorbisFile didn't work however.

Any idea why this is happening? I cannot explain it. It must be due to the logger calling Console.WriteLine which does something funky with the memory (in a good way)...

EDIT: Looks like switching from malloc/free to Marshal.AllocHGlobal/Marshal.FreeHGlobal resolves the issue too. Any word on why this might be a bad fix?

[flibitijibibo]

I believe the problem is exclusively a Mac problem - specifically at the compiler stage. If you build the exact same sources with the exact same compiler version on a different platform then it should fix it as well. I saw this with FEZ 1.12 but I didn't bother investigating.

[LennardF1989]

@flibitijibibo You mean I simply have to copy over my Windows-compiled FNA.dll to my Mac, and it will magically work?

EDIT: Would you be willing to replace the malloc/free with the Marshal calls in the original repository to fix this issue no matter where you compile sources from?

[flibitijibibo]

Yeah, Windows or Linux should be fine.

We can't actually use AllocHGlobal because it technically uses LocalAlloc, which has different behavior from malloc on Windows:

https://msdn.microsoft.com/en-us/library/s69bkh17(v=vs.110).aspx