[MMEBUDDY] Implement support for looped wave playback #6761
Conversation
JoachimHenze
left a comment
JoachimHenze
left a comment
There was a problem hiding this comment.
Absolutely outstanding Oleg! I waited almost 10 years to get that bug fixed. The playback is perfect with your patch!
|
https://build.reactos.org/#/builders/9/builds/36279 is running (against the testbots)... |
|
Just retested, everything still works same as before, no any regressions after applying the suggestions. So LGTM. ✅ |
HBelusca
left a comment
HBelusca
left a comment
There was a problem hiding this comment.
LGTM. One trace was missing newline though.
|
✅ Still works fine for me. No any regressions. |
SergeGautherie
left a comment
SergeGautherie
left a comment
There was a problem hiding this comment.
With regard to this PR's limited scope, LGTM now to make a step forward.
I'll trust Oleg that existing surrounding code works as expected,
though 'I would feel safer if [extra call removal] was done (separately) before committing the current PR.'
Fix playing wave header multiple times in case the caller requests to do it. In Windows, it is supported by WHDR_BEGINLOOP and WHDR_ENDLOOP flags (specified together) and dwLoops member of WAVEHDR structure (ususally set to 0xFFFFFFFF (INFINITE constant)). - Check whenther WHDR_BEGINLOOP | WHDR_ENDLOOP flags are set by the caller. - If they are, get the amount of times to play the header from WAVEHDR.dwLoops. - Perform wave header competion only when the loop count is equal to zero. Otherwise, don't do it. - When the header is entirely committed, in case completion is not needed, reset committed bytes count to the starting value to allow the header play again. - Decrement loop count in case it isn't set to INFINITE, to mark loop as played correctly. When this count becomes zero, then the playback is finished. - Get rid from SOUND_OVERLAPPED.PerformCompletion member. Use SOUND_DEVICE_INSTANCE.LoopsRemaining == 0 condition instead. - Do this only for WaveOut devices, since MSDN states it works only with output buffers. Hence, there is nothing changed for WaveIn. - Update an appropriate statement about unimplemented functionality from mmebuddy notes. TODO: probably handle the case when multiple headers are requested to be looped (WHDR_BEGINLOOP and WHDR_ENDLOOP are set separatedly: 1st flag - in the 1st header, and 2nd in the last header). Currently, only looping a single wave header is supported (if I'm not wrong here). This fixes the playback in the apps those request looped wave playback of some audio data (e. g., BRD Demo app, which did play its sound only first 500 ms before, now it plays endlessly until closing it manually). CORE-10118
oleg-dubinskiy
force-pushed
the
wave_looped_playback_support
branch
from
d9ecbdd to
d5f2118
Compare
6 participants
Purpose
Fix playing wave header multiple times in case the caller requests to do it. In Windows, it is supported by
WHDR_BEGINLOOPandWHDR_ENDLOOPflags (specified together) anddwLoopsmember ofWAVEHDRstructure (ususally set to0xFFFFFFFF(INFINITEconstant)).This fixes the playback in the apps those request looped wave playback of some audio data (e. g., BRD Demo app, which did play its sound only first 500 ms before, now it plays endlessly until closing it manually).
JIRA issue: CORE-10118
Proposed changes
WHDR_BEGINLOOP | WHDR_ENDLOOPflags are set by the caller.WAVEHDR.dwLoops.INFINITE, to mark loop as played correctly. When this count becomes zero, then the playback is finished.SOUND_OVERLAPPED.PerformCompletionmember. UseSOUND_DEVICE_INSTANCE.LoopsRemaining == 0condition instead.TODO
WHDR_BEGINLOOPandWHDR_ENDLOOPare set separatedly: 1st flag - in the 1st header, and 2nd in the last header). Currently, only looping a single wave header is supported (if I'm not wrong here).Result
As visible in the following video, BRD demo app from the ticket is now playing the sound correctly after my changes. 🙂 Also, Minitube 2.4 Keygen also plays the sound correctly now, as it did not play it before them.
BRD_test.webm