Guest audio playback sound like fast-forward tape.

[NoNoNo]

HOST is Windows 7 64-bit
GUEST is Windows XP

Additionally, some video playback be affected, too. (most files are MP4, quite few can test.)

Some walkaround I tried:

• Downgrade VBox to 5.1.30
  -> Good, Back to normal.
• Boot same VM Guest in Debian HOST (5.1.32)
  -> Good, Work as expected.

[Socratis]

This is a duplicate of about a dozen duplicates already. Please use the search functionality next time...

[boxer01]

You are missing a very important point here: this is the first time after a long time when the 5.1.x trunk also has this audio issues on Windows. I try to recapitulate: after initial release of 5.1.x in summer 2016 this sound problem appeared both on Windows and Linux hosts. Later the audio back end was replaced on Windows with previous one, so problems disappeared at least on Windows. They persisted on Linux. As for 5.2.x trunk, this one has audio issues from the very beginning on, both on Windows and Linux.

The 5.1.32 is the first version in over the year, where I have the same issues with audio as on 5.2.x. So now I’m back to the 5.1.30 as a stable version. It has other old audio issue, where the VM suddenly loose audio link to the host and the sound disappears completely in the guest until the VM restart, but not a sound distortion issue. So now somebody could analyze the 5.1.x trunk changes between the 5.1.30 and 32 and would probably see the changes causing this issue.

[boxer01]

Another question: should I file a separate ticket for this case? I mean that the 5.1.32 has now the same problems as 5.2.x? With some logs from 5.1.32?

[Socratis]

My first reply was that this is already a duplicate of about a dozen or more sound related tickets. That are being actively worked on. You want to open another duplicate? Why? To create additional load for the developers? It baffles me...

[boxer01]

Let me explain once again, why I think that this isn’t a duplicate of many other audio problem reports, but the new one. After release of 5.1 in summer 2016 it has had some problems with audio emulation. After some month the new audio back-end was replaced with an old one in 5.1.10 on Windows. More than a year within 10 build it worked fine. But between 5.1.30 and 5.1.32 somebody made some changes which now causes the same erratic behavior as in 5.2.x version. I just like to stress this in my opinion important difference. So somebody could analyze the change-set and probably find the change which is the reason for all this havoc in both currently supported versions. Or maybe not, but this should be worth a simple try.

My second question was: should I file another ticket with this very explanation, because this ticket describes a little bit different issue. Should I make some audio logs from 5.1.32 or do you think that they wouldn’t be different from the 5.2.x line? BTW, I can also post this logs here, if this could help in fixing this bug.

[robpats]

I have the same issue on Windows XP guest with VirtualBox 5.1.32 and 5.1.34 but not 5.2.6.

I posted logs in https://www.virtualbox.org/ticket/17469#comment:1

[NoNoNo]

Things I would like to add but without log to proof it.

• After Guest(WinXP) login, system clock looks out-of-sync, observably about 0 to 5 seconds faster, compare to Host(Win7) clock.
• Clock eventually sync after another dozen minutes. Does this is normal behavior?
• About video files playback, Most files without audio track will play in normal speed, and most files with audio track will play in very fast speed-- no matter video track's codec is.

Lastly, give VBox 5.1.37-122139 a try -- sounds same as previous post.

[ManWithNoName]

I have the same problem.

Host : Windows v10.0.17134.48

Guest : Windows XP v5.1.2600

VBox : v5.1.36

VBox Sound Settings : Audio Host Driver -> Windows DirectSound & Audio Ctrl -> ICHAC97

I have tried to capture a video but sound is not recorded. (capture via the VBox Video Capture feature and also "externally" via VLC -> Desktop Video Capture)

[NoNoNo]

Today, try with Vbox 5.2.20 r125813 @ windows 7 HOST, (all the same system setting)

Boot up Windows XP GUEST, when startup progress finished, looks (and sounds..)very neat at first.

The sound is good for most of Windows XP's PCM (windows'startup.wav...), other PCM not play well, some very short (less than 1 second) PCM files play no sound or sound loop infinity , some un-common used bitrate mono PCM files were no play at all.

For multimedia application, like music player with some MP3 files. Music outputted as expected, said, about 5 minutes music can play well. while there were a gap/latency that human can notice. Sound output lag behind about 500~1500ms

For video files playback, the sound is out-of-sync with video frame, about 500~1500ms. For PC Game also the same lag of sound.

Also ​posted replies here @forums.

update: Try testbuild 5.2.21 r125885, and behave same as 5.2.20

[NoNoNo]

Try Vbox 5.2.28 (r130011) @ windows 7 HOST, (all the same system setting)

Now, Windows XP GUEST has better sound than previous=VBox 5.2.20. There may still have a playback gap/latency but my ears heard no latency.

For very short (less than 1 second) PCM files playback, It's still no sound. Included log and debug wave files. Wave file content is:

"Windows OS Startup", "Pop" repeat 5 times (very short), "Windows OS shutdown"

What I can not hear in VM is that very short "pop" PCM file.

This is link of Log and Wave file: ​xp_log_wave.zip (let me know if link is dead)

[SamR]

I have the same issue in 6.0.8 running XP guest in Win10-64 bit host. Capturing a video file without sound works properly, but when adding sound input, the captured file runs at least two times too fast. Sounds like Tiny Tim. Not just the audio, but the video also plays back at the higher speed. It does not matter what app I use to play it back (the capture software or Movie Maker) or whether it plays from inside the VM XP or directly from the host. So it must be capturing the clock signal incorrectly when sound is turned on. There does not seem to be a way to chose a different audio controller as some have suggested.