Closed Feelisreal closed 2 months ago
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?
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?
Can you please specify the exact Windows 10 version, where the issue did not occur.
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.
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
The m4a decoder on Windows 11 seems to be broken. We have https://github.com/mixxxdj/mixxx/issues/11094 that describes a broken unit test.
Do we know if Microsoft is aware of that? Where can we report bugs?
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
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?
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.
Do we know if Microsoft is aware of that? Where can we report bugs?
@psychlist1972 Could you establish a contact to the development team, that is responsible for the M4A audio decoder in Windows11?
@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
@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 https://github.com/mixxxdj/mixxx/issues/11094 about our own M4A unit tests failing):
@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
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.
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.
Yes, that could be useful. However you need to build Mixxx at home for testing at home.
To rerun the test, on GitHub, just apply https://github.com/daschuer/mixxx/commit/aaf8a11f0baac91122a7ccd419dd4789f2a87ddc and push. My test run has been removed from the history: https://github.com/daschuer/mixxx/actions/runs/5855464923
@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
@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
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
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:
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
@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.
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
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
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.
Are they able to provide the fix as an installer or set if DLLs? Than we can update the GitHub workflow runner.
Does the fix increase the version of the mfplat.dll? If yes, we are able to add a warning if the fix is not installed.
I personally have a windows 10 in a Virtual Box. It is not capable for the win 11 update. Or is there a way to install a canary win 11 in a virtual box?
I could try and see if I can get the canary insider built to run on an external harddrive and test. I might be able to look into that on the weekend
@Psychlist1972 Hey Pete, I have tested MIXXX and Rekordbox on the Canary Insider Built (On an external Harddrive and Windows To Go with Rufus) and I can confirm, that the issue does not occur anymore 🥳. All Audio runs smoothly in all Programs (including built in Mediaplayer). For the MIXXX Developers: from the first looks the Hotcues on Beatgrids are not shifted with the new Codec or API (I have not yet understood the fix).
Now we just have to hope for a quick roll-out which as far as I understand is not a straight path with the canary channel. But my trust in Windows is regained thanks to you Pete! I hope you can help so that the Fix makes it to Production soon!
I'll keep this issue open untill the Fix is rolled out
@Psychlist1972 Hey Pete, I have tested MIXXX and Rekordbox on the Canary Insider Built (On an external Harddrive and Windows To Go with Rufus) and I can confirm, that the issue does not occur anymore 🥳. All Audio runs smoothly in all Programs (including built in Mediaplayer). For the MIXXX Developers: from the first looks the Hotcues on Beatgrids are not shifted with the new Codec or API (I have not yet understood the fix).
Now we just have to hope for a quick roll-out which as far as I understand is not a straight path with the canary channel. But my trust in Windows is regained thanks to you Pete! I hope you can help so that the Fix makes it to Production soon!
I'll keep this issue open untill the Fix is rolled out
Awesome! Thanks for testing. I'll let the team know.
Pete
If any others are able to verify the fix in Canary, that would also be super helpful.
Once I know this is going out in retail channels, I'll let folks know.
Thanks again for @Feelisreal for the trace logs and report and @JoergAtGithub for the ping.
Pete
Nice to see how quick issues could be resolved if the right people start listening to each other. Thanks @Psychlist1972 for your coordination.
Unfortunately, I am not a Windows user ;) Nevertheless, I appreciate this semi-official move by Microsoft for reaching out!
@Feelisreal Can you report the Canary verison mfplat.dll and if you have the broken version as well? I consider to add a warning if one is using the broken version.
@Psychlist1972 I'll leave your reply from the Windows Forum here so we stay up to date here as well. Let's keep fingers crossed we can use MIXXX with m4a on Windows 11 soon
This fix has been scheduled to go out into retail Windows in February.
The holidays added a delay for rollouts, so this is the earliest possible time when it can go out.
Note that this is not a guarantee of when it will go out. It represents current plans.
Thanks
Pete
Thanks @Feelisreal
@Feelisreal Can you report the Canary verison mfplat.dll and if you have the broken version as well? I consider to add a warning if one is using the broken version.
It's the codec, from what I understand. I don't know which binary that's in, but it's quite likely that mfplat.dll won't change.
What is the alternative, to ping our users to update there Windows?
How is the situation here. Who has a machine with the fix installed? We need your help to adust our unit testes. Thank you.
Do we really need to adjust our unit tests? I expect that Windows11 version from Feb 2024 will have the same behavior as Windows7-10.
When everything is fine, only the comments need to be adjusted. But first of all we need to run them on a fixed system. It would be unfair to let Microsoft release a fix without confirmation at it fully fixed our issue.
Do we have an official reference of any type to the fix?
When everything is fine, only the comments need to be adjusted. But first of all we need to run them on a fixed system. It would be unfair to let Microsoft release a fix without confirmation at it fully fixed our issue.
Do we have an official reference of any type to the fix?
I'm not sure what you mean by "an official reference of any type". But if you have an additional PC for testing, you can install the latest Windows Insider Canary build there and verify the fix is present.
I run Canary as my daily driver, but I don't recommend everyone do that, especially since going back to retail involves reinstalling from scratch.
Pete
Cool, can you run the test for us? We can export it from a GitHub workflow.
I have uploaded here the working tree created from https://github.com/daschuer/mixxx/actions/runs/7298668710 https://drive.google.com/file/d/1cPDNmq48IezmvfATLL7LWEHMoUCMRPs0/view?usp=sharing In addition to the GitHub artifact I have added missing DLLs and made the paths in CMakeCache.txt relative.
I would like to ask anyone with a windows installation to run
mixxx-test --gtest_filter=SoundSourceProxyTest.seekForwardBackward --developer
from the build folder and report the Microsoft Media Foundation version.
Mine is 10.0.19041.3636 from Windows 10, Version 22H2 from the "Release Preview" channel and .... failing This is a bad news because by now only Win 11 was affected.
Here is a test how it looks like when failing: https://github.com/daschuer/mixxx/actions/runs/7285956895/job/19853789720
So if I read this right, this is a windows issue and a fix is planned to be rolled out in february? In that case, could we add something to the release notes about the problem and close this issue? It sounds like there is nothing we can do to address it short of holding back the release until the windows fix goes out, which I do not want to do.
The issue here is that we not even have a formal confirmation that it is really fixed bit perfect, which is verified by our unit-tests.
My idea was to add at least a warning into the log, that we have a hint in a support case that a broken windows version is used.
The pending work is to install the preview build, download the unit test I have packed execute it and report the results and the used Media Foundation version.
Is KB5032288 the update that includes the fix? Can one confirm?
My preview Windows 10 Virtual Box still fails.
@JoergAtGithub how is the situation on your devices?
Removing the Milestone for now, because this is no regression form Mixxx 2.4.
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.
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?
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:
I tried:
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