Volume / Loudness spikes on Windows 11

[Feelisreal]

Bug Description

When playing files in Mixxx on Windows 11 they have random spikes in Loudness/Volume throughout the songs that are clearly measurable by recording the output signal of the computer and comparing the wave file to the original. The issue intensifies when fastsearching or needle searching the track and then continuing playing. The spikes then seam to built up and level down after a while. The issue does not occur in Windows 10 on the same hardware.

Additional Infos:

• When I start playback of any Audio in any software (Browser, Windows Media player etc.) it starts slightly louder and then level down (spikes DURING playback only occur in Mixxx and Rekordbox)
• A similar issue occurs in Rekordbox on Windows 11 (here the spikes are even visible in the Waveform)
• Serato plays the songs normally on Windows 11 (so there is a way)
• Both my machines to test are Lenovo Thinkpad T-Series (different models and years) so it might still be a Lenovo issue
• I tried:

1. A fresh and plain install of Windows 11 (not the Lenovo distribution) —> Issue still remains
2. Linux Live USB —> Issue doesn’t occur
3. Windows 10 —> Issue does not occur
4. Went through all (!) sound settings in Windows 11, Mixxx and even in the bios —> Issue still remains
5. Reinstalled all sound devices and tried different sound drivers.

I am currently using one machine for DJaying
that I downgraded to Windows 10 to avoid the issue, but I have another Windows 11 machine where the Issue is reproducible and I would be happy to test further, I just ran out of ideas.

Version

2.3.4, 2.4

OS

Windows 11

[daschuer]

How do you record the loudness level? Is it also able to record with the Mixxx recording feature?
Which type of files do you use?

[Swiftb0y]

A similar issue occurs in Rekordbox on Windows 11 (here the spikes are even visible in the Waveform)

Could it be a decoder issue then?

[JoergAtGithub]

Can you please specify the exact Windows 10 version, where the issue did not occur.

[Feelisreal]

How do you record the loudness level? Is it also able to record with the Mixxx recording feature? Which type of files do you use?

My library is mostly m4a / AAC. I went back and checked: apparently the issue does not apply to mp3. Even the leveling down in other media players does only happen with m4a.

I recorded the spikes by connecting my Iphone to my Audio Interface (Via USB) an recording on my I-Phone. Then analysed the recorded track and the original by alining them in a DAW. The spikes are very much visible.

I just checked, the spikes are also on the recordings if I use the internal MIXX recording function.

[Feelisreal]

Can you please specify the exact Windows 10 version, where the issue did not occur.

Where it is functioning I am on Windows 10.0.19045 Build 19045

[daschuer]

The m4a decoder on Windows 11 seems to be broken.
We have #11094 that describes a broken unit test.

Do we know if Microsoft is aware of that? Where can we report bugs?

[daschuer]

A solution might be to use ffmpeg instead.
The issue is that this will invalidate all stored cues and beat grid, because a not yet known deciding offset.

So we have the option to

• figure out and compensate the offset and move to ffmpeg
• Move to ffmpeg and tell users to reanalyze all m4a tracks
• Warn users about the issue until Microsoft has fixed it.
• Use the Windows 10 DLL

[Feelisreal]

A solution might be to use ffmpeg instead. The issue is that this will invalidate all stored cues and beat grid, because a not yet known deciding offset.

So we have the option to

* figure out and compensate the offset and move to ffmpeg

* Move to ffmpeg and tell users to reanalyze all m4a tracks

* Warn users about the issue until Microsoft has fixed it.

* Use the Windows 10 DLL

I don't know how this decission is made but if moving to ffmpeg makes MIXXX more indipendent from decissions taken at Microsoft, I would defenetly vote for that option and rather sooner then later. Who knows how long Windows takes to fix the issue. Now I currently only have 130 files in my library so probably users with bigger libraries might see things differently. Then again MIXXX is pretty much unusable on windows 11 anyways if you are using mostly AAC.

As far as I understand, the offset is not really predictable so this seems to not really be an option. Unless there is an offset that applies most of the times in which case we'd have a 80 / 20 solution.

How would I go about using the Windows 10 DLL? How does that help?

[daschuer]

I am not a windows user, but maybe you can copy the mfplat.dll to the Mixxx folder. There may be more this can be figured out by the "Dependency Walker"

Another favour you can do us is to find out how to report bugs and report it. I assume you need to be hard-nosed to pass the first level "try to restart" support wall. But it is a clear product shortage in you case which makes Windows unusable for you.

[JoergAtGithub]

Do we know if Microsoft is aware of that? Where can we report bugs?

