Everything works fine in the project, except it crashes with FMOD_OUTPUTTYPE_ASIO when quitting. Switching to FMOD_OUTPUTTYPE_WASAPI, the issue is gone.
I stripped almost all code to find the issue. Crashes about 50% when testing:
Unfortunately, testing in our core API examples I couldn’t reproduce the issue. Are you able to reproduce the issue in our examples? On a windows they can be found here: "C:\Program Files (x86)\FMOD SoundSystem\FMOD Studio API Windows\api\core\examples\vs2019\examples.sln".
How would I test your code? Any reproduction steps would be greatly appreciated.
Seems this error (sometimes?) has some big impact.
Didn’t crash anymore, but had no sound at all with the ASIO audio device. Sometimes no playback progress, or progress stopping after some time due no reason. After switching the device off, playback progress continued bumb
I’d guess this could be some driver issue? Maybe any idea, or some info what’s the exact issue, so I can contact the vendor - so I wonder if the device is supported anymore.
/*==============================================================================
Play Sound Example
Copyright (c), Firelight Technologies Pty, Ltd 2004-2024.
This example shows how to simply load and play multiple sounds, the simplest
usage of FMOD. By default FMOD will decode the entire file into memory when it
loads. If the sounds are big and possibly take up a lot of RAM it would be
better to use the FMOD_CREATESTREAM flag, this will stream the file in realtime
as it plays.
For information on using FMOD example code in your own programs, visit
https://www.fmod.com/legal
==============================================================================*/
#include "fmod.hpp"
#include "common.h"
int FMOD_Main()
{
FMOD::System *system;
FMOD_RESULT result;
void *extradriverdata = 0;
Common_Init(&extradriverdata);
/*
Create a System object and initialize
*/
result = FMOD::System_Create(&system, FMOD_VERSION);
ERRCHECK(result);
/* Changes ... Running VS22 community with VS19 build tools ... running x64 */
// Added...
result = system->setOutput(FMOD_OUTPUTTYPE_ASIO);
ERRCHECK(result);
// Added...
result = system->setDriver(0);
ERRCHECK(result);
/* End changes */
result = system->init(32, FMOD_INIT_NORMAL, extradriverdata);
ERRCHECK(result);
// Common_Update();
// result = system->update();
// ERRCHECK(result);
// Common_Sleep(50);
/*
Shut down
*/
result = system->close();
ERRCHECK(result);
result = system->release();
ERRCHECK(result);
Common_Close();
return 0;
}
Would it be possible to run DxDiag? Instructions can be found here: Open and run DxDiag.exe - Microsoft Support. The results can be uploaded to your profile here: FMOD | Profile - Upload. Please note you will have to register a project with us to be able to upload files.
What device are you trying to output to with the call result = system->setDriver(0);? What version of the FMOD engine are you using?
Notes:
Think this after the VS test crash issue. Did a quick check after the DxDiag, and sound output was ok, crash as usual. If you need a specific DxDiag.txt - before a crash, after a crash or when in no-sound-state - Let me know.
Page File: 16907MB used, 81577MB available
Aktually, Windows is set to: “Total paging file size for all drives: 386 MB”, and there only is a page file on drive C: with around 386 MB. No pagefile on any other drive. Guess this number includes the physical RAM? Have such wrong values since Windows XP.
+++ WER4 +++ Event Name: GDIObjectLeak P1: explorer.exe
Before having 96 GB Ram, the system sometimes had out of memory issues with explorer reserving up to 40 GB Ram. I want upgrade to 128 GB, but the BIOS has huge issues with RAM making it hard to get the latest setup working without memory corruptions occurring. No out of memory issues unless when heavy surfing with Firefox !
Due the ASIO issues, the fmod.dll for the project was recently updated (from 2.02.18) to 2.02.23. The Visual Studio project test is 2.02.23 (fmodstudioapi20223win-installer.exe)
The device is “ADJ ASIO” (American Audio 14MXR)
[09:31:54] [Debug] FMOD: ASIO-device 0: ADJ ASIO
[09:31:54] [Debug] FMOD: ASIO-device 1: DUO-CAPTURE EX Log excerp, modified
Some positive news: Tried the project yesterday when visiting a friend on a more professional gear, and there were no issues (so far).
Thank you for the DxDiag, I was mainly looking into your connected output devices which FMOD may be trying to access. As you mentioned there are two that FMOD has identified.
Where did you get the log file from? I can see two FMOD systems attempting to initialize using both the ADJ ASIO device and the DUO-CAPTURE EX device.
FMOD: Creating system on ASIO-device 0: ADJ ASIO (channels 0/1)
FMOD: Creating system on AUTODETECT-device 0: OUT (DUO-CAPTURE EX)
FMOD: Closing system on AUTODETECT-device 0: OUT (DUO-CAPTURE EX)
FMOD: Closing system on ASIO-device 0: ADJ ASIO (channels 2/3)
Would it be possible that having two systems running simultaneously could be causing the issue?
That is good to hear! Is there anything immediately obvious that would not cause the crash on their device?
The real project uses FMOD multiple times. First temporarily for enumerating, two for audio players, two for tag reading / getting wave-data (no output, separate threads). No issues so far, except since the change to ASIO. BTW; using two ASIO system with FMOD.
To find the issues, we ended up creating the small test program. as posted above.
Could be a driver issue. Only had the device for a few days (for testing / coding ASIO subchannels support and reusing ASIO device / sound system) and will give it back on Thursday.
Are there some debug info files (pdb or so) to get further info?
Thank you, I have been able to confirm the issue is with the 14 MXR drivers. I will pass on the issue to our development team to investigate further. Are you able to use any other drivers in the meantime?
Hello, only had the device for a few days for testing. If needed I can lend the device again. If you want I can contact the manufacturer about the issue, maybe with a link to this forum post. As it’s pretty obviously a driver issue, I don’t want to bother you to much with the issue.
The issue is indeed with a non-compliant ASIO driver, but I have found a sufficient workaround. 2.02.25 will include the fix/workaround allowing interaction with the driver without crash.
!