-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
First sound test #11887
First sound test #11887
Conversation
The new clang format insist to break the format. I suggest to just merge it as it is. I have no interest to debug it, since we run clang format on changes only. |
…fter updating soundsources.
b5b216a
to
37a86ed
Compare
Rebasing to the updated updated pre-commit does not help. I give up. |
Wrap the ifdef'd block with |
935e4f7
to
ff0d20e
Compare
I have no interest to maintain clang-format exceptions because they break nice formatted comments as well. |
This is now adjusted for the FPM_64BIT libmad version and merged from 2.4. |
CMakeLists.txt
Outdated
@@ -2797,6 +2797,7 @@ if(COREAUDIO) | |||
src/sources/soundsourcecoreaudio.cpp | |||
src/sources/v1/legacyaudiosourceadapter.cpp | |||
lib/apple/CAStreamBasicDescription.cpp | |||
src/util/macosversion.mm |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think this should be dependent on coreaudio... it'll probably get used somewhere else too in the future.
} else if (m_madStream.error == MAD_ERROR_BADDATAPTR && | ||
m_curFrameIndex == firstFrameIndex) { | ||
// This is expected after starting decoding with an offset |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
expected by us, but is it by MAD? Are we using MAD wrong here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have debugged into that and there is is nothing wrong. That why I have silenced the message.
You find this in other adoptions as well. Here for instance:
https://github.com/Sneeds-Feed-and-Seed/sneedacity/blob/5fba67545ca29d009b51d355687979a3996d252c/src/import/ImportMP3.cpp#L1093
UINT size; | ||
DWORD* fi; | ||
if (VerQueryValue(info.data(), L"\\", reinterpret_cast<void**>(&fi), &size) && size) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
either check all, or none;
UINT size; | |
DWORD* fi; | |
if (VerQueryValue(info.data(), L"\\", reinterpret_cast<void**>(&fi), &size) && size) { | |
UINT size = 0; | |
DWORD* fi = nullptr; | |
if (VerQueryValue(info.data(), L"\\", reinterpret_cast<void**>(&fi), &size) && size > 0 && fi != nullptr) { |
UINT size; | |
DWORD* fi; | |
if (VerQueryValue(info.data(), L"\\", reinterpret_cast<void**>(&fi), &size) && size) { | |
UINT size; | |
DWORD* fi; | |
if (VerQueryValue(info.data(), L"\\", reinterpret_cast<void**>(&fi), &size)) { |
DWORD* fi; | ||
if (VerQueryValue(info.data(), L"\\", reinterpret_cast<void**>(&fi), &size) && size) { | ||
const VS_FIXEDFILEINFO* verInfo = reinterpret_cast<const VS_FIXEDFILEINFO*>(fi); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
DWORD* fi; | |
if (VerQueryValue(info.data(), L"\\", reinterpret_cast<void**>(&fi), &size) && size) { | |
const VS_FIXEDFILEINFO* verInfo = reinterpret_cast<const VS_FIXEDFILEINFO*>(fi); | |
// iff VerQueryValue is called with "\", the version info is of type VS_FIXEDFILEINFO | |
VS_FIXEDFILEINFO* verInfo; | |
if (VerQueryValue(info.data(), L"\\", reinterpret_cast<void**>(&verInfo) && size) && size) { |
return QStringLiteral("%1.%2.%3.%4") | ||
.arg(HIWORD(verInfo->dwProductVersionMS)) | ||
.arg(LOWORD(verInfo->dwProductVersionMS)) | ||
.arg(HIWORD(verInfo->dwProductVersionLS)) | ||
.arg(LOWORD(verInfo->dwProductVersionLS)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
avoid unnecessary chaining
return QStringLiteral("%1.%2.%3.%4") | |
.arg(HIWORD(verInfo->dwProductVersionMS)) | |
.arg(LOWORD(verInfo->dwProductVersionMS)) | |
.arg(HIWORD(verInfo->dwProductVersionLS)) | |
.arg(LOWORD(verInfo->dwProductVersionLS)); | |
return QStringLiteral("%1.%2.%3.%4") | |
.arg(HIWORD(verInfo->dwProductVersionMS), | |
LOWORD(verInfo->dwProductVersionMS), | |
HIWORD(verInfo->dwProductVersionLS), | |
LOWORD(verInfo->dwProductVersionLS)); |
{QStringLiteral("cover-test.wav"), 1166}, | ||
{QStringLiteral("cover-test.wv"), 1166}}; | ||
|
||
for (const auto& ref : refs) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
have you considered writing a parametrized test? That would have the advantage that the test would not abort after the first failure and each first sound ref would be tested independently.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The test already continues when one test is failing. I am fine with the current implementation.
Co-authored-by: Swiftb0y <12380386+Swiftb0y@users.noreply.github.com>
return QStringLiteral("%1.%2.%3.%4").arg( | ||
QString::number(HIWORD(pVerInfo->dwProductVersionMS)), | ||
QString::number(LOWORD(pVerInfo->dwProductVersionMS)), | ||
QString::number(HIWORD(pVerInfo->dwProductVersionLS)), | ||
QString::number(LOWORD(pVerInfo->dwProductVersionLS))); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Really looking forward to Qt6 when we finally have a variadic QString::arg
...
4659439
to
f687745
Compare
The failing test confirms that the Media Foundation version is still read: |
f687745
to
96b00a7
Compare
All green now. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
any1 else wanting to take a look?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
Thank you! |
In an attempt to fix #11094 I have created a test that compares the first sound position of the current version with the position of future versions.
The idea was to replace the faulty 10.0.20348.1 Media Foundation version with FFmpeg.
This test exposes that this is not trivial, because the Media Foundation has an offset compared to FFmpeg according to a not yet known pattern.
We need further investigations to either fix #11094 with Media Foundation or mimic the offset behaviour with FFmpeg. The alternative would be to just swap to FFmpeg and tell the users to reanalyse the track and adust the cue points again.
In addition this has discovered a regression in the 2.3 branch where the
FPM_64BIT
has been lost:https://github.com/mixxxdj/buildserver/blob/2.3.x-windows/build/libmad-0.15.1b/msvc%2B%2B/libmad.vcxproj#L133
This falls back to 32 bit maths leading to significant rounding issues.
https://github.com/markjeee/libmad/blob/c2f96fa4166446ac99449bdf6905f4218fb7d6b5/fixed.h#L425
This version is the most portable but it loses significant accuracy.
This PR is just a test that aims to detect offset issues due to decoder update early and should be merged independently.