https://bugs.winehq.org/show_bug.cgi?id=38421
Bug ID: 38421 Summary: Windows Media Player 9 & 10: mp3 sound plays too fast Product: Wine Version: 1.7.34 Hardware: x86 OS: Linux Status: NEW Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: dimesio@earthlink.net Distribution: ---
To reproduce, install WMP10 with winetricks and play an mp3 file.
Setting version based on regression test results, but the problem is still present in wine-1.7.40-156-gba00e8e.
Regression test results:
5c91d011bbdff0cac6535c866ef5498b1ddc42c7 is the first bad commit commit 5c91d011bbdff0cac6535c866ef5498b1ddc42c7 Author: Nikolay Sivov nsivov@codeweavers.com Date: Mon Dec 29 00:13:56 2014 +0300
msdmo: Registry API functions don't return HRESULT codes.
:040000 040000 dd337587dde868375ad75d4fd6adcc590453375c 35cf0352b6c68488c4b17f2064575eec35eb25aa M dlls
The patch can't be reverted cleanly. The results seemed odd, so I ran the regression test a second time and got the same result.
Winetricks quartz devenum works around it.
https://bugs.winehq.org/show_bug.cgi?id=38421
Rosanne DiMesio dimesio@earthlink.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression CC| |bunglehead@gmail.com Regression SHA1| |5c91d011bbdff0cac6535c866ef | |5498b1ddc42c7
https://bugs.winehq.org/show_bug.cgi?id=38421
--- Comment #1 from Nikolay Sivov bunglehead@gmail.com --- Is it install time issue or is it fixable with native quartz devenum after installation?
https://bugs.winehq.org/show_bug.cgi?id=38421
--- Comment #2 from Rosanne DiMesio dimesio@earthlink.net --- You can add them after installation.
https://bugs.winehq.org/show_bug.cgi?id=38421
--- Comment #3 from Rosanne DiMesio dimesio@earthlink.net --- Turns out the workaround only works for WMP10; native quartz and devenum just crash WMP9.
https://bugs.winehq.org/show_bug.cgi?id=38421
--- Comment #4 from Nikolay Sivov bunglehead@gmail.com --- I'll take a look soon.
https://bugs.winehq.org/show_bug.cgi?id=38421
--- Comment #5 from Nikolay Sivov bunglehead@gmail.com --- Yes, I can confirm that it's related to this patch. So far I can see that making DMOGetName() return a code on failure that passes SUCCEEDED() check makes it work properly again. However it's not a right thing to, as my patch shows https://www.winehq.org/pipermail/wine-patches/2015-April/138796.html - we should really return E_FAIL in this case.
What wmp does doesn't make much sense - it tries DMOGetName for every guid in HKLM\Software\Microsoft\MediaPlayer\NodeCLSIDs. I checked on windows and DMOGetName fails on such guids as expected.
So it looks like this change uncovered some other problem, which is good in general.
https://bugs.winehq.org/show_bug.cgi?id=38421
--- Comment #6 from Nikolay Sivov bunglehead@gmail.com --- It tries to enumerate DMOs with DMOEnum() looking for MP3->PCM capable object, on Windows it should work as it has mp3dmod.dll registered for this category. After this lookup fails it uses another way to play it, for which DMOGetName doesn't work (as it should). I'll try to see what happens with native quartz.
https://bugs.winehq.org/show_bug.cgi?id=38421
--- Comment #7 from Rosanne DiMesio dimesio@earthlink.net --- Still present in 1.8-rc1.
https://bugs.winehq.org/show_bug.cgi?id=38421
--- Comment #8 from Rosanne DiMesio dimesio@earthlink.net --- Still present in 2.0-rc1.
https://bugs.winehq.org/show_bug.cgi?id=38421
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12@gmail.com
--- Comment #9 from Zebediah Figura z.figura12@gmail.com --- Created attachment 58481 --> https://bugs.winehq.org/attachment.cgi?id=58481 PATCH: Use nAvgBytesPerSec to calculate length
There are two different unrelated bugs here, although I suspect only one was actually encountered. The first is that .wav files encoded with mp3 played too fast at a constant rate. This should be fixed by the attached patch, which I have submitted to wine-patches as well.
The second and probably more relevant bug, which affects plain .mp3 files, stems from something removing silence from the audio. The program first converts the mp3 to wav via msacm, and this works correctly, however, the samples it passes in to DirectShow have any sound quieter than some level truncated out. I would guess that the program is doing this, and not WINE, but I have no idea why.
https://bugs.winehq.org/show_bug.cgi?id=38421
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |quartz
--- Comment #10 from Zebediah Figura z.figura12@gmail.com --- Now that I have a better understanding of how quartz works:
The program is chaining a series of filters with the names:
WMRenderer Source Filter -> WMPlayer Time Compression DMO -> Volume Normalization DMO -> Seamless Audio DMO -> WMPlayer SRSWow DMO -> WMPlayer Equalizer DMO -> WMPlayer Spectrum Analyzer DMO -> Audio Renderer
Only the last one is ours. The source filter internally uses msacm32 to convert mp3 to wav. But the problem isn't there; indeed using native l3codeca.acm shows the same problem. The problem is actually the "Seamless Audio DMO", which seems to be completely dropping any samples which are quieter than a certain cutoff. Sort of like a gate, except that the samples are removed completely rather than just being truncated to silence.
I think the regression is not because it couldn't find an mp3 -> wav DMO (there isn't necessarily one on Windows either), but rather because if DMOGetName() works it won't add these intermediate filters.
Since native quartz fixes the problem, I'm setting the component to quartz. It's not clear what we should be doing—either not adding the filter, or perhaps there's something wrong with how we're passing samples around.
https://bugs.winehq.org/show_bug.cgi?id=38421
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |b9073b1e94d7be21cc2ee2ada88 | |8eb1f0a019c52 Status|NEW |RESOLVED Resolution|--- |FIXED
--- Comment #11 from Zebediah Figura z.figura12@gmail.com --- Fixed by https://source.winehq.org/git/wine.git/commitdiff/b9073b1e94d7be21cc2ee2ada888eb1f0a019c52.
https://bugs.winehq.org/show_bug.cgi?id=38421
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #12 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 4.12.
https://bugs.winehq.org/show_bug.cgi?id=38421
Michael Stefaniuc mstefani@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|--- |4.0.x
https://bugs.winehq.org/show_bug.cgi?id=38421
Michael Stefaniuc mstefani@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|4.0.x |---
--- Comment #13 from Michael Stefaniuc mstefani@winehq.org --- Removing the 4.0.x milestone from bug fixes included in 4.0.3.
-
wine-bugs＠winehq.org -
WineHQ Bugzilla