https://answers.microsoft.com/en-us/windows/forum/all/big-problems-with-m4a-after-updating-to-windows-11/c7a84a9c-f013-4525-b0e4-d162aae122f2

[JoergAtGithub]

@Psychlist1972 Could you establish a contact to the development team, that is responsible for the M4A audio decoder in Windows11?

[Psychlist1972]

@JoergAtGithub Sorry. Those forums are mostly just peer-to-peer with people who are "independent advisors". The info from there never seems to make it over to product teams, unfortunately, so if that's the main place the problem was reported, it's unlikely that it has been noticed by engineering. I don't see anything matching in our internal work items, in any case.

If you have time and willingness to do so, it would be helpful if someone here could please take a glitch trace on an affected PC, save the files on OneDrive or some other service you trust**, and send me a link. My email is pete dot brown at microsoft dot com. Include in the subject something like M4A Audio Decoder Glitch or similar. If multiple people are seeing the issue, reports from multiple people are welcome.

Once I have that, I can bring it to our internal glitch alias where folks can take a look. But without a glitch recording, I won't be able to get anyone to look at the problem.

** Or you can do it through Feedback Hub as Gary describes in the main readme and just send me a link to the feedback hub item.

https://github.com/microsoft/audio

Thanks.

Pete

[JoergAtGithub]

@Psychlist1972 Thank you very much for your detailed response!

@Feelisreal Could you record the loudness spikes of an M4A track under Windows11 and upload it?

