0
\$\begingroup\$

I am writing a playback mechanism for looping background music with XAudio2 and SharpDX.

I converted some perfectly looping WAV files to XWM(A) with the xWMAEncode command line utility (from the DX SDK of June 2010), but as soon as I play back the XWM file in a looping audio buffer, I notice a significantly noticable silence before it loops over.

I found out that when filling an XAudio2 audio buffer manually with a synthesized vibrato sound, no looping bug occurs. To further support this, I decoded the XWM file back into WAV, and the WAV file had exactly the same amount of silence at the end as I noticed in the playback, which turns out to be of 0,06 seconds length:

XWMA sound bug

My first question is if anyone noticed the same behavior of the xWMAEncode utility, and if it is either a bug of the utility or even of the XWMA format itself.

I'd love to know some workaround for this if it can't be fixed by the encoding of the WAV itself.

I thought of setting the LoopLength sample of the audio buffer to exactly before the silence occurs. But for that I'd need to pray that such a silence isn't dynamic depending on the sample rate. Has anyone fixed it like this before and can provide or link me to details about this?


Head-shaking corner: MP3 adds silence to the start of each file, so XWM likes to put it at the end? Do we live in times were only OGG gets stuff looping correctly?

\$\endgroup\$
  • \$\begingroup\$ If you read the xwmaencode documentation in the legacy DirectX SDK Documentation CTM, it states: "Note that when looping xWMA audio, a period of silence can be introduced. Because of this possibility, looping xWMA audio should generally only be used with sounds that have smooth fade ins and outs (such as ocean waves or other subtle ambient loops)." \$\endgroup\$ – Chuck Walbourn Apr 10 '15 at 19:54
  • \$\begingroup\$ I see. I think that comes from the block length a XWMA file has to be aligned with for the play or loop points at least. Kinda stupid... probably gotta decode OGG anyways, because I also noticed that XWMA has bad quality for most of the music I now have tested. \$\endgroup\$ – Ray Apr 10 '15 at 21:01
0
\$\begingroup\$

This is 'by design'.

See the DirectX SDK documentation under the topic "xWMA Overview"

xWMA Looping xWMA does not support loop regions or looping of arbitrary packets within an xWMA file. Only an entire xWMA file may be looped. XACT enforces this restriction, and no special treatment is needed. In XAudio2 xWMA has the following rules related to looping for the values in the XAUDIO2_BUFFER that is passed to IXAudio2SourceVoice::SubmitSourceBuffer.

If all of the xWMA file's audio data is submitted as one buffer and the user wants to loop it, the following restrictions must be met.

XAUDIO2_BUFFER.LoopBegin must always be zero.

XAUDIO2_BUFFER.LoopLength must be the size, in samples, of the entire file's xWMA data or 0.

XAUDIO2_BUFFER.LoopCount can be any value.

XAUDIO2_BUFFER.Flags must be set to XAUDIO2_END_OF_STREAM.

If xWMA audio data is submitted as more than one buffer the audio can only be looped manually by resubmitting the series of buffers.

Note that when looping xWMA audio, a period of silence can be introduced. Because of this possibility, looping xWMA audio should generally only be used with sounds that have smooth fade ins and outs (such as ocean waves or other subtle ambient loops).

\$\endgroup\$
  • \$\begingroup\$ Thanks for the quote. I thought I can get a nice compression easily with XWMA, but due to the looping / quality restrictions and rare encoder support, I'll implement OGG again. \$\endgroup\$ – Ray Apr 14 '15 at 7:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.