Unhandled exception when disposing AudioSessionManager2 about coreaudio

[LAB02-Admin]

Don't worry about it :)

I'm already doing that:

I've published the source here: https://github.com/LAB02-Admin/AudioDetectionTest

The relevant file is AudioManager.cs.

Maybe you could have a quick look when you have some spare time?

[LAB02-Admin]

Wow @morphx666, this is some grade-A support :)

Been running for a while and no more memory leak, very happy with this, thank you!

I'll remove the manual disposes, test again later and let you know

[LAB02-Admin]

It's all good, I was indeed just too focussed. GC just keeps the memory around to save resources, but it stays around 30-50MB. Its released when I run out of memory, but that normally doesn't happen.

Thanks for all your support @morphx666, really great :)

[morphx666]

Hi @LAB02-Admin, if I understand correctly the error occurs when the default audio output device changes?

If that's the case, I will need to run some tests to see if I can reproduce the problem.

[LAB02-Admin]

No that works fine. When the device changes, I dispose the AudioSessionManager2 (that's where it crashes) and fetch a new one. But I just realised that's probably not the right way.

What do you recommend? Just keep using the same MMDevice & AudioSessionManager2, even when the device changes, and only dispose when closing the application?

[LAB02-Admin]

If I don't renew the AudioSessionManager2, it doesn't pick up sessions that are bound to the new device, so I can't keep using the same one. You probably already knew that though, just reporting what I tested :)

[morphx666]

Each MMDevice has its own AudioSessionManager2 so when changing the device, the new device will contain its own set of sessions via its own AudioSessionManager2.

If you run this sample you will see that every time you select a different output device, the sessions change accordingly.

Regarding that sample, I will be soon updating it to support the creation and expiration of sessions.

[LAB02-Admin]

Alright, thanks for the info! I'll be processing volume/session changes non stop, so what do you recommend regarding disposals? Memory leaks seem to be hard to avoid when working with audio devices.

[LAB02-Admin]

The odd thing is, that when I'm just periodically looping through the devices and their sessions, the number of objects (and amount of unmanaged memory) just keep rising:

This is whether I dispose where objects can be disposed, or not.

These objects just keep rising in count:

Any idea what I'm doing wrong or what's happening?

[morphx666]

I'm sorry for taking so long to reply.

Something that occurs to me would be to call RefreshSessions() on the AudioSessionManager2 every time you "re-connect" to an MMDevice. This will force a dispose on the object and will then re-create it with all sessions attached to that device.

[morphx666]

Absolutely. Give me time until this weekend as I'm swamped!

[LAB02-Admin]

Of course, good luck!

[morphx666]

So now it happens that I cannot run the profiler on VS 2022 because of some weird bug.

I will check the code (manually) and I'll let you know if I can find anything...

[morphx666]

Good news. I have just updated the library (1.12.0) to include a Dispose() method for MMDevice. This appears to solve the problem.

In your sample, I'd recommend doing the following changes:

• In the main loop of MonitorAudioDevices, add _audioDevice.Dispose(); at the end of the try block.
• Remove the device.AudioSessionManager2?.RefreshSessions(); from the GetSessions function.
• In that same function, add the following statements in the finally block:
  session?.Dispose();
device.Dispose();

Please let me know if you notice any improvements.

If it works, it'd be interesting to test if removing all the manual Dispose's also works, as the GC should take care of that automatically.

[LAB02-Admin]

After removing all disposes, the obj count keeps rising:

[LAB02-Admin]

Another weird thing; the objects are going great, but the amount of unmanaged mem keeps rising (like 40MB with just a few MB for the app itself).

I noticed a drop in the unmanaged mem when the profiler called the GC, so I added this to run every 5 min:

GC.Collect();
GC.WaitForPendingFinalizers();

And now the memory stays 100% stable.

Weird though, never had to use that before.

[morphx666]

hmmm... that doesn´t sound right. I guess I'll have to run some more tests and see if I can figure out what's going on.

[LAB02-Admin]

Could be that I'm just too focussed on it now, and that GC will collect it eventually. I'll keep it running for a few days to see what happens.