To summarize the issues with the M4A decoder (we've also issue #11094 about our own M4A unit tests failing):

• Affected are: Windows11 and Windows Server 2022
• Not affected are Windows7, Windows10 and Windows Server 2019
• We have loudness spikes Volume / Loudness spikes on Windows 11 #12289
• We now see a different number of samples at the beginning of the decoded track, which results in offset of the beat positions Some SoundSourceProxyTests fail on Win11 with VS2022 #11094

[Feelisreal]

@Feelisreal Could you record the loudness spikes of an M4A track under Windows11 and upload it?

I recorded a trace. @Psychlist1972 I send you an email with the link to download the trace. Hope this helps

[daschuer]

The good thing is we have a unit test on GitHub which is able to reproduce the issue reliable. We are not sure if there is a time offset in the decoding. The unit tests fail, if it is not possible to read the same samples after a seek, you it can read via steady playback from the beginning. This seek accuracy is a requirements for decoders in Mixxx.

[Feelisreal]

The good thing is we have a unit test on GitHub which is able to reproduce the issue reliable. We are not sure if there is a time offset in the decoding. The unit tests fail, if it is not possible to read the same samples after a seek, you it can read via steady playback from the beginning. This seek accuracy is a requirements for decoders in Mixxx.

I am not familiar with this unit test. Can you give me some pointers? Do you think it would help to run this as well while tracing with Pete's tracer? I mean I have allready reproduced the issue while tracing, but maybe the Unit Test could give us some extra information, what exactly is failing. I am willing to test anything on my machine but my developer skills are very limited.

[daschuer]

Yes, that could be useful. However you need to build Mixxx at home for testing at home.

[daschuer]

To rerun the test, on GitHub, just apply daschuer@aaf8a11 and push.
My test run has been removed from the history:
https://github.com/daschuer/mixxx/actions/runs/5855464923

[Psychlist1972]

@Feelisreal Could you record the loudness spikes of an M4A track under Windows11 and upload it?

I recorded a trace. @Psychlist1972 I send you an email with the link to download the trace. Hope this helps

I received it. Thank you very much.

Pete

[Psychlist1972]

@Feelisreal and @JoergAtGithub is the source media file something you can share? There are no traditional glitches in the audio, so the team is trying to decipher the trace.

Also, and I know this is a big request, they're asking if you can record the experience you are getting using video recording. This is something you can do through feedback hub if you don't have another tool you prefer.

Also, if you use an in-box tool like Media Player, do you see the same thing?

Pete

[Psychlist1972]

Also, for folks seeing this issue, have you tried on any Windows 11 Insider builds as well? If so, can you let me know which ones?

Sorry for a million questions, but we want to get to the bottom of this one.

Thanks.

Pete

[JoergAtGithub]

Thank you for taking care!
Maybe the easiest way to test, if a Windows build is affected is to build our Mixxx 2.4 branch and execute the CTests. If you get the following fails, the Windows build is affected:

The following tests FAILED:
	731 - SoundSourceProxyTest.seekForwardBackward (Failed)
	733 - SoundSourceProxyTest.seekBoundaries (Failed)
	734 - SoundSourceProxyTest.readBeyondEnd (Failed)
	735 - SoundSourceProxyTest.regressionTestCachingReaderChunkJumpForward (Failed)
Errors while running CTest

@Feelisreal Could you provide 3 files to Pete:

• M4A source file
• Recording with unaffected Windows 10
• Recording with affected Windows 11

[Psychlist1972]

Thank you for taking care! Maybe the easiest way to test, if a Windows build is affected is to build our Mixxx 2.4 branch and execute the CTests. If you get the following fails, the Windows build is affected:

The following tests FAILED:
	731 - SoundSourceProxyTest.seekForwardBackward (Failed)
	733 - SoundSourceProxyTest.seekBoundaries (Failed)
	734 - SoundSourceProxyTest.readBeyondEnd (Failed)
	735 - SoundSourceProxyTest.regressionTestCachingReaderChunkJumpForward (Failed)
Errors while running CTest

Thanks. Unfortunately, no one in engineering is going to have time to do that during this phase of investigation, so trying to find the quickest past to proving there's an issue.

Pete

[daschuer]

@JoergAtGithub can you send them a freshworking tree including the test after make clean. I think a reliable failing unit test is the way quickest path to reproduce the issue at Microsoft.
Just extract the files, run the test and than modify the m4a decoder that test succeeds.

[Feelisreal]

Sorry for the late reply I have been bussy...

@Psychlist1972 Hey Pete I send you a Nextcloud Share with the requested recordings.

Here a short explanation

• Recording from affected Windows 11 in MIXXX which shows the spikes especially (but not only) when you skip through the song
• Recording from affected Windows 11 in Windows Mediaplayer (the new one) which shows, that the Audio spikes each time you start playing after skipping through the song (after that it plays regular thorugh the song). But I think this intial spike combined with the processing that is done in MIXXX creates the random spikes in MIXXX
• Unaffected Windows 10 MIXXX shows no spikes even after skipping through the song
• Unaffected Windows 10 Media Player (the new one) has no spikes even after skipping
• I included one song (07 Joha.m4a), that I always know its affected and I know where to find the issue. Note that almost any m4a/AAC File will show the issue eventually and the spikes in Media Player at the beginning of playback are allways there on the affected System

[Psychlist1972]

Sorry for the late reply I have been bussy...

@Psychlist1972 Hey Pete I send you a Nextcloud Share with the requested recordings.

Here a short explanation

• Recording from affected Windows 11 in MIXXX which shows the spikes especially (but not only) when you skip through the song
• Recording from affected Windows 11 in Windows Mediaplayer (the new one) which shows, that the Audio spikes each time you start playing after skipping through the song (after that it plays regular thorugh the song). But I think this intial spike combined with the processing that is done in MIXXX creates the random spikes in MIXXX
• Unaffected Windows 10 MIXXX shows no spikes even after skipping through the song
• Unaffected Windows 10 Media Player (the new one) has no spikes even after skipping
• I included one song (07 Joha.m4a), that I always know its affected and I know where to find the issue. Note that almost any m4a/AAC File will show the issue eventually and the spikes in Media Player at the beginning of playback are allways there on the affected System

Thank you so much for taking the time to do all this and record it. I've sent the info along to the team and will let you know what they come back with.

Note that much of next week is a holiday in the US, so there may be a delay in reporting back.

Pete

[Psychlist1972]

Is anyone here running a Canary Insider build of Windows 11? The team had put in some fix in the codec and wanted to confirm if it does/doesn't fix this issue. They know the fix made it into the Canary channel for sure. They are looking to see if it's in any of the other Insider channels.

[JoergAtGithub]

The fix will not be released before February 2024! No need to test it now, except you have access to the Windows-Beta builds from Microsofts Canary-Channel.

[daschuer]

The issue is that we have no guarantee that the issue is fixed. It would be relay bad if Microsoft rolls out the "fix" which is not fixing the issue completely. Do you have a proposal how to check that before February?

[daschuer]

KB5032288 is described here:
https://support.microsoft.com/en-us/topic/december-4-2023-kb5032288-os-builds-22621-2792-and-22631-2792-preview-538fbe4a-e9de-4312-85cd-d870444341d0

There is nothing noted about m4a / AAC or Media Foundation, however it contains a new mfplat.dll with 10.0.22621.2506".

[daschuer]

Who can share some insights? I have currently access to a Windows 11 21H2 10.0.22000 machine
KB5032288 is only availabel for 22H2 and 23H2

I have downloaded the 22H2 version form https://www.catalog.update.microsoft.com/Search.aspx?q=KB5032288 but it complains to be not for this machine.

Is one able to install and test this update?

[daschuer]

I have managed to update to Windows 11 23H2 10.0.22631
It was updated to KB5033375 wich includes KB5032288

Unfortunatly the unittest is still failing it comes with "Microsoft Media Foundation 10.0.22621.2506"
Which update do we need for a fix?

[JoergAtGithub]

You need to use one of the latest build from the Windows 11 Canary-Channel. In the official builds the fix will not appear until February.
Try this one: https://blogs.windows.com/windows-insider/2024/01/03/announcing-windows-11-insider-preview-build-26020-canary-channel/

[daschuer]

I cannot mess around with this machine, sorry. Who is able to test that?

[Feelisreal]

I had a Canary version running on a external harddrive I will check if i still have it flying arround. But I would need instructionson how and what to test.

[daschuer]

Great! Thank you very much.

The instructions are here:
#12289 (comment)

Just unpack, open cmd.exe, cd to build folder and execute the given command and wait.

In case of failure it runs quite long.

[daschuer]

Any news? Did one find time for testing?

[Feelisreal]

I just tested with the 2024/01/03 Canary Built a lot of Errors and Failed I don't understand and

Media Foundation 10.0.26016.1000

IDK what that means hope it helps. I leave the system laying arround here in case you need more infos

[daschuer]

That sounds like bad news. Thank you very much for testing. In case of an error the test takes quite long. Before blaming Microsoft for not fixing the regression lets double check:

Do you see something like this during the test?

soundproxy_test.cpp(123): error: The difference between expected[i] and actual[i] is 0.72252137959003448, which exceeds kMaxDecodingError, where
expected[i] evaluates to 0.49337208271026611,
actual[i] evaluates to -0.22914929687976837, and
kMaxDecodingError evaluates to 0.0099999997764825821.

If you let it run until the end you should see something like this:

[  FAILED  ] SoundSourceProxyTest.seekForwardBackward (132200 ms)
[----------] 1 test from SoundSourceProxyTest (132200 ms total)

[----------] Global test environment tear-down
[==========] 1 test from 1 test suite ran. (132200 ms total)
[  PASSED  ] 0 tests.
[  FAILED  ] 1 test, listed below:
[  FAILED  ] SoundSourceProxyTest.seekForwardBackward

please confirm.

[Feelisreal]

I can see those exact two pessages only with different ms Values (of course)

I must state again though that the audible issues in Mixxx are gone with this version. I have a Song with a pessage that gives me this issue all the time and it runs smooth. But you will know what the test means and why its bad news

[daschuer]

Ok so the issue is solved half way.

The test checks if the decoder is able to reproduce the same samples when decoding a file from the beginning or seeking back. The difference can be a remaining subtile loudness change or a shift of beats. The test is obviously more critical than a human.

The issue for DJs is unwanted noise in loops and especially when jumping to a cue point at the end of the track or unpredictable cue points not always at a beat.
Is this an issue for you?

Please load a track and play it until the end without seeking and then place a cue at a significant position near the and. Eject the track, load it again and jump directly to the cue. Check if you hear the same sound as before. Thank you.

[JoergAtGithub]

This issue is about the loudness spikes and this is reported to be fixed in the Canary build.
The other issue with M4A decoder of Windows11 is #11094 - which is about the failing seek test with Windows 11.

[daschuer]

@Psychlist1972 Can you support us to report the remaining issue and get in contact with the right person at Microsoft?

Our unit test fails in case of random loudness spikes or timing offsets. It starts failing with Windows 11 because of loudness spikes and it still fails with the latest Canary build and Media Foundation 10.0.26016.1000.

[Psychlist1972]

@Psychlist1972 Can you support us to report the remaining issue and get in contact with the right person at Microsoft?

Our unit test fails in case of random loudness spikes or timing offsets. It starts failing with Windows 11 because of loudness spikes and it still fails with the latest Canary build and Media Foundation 10.0.26016.1000.

It's not clear to me how the Microsoft team can reproduce this problem, what they will see, and what they should expect to see. Can you all provide more step-by-step detail here so they don't have to guess? Thanks.

Even better if this can be captured in a trace in feedback hub and the link posted here, but I'm not sure if that is possible in this case.

I've sent a link to this post to the team. I'm off to NAMM, so please post updates here. Thanks!

Pete

[daschuer]

Dear Microsoft team,

here a short wrap up:

• We have the issue that we see different loudness at the same position when decoding an m4a file before and after seeks.
• We have a unit test in place that compares these two decoding. All sample difference need to be not greater than a reasonable epsilon for success.
• The last known good version is Media Foundation 10.0.17763.2989 OK
• Media Foundation 10.0.26016.1000 improves the situation, but is still failing the test.
• The test binary can be found here
• Unpack and navigate to the build folder and execute
• mixxx-test --gtest_filter=SoundSourceProxyTest.seekForwardBackward --developer
• wait a couple of minutes and watch for [ PASSED ] or [ FAILED ] at the very end
• find the source code here:

  mixxx/src/test/soundproxy_test.cpp

  Line 307 in a4ead51

  TEST_F(SoundSourceProxyTest, seekForwardBackward) {

• If you like to build the test yourself, follow https://github.com/mixxxdj/mixxx/wiki/Compiling-On-Windows
• Here is the seeking code with some descriptions:

  mixxx/src/sources/soundsourcemediafoundation.cpp

  Line 24 in a4ead51

  // "AAC Audio - Encoder Delay and Synchronization: The 2112 Sample Assumption"

Do you need anything else?

[daschuer]

Any Microsoft developer listening?

[Psychlist1972]

Any Microsoft developer listening?

I know some folks on that team were reading this stuff and looking at the tests. Not everyone likes to openly comment on GitHub and similar, though.

This second concern is a weird one, because the fix here (available later this month) effectively reverted us back old behavior. Apple uses one of the settings in the file in a weird (and potentially incorrect or at least unexpected) way when creating files from iTunes. iTunes knows how to read that for their purposes, but other software is going to interpret it the "correct" way, which results in what you all originally found. The fix ignores that, bringing us back to the old behavior.

So the team is looking at this, but it makes no sense that with the fix in place, there's a new problem that didn't also exist in Windows 10 as well. Has anyone verified that the unit test that is failing in Windows 11 Canary worked fine back in Windows 10?

The change is in the codec, nothing else.

Pete

[daschuer]

Not everyone likes to openly comment on GitHub and similar, though.

No problem, please contact me via my GitHub user name at mixxx.org.

This second concern is a weird one, because the fix here (available later this month) effectively reverted us back old behavior.

Oh, It really sounds like we have another overlapping issue. We run the test at the GitHub workflow runner with Media Foundation 10.0.17763.2989 on Microsoft Windows Server 2019 10.0.17763 and there the test succeeds. This means we can seek though the file and find the same samples on every path. The test fails in my Windows 10 virtual machine with Microsoft Media Foundation 10.0.19041.3636. and on another machine with Microsoft Media Foundation 10.0.19041.746

[daschuer]

@Psychlist1972 Do you have any news? Can we help somehow?

[Psychlist1972]

@Psychlist1972 Do you have any news? Can we help somehow?

The team is still investigating, and is going to get back to me. Whatever is going on here is unrelated to the decoder issue.

Are you all sure the test is doing what you think it should? As a developer there said "I’m not fully sure why their test is written [using this approach] and I’m a little wary of it depending on a fixed number of samples like that"

Is it testing something your app actually does?

Pete

[daschuer]

Mixxx has a caching reader, that keeps positions in cache for looping and jumping to cue points. Instead of buffering the whole file only these points of interest are buffered.

This approach requires to read exactly the same samples, independent what has been read before. We read some amount of samples to settle the decoder and make that true. In the past this works flawlessly with windows, but does no longer work.

We looking here for a solution to make it work. If it turns out that we neet to adjust Mixxx code for the new decoder it is also fine.

Are you all sure the test is doing what you think it should

I am confident, but not sure we have no bug.

The test does:

• First reads a chunk of frames without seeking
• Than repeat but with seeking
• Both buffers should be equal
• Seek backwards to beginning of chunk and read again
• Both buffers should again be equal

[Psychlist1972]

FYI. The fix for the original decoder issue reported is in today's release, according to the product team. I've had one person report that resulting volume is now too low, which would be strange given that the fix was, as I understand it, to revert back to old behavior and ignore the extra mobile info Apple is putting in there.

If anyone else tests this on the new release, please LMK your findings.

https://blogs.windows.com/windowsexperience/2024/02/29/microsoft-copilot-improvements-for-windows-11/

[Psychlist1972]

FYI. The fix for the volume spike problem went back out yesterday. LMK if that works for you.

[Feelisreal]

Since I got a new reply on the MIXXX Discourse for my original post. I will mark this as closed since I do not have those issues on MIXXX and WIndows 11 anymore. Thanks to everyone involved. Especially to @Psychlist1972 for pushing the issue at Microsoft and actually fixing it!