Memory leak in audiodg.exe with FXSound 1.1.16.0

Get Help
1

I’m here to report an issue that appears to only play when FXSound is running, currently version 1.1.16.0 and this has been happening for months and on two different systems.

This issue mostly appears to happen when the system has been running for a prolonged period of time but it is random. Usually with 1+ day uptimes of operating system.

The problem is that the system process audiodg.exe starts consuming considerable amounts of memory, sometimes even more than 1GB until FXSound is closed and restarted again.

I’ve had this issue happen on the following system/platforms:

System 1:
Windows 10 21H1 & 21H2
Intel Core i7 3930K
Corsair Dominator 8x4GB DDR3-1866
EVGA Geforce GTX1080Ti FTW3 (multiple recent driver versions)
Asus Sabertooth X79 motherboard
Audio Chip + Setting: Realtek ALC892 @ 192Khz 24bit 5.1 surround
Audio device(s) connected: Logitech Z906 5.1 @ analog & Logitech G35 7.1 Headset @ USB

System 2:
Windows 10 21H2
Intel Core i9 13900K
Corsair Dominator 2x32GB DDR5-5600
Asus ROG Maximus Z790 Extreme
Audio Chip + Setting: Realtek ALC4082 @ 192Khz 32bit 5.1 surround
Audio device(s) connected: Logitech Z906 5.1 @ analog & Logitech G35 7.1 Headset @ USB

Both systems have been experiencing this issue.

On System 1 audiodg.exe would sometimes freeze so badly the service/process could not be closed or restarted despite closing FXSound needing a full system reboot to fix the audio & memory leak.

Whether it is stereo or 5.1 mode does not appear to matter.

But what seems to increase the memory leak a lot is having Realtek set to 192Khz mode and/or higher bits versus 16-bit 48Khz and then switching devices from USB device and back to Realtek chip in FXSound constantly.

Closing FXSound and switching devices in Windows sounds itself does change memory footprint of audiodg.exe but it will not keep increasing as FXSound does cause. For example USB headset will consume 16MB RAM and Realtek would consume ~67MB RAM at 192Khz 32bit.

Please look into this issue as it is quite an annoying problem.

I have uploaded the following video’s to demonstrate the issue:

Regards from a long-time DFX user since early Windows Millenium days.

1 Like
2

Hi CriticalHit,
Sorry for that.
Either way, I doubt this bug will get a fix soon, since active development of the program has come to a halt.
But I’ll ask FxSound’s lead programmer @bvijay nicely if he could perhaps do some troubleshooting on this issue?
The data you provided seems more than sufficient for him to work with.
Also, 192kHz is going overkill, since FxSound only supports bit rates of up to 48kHz:

https://forum.fxsound.com/t/discontinuing-active-development-of-fxsound/1198

1 Like
3

Yeah the 192Khz may seem a bit overkill, and while FXSound doesn’t support it itself, it does appear to have a slight change in quality in my experience. But I suppose that is weird considering it’s a digital signal.

With my previous motherboard, that audio felt more defined in the high-tone ranges so I’ve always kept it on.
This felt exceptionally noticeable in games as Battlefield Bad Company 2 with War Tapes audio enabled with all the high-fidelity ambient sounds going on.

I must admit however that on the current motherboard I do not really seem to notice a difference between 16-bit 48Khz or 192Khz 32bit.

I’m unfortunate to read that development was halted after so many many years of existence, I hope this can find a continuation because without this software the world is at a big loss for Windows audio software improvements, there is no equal replacement for DFX, this is how impactful it is and for the audio quality that our equipment can output.

Either way thank you for your reply and hopefully it is something that can be looked into. I felt like a bug report was needed.

1 Like
4

Definitely. That’s what this forum is for!

1 Like
5

Thanks @CriticalHit_NL for reporting this issue. I will use some profiling tools to root cause the memory leak. But since the active development is discontinued, I will discuss with @james on how to release any critical fixes.

3 Likes
6

