[Bug 38421] New: Windows Media Player 9 & 10: mp3 sound plays too fast
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(a)winehq.org Reporter: dimesio(a)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(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=38421 Rosanne DiMesio <dimesio(a)earthlink.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression CC| |bunglehead(a)gmail.com Regression SHA1| |5c91d011bbdff0cac6535c866ef | |5498b1ddc42c7 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=38421 --- Comment #1 from Nikolay Sivov <bunglehead(a)gmail.com> --- Is it install time issue or is it fixable with native quartz devenum after installation? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=38421 --- Comment #2 from Rosanne DiMesio <dimesio(a)earthlink.net> --- You can add them after installation. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=38421 --- Comment #3 from Rosanne DiMesio <dimesio(a)earthlink.net> --- Turns out the workaround only works for WMP10; native quartz and devenum just crash WMP9. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=38421 --- Comment #4 from Nikolay Sivov <bunglehead(a)gmail.com> --- I'll take a look soon. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=38421 --- Comment #5 from Nikolay Sivov <bunglehead(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=38421 --- Comment #6 from Nikolay Sivov <bunglehead(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=38421 --- Comment #7 from Rosanne DiMesio <dimesio(a)earthlink.net> --- Still present in 1.8-rc1. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=38421 --- Comment #8 from Rosanne DiMesio <dimesio(a)earthlink.net> --- Still present in 2.0-rc1. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=38421 Zebediah Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12(a)gmail.com --- Comment #9 from Zebediah Figura <z.figura12(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=38421 Zebediah Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |quartz --- Comment #10 from Zebediah Figura <z.figura12(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=38421 Zebediah Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |b9073b1e94d7be21cc2ee2ada88 | |8eb1f0a019c52 Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #11 from Zebediah Figura <z.figura12(a)gmail.com> --- Fixed by <https://source.winehq.org/git/wine.git/commitdiff/b9073b1e94d7be21cc2ee2ada888eb1f0a019c52>. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=38421 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #12 from Alexandre Julliard <julliard(a)winehq.org> --- Closing bugs fixed in 4.12. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=38421 Michael Stefaniuc <mstefani(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|--- |4.0.x -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=38421 Michael Stefaniuc <mstefani(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|4.0.x |--- --- Comment #13 from Michael Stefaniuc <mstefani(a)winehq.org> --- Removing the 4.0.x milestone from bug fixes included in 4.0.3. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (2)
-
wine-bugs＠winehq.org -
WineHQ Bugzilla