Thanks for your reply, valueable time and willing to look into it further!
Hopefully something can be figured out with James.

All the best,

Critical.

2 Likes
7

Hi @CriticalHit_NL,
I am observing that even if FxSound is not running, and I keep switching the default playback device through Control Panel->Sounds or the system tray icon, the memory used by audiodg.exe keeps going up. Please let me know if you are seeing the same behaviour on your setup.

1 Like
8

Good day @bvijay ,
I have just checked it again with FxSound closed, here audiodg.exe on Windows 10 2H22 with latest updates seems to stay at 10-11MB switching between both Realtek and USB headset but is not adding up infinitely in memory usage.

This however does occur once I start FxSound again.

Choosing a primary device with FxSound running either via Windows Audio Properties or FxSound itself does not differentiate in behaviour of audiodg.exe

I am not certain why your setup appears to do so without FxSound aswell.
Hope that provides enough information.

Regards, Critical.

2 Likes
9

Hello @CriticalHit_NL
I am testing on a Windows 11 laptop with Realtek Audio. When switching between built-in speaker and external speaker frequently, I see about 3MB increase in memory used by audiodg.exe, but it eventually comes down as audio playback continues.
Also, I am able to replicate the FxSound scenario that you have observed, and the memory used by audiodg.exe keeps increasing when switching the audio output device and it is not coming down.
I have identified the line of code where IAudioClient::Initialize is called and the memory increases. I am looking at the solution for this.

3 Likes
10

Hello @bvijay

It is awesome to read you have been able to replicate the issue and find where the issue is originating from. I could hardly believe it would be something specific to my setup even with two different systems.

Hopefully you are able to find a solution.
I’m grateful for the efforts that are being made to look into this problem.
Having made the bug report for this turned out to be the right move.

Best of luck and regards, Critical.

2 Likes
11

Hi @CriticalHit_NL
I appreciate your help to analyse this issue.
If I uncheck and disable the audio enhancement option from the Speaker Properties, Advanced tab for all the playback devices, then I don’t see an increase in the memory utilised by audiodg.exe in the same rate. With the option disabled, the memory increases in the order of 100KBs.

image
image465×583 14.5 KB

In spite of calling all the required APIs to release the stream before switching the playback device interface, the memory is not getting released by audiodg.exe. So, I have posted a question in the Microsoft developer forum and waiting for an answer.
Question, audiodg.exe not releasing memory even after IAudioClient::Release is called, Published successfully (microsoft.com)

3 Likes
12

Hello @bvijay

No worries here to help, apologies for the somewhat late reply.
That is a very interesting find and I am replicating the same behaviour.
With it turned off the memory increases are very very little even if using 32bits and 192Khz on the Realtek audio configuration.

Unfortunately that seems to turn off the equalizer enhancements that Realtek provides so unfortunately can’t really do that otherwise the sound gets a lot worse.

Thank you for further investigating and creating a topic about the matter, very much appreciated.

Regards, Critical.

1 Like
13

Hi @CriticalHit_NL
Sorry for the delay in my reply. I compared our code with a Microsoft sample code as reference and found out the interface which is not getting released in our application code.
After making the changes to release the interface, memory allocated in audiodg.exe does not keep adding up when changing the output device. This solution will work with the audio enhancements enabled for the device.
Thank you for your patience on waiting for the fix for this issue.
The fix will be available soon in the coming release.

3 Likes
14

Hello @bvijay that’s amazing news!

Thank you for trying to sort this issue out despite development having halted right now, this helps the stability and user friendliness a lot for many end users.

I’ve made a $50 + fees donation just now to show my gratitude.
Hope to see the new version appear soon. :+1:

Thanks and all the best, hope development can find it’s way to continue soon.

Regards, Critical.

1 Like
15

Thank you @CriticalHit_NL for your gratitude and donation. Your support is a huge encouragement for us to keep going on this project. Looking forward to serve our patrons with many more exciting updates to the product.

2 Likes