Sound is very choppy as of 3.2

Description

I am using a Mac OS X 10.6.3 host on a Macbook4,1 (early '08), and with both Windows XP and Ubuntu Linux (8.04) guests, I am getting very choppy audio. It seems to happen more with sounds with short duration, like error sounds. The login sound is also very choppy. I've noticed some small amount of choppiness before, but it is now very severe. I can submit any logs/core dumps/etc requested.

I have found this on my Linux x64 host with linux and windows clients (32bit and 64bit). It first showed up for me in 3.2 but downgrading to 3.1.8 the issue was evident there as well. Version 3.1.6 does not have this problem. I have verified on my system that 3.2.2 and 3.2.4 also have the choppy sound issue. The issue goes away when removing the current version and reinstalling 3.1.6.

To me is sounds like a driver timing issue. Maybe unrelated but after jumping from 3.1.6 I/O on 3.2 was horrible. The system doesn't go into I/O storm in 3.2.2 but I have trouble running 2 clients concurrently. I have yet to test 2 clients in 3.2.4.

I still have this bug, but strangely the sound is choppy only at startup in my case ! I just tried playing some songs on deezer.com and no lag at all… System alert sounds too are fine. I'll retry with a game in the next days.

I can confirm that I have the same issue. The sound is very choppy (unbearable to hear). Host - arch linux kernel 2.6.35, alsa - 1.0.23, virtualbox - 3.2.8. Guest - windows xp sp3, vbox additions installed. I have tried both Alsa and OSS drivers with the same results.

I do supply information: I'm saying that the problem persists. I didn't think the log would be of much help in this case, sorry about that, I will attach it.

This ticket's problem is that the sound is very choppy. Since the sound is still choppy, this ticket problem is not completely solved. The bug that was thought to be the cause, or that was actually the cause of this problem in some cases, is (i guess) solved. I don't see any point in opening a new ticket with exactly the same description.

I was not complaining, I was _informing_ that the problem is not fixed, since thinking it is fixed won't help fixing it.

I'm having this problem as well - Host is Linux x86_64, guest Windows XP, Audio output ALSA / ICH AC97. I can play back audio with Windows Media Player just fine, but when I play the same file with VLC, it's a choppy, noisy mess.

I am using Windows7 x64 guest on Ubuntu 10.10, I am using Windows for Visual Studio / Adobe and subscription music services. I was having the choppy sound issue, It went crazy anytime I did anything graphics or cpu intense on the linux host even with virtualbox minimized which makes sense. But I knew it had to be some kind of virtual box guest->host communication issue maay just not have the proper priority. I have verified that the Audio hardware emulation is perfect. The workaround for me is to RDP into Windows 7 from the Terminal Server Client within Ubuntu. The sound is then flawless. Maybe VBox needs to borrow some ideas, maybe making an audio driver that communicates over a TCP stream instead of w/e guest->host communication they are currently using. This is actually something that could probably be developed by a third party ... Also VLC might already be capable of transmitting the flawlessly created sound from the guest to the host. Im just glad I have my sound now, but it would be nice if Virtual Box had proper sound support natively. I have not tried the RDP extension withing Virtual Box yet but I imagine it will suffer the same choppy audio as it is outside of the emulator where the RDP Server resides.

Hopefully this helps the VBox community as well as the developers diagnose and resolve or work around the problem.

I am using Windows 7 Ultimate x32 guest on an Ubuntu 10.04 x64 host, and one of the major reasons for me virtualizing was so I could watch Netflix without having to dual-boot. Unfortunately, I am suffering the same choppy sound as everyone else here. I use the ALSA / ICH AC97 combo. I have VirtualBox 4.0.6 r71344 installed. I have attached my log file. Any help would be appreciated. I haven't tried RDP, yet, but will in a minute.

The workaround for me is to RDP into Windows 7 from the Terminal Server Client within Ubuntu.

I just tried using Terminal Server Client to RDP into my Windows 7, but it didn't work. Anything special I need to know about RDPing into a virtualized machine? The error reads: "ERROR: 10.0.2.15: unable to connect".

I just found a solution that works for me. As I noted previously, I am running VirtualBox 4.0.6 on Ubuntu 10.04 x64, with a Windows 7 x32 guest. Sound was very scratchy with the ALSA / ICH AC97 combo. I followed the instructions in this thread: http://forums.virtualbox.org/viewtopic.php?p=51237#p51237 (creating a .asoundrc file in my home directory) which fixed the problem. I now use Pulse audio. Next step is to get the video smoothed out....

Can anybody guide me through the RDP workaround? I don't know what that is...

*RDP Workaround*

The RDP Workaround requires a Pro or Server Guest OS, Windows XP Pro, I was using Windows 7 Professional ... This does not use the Virtual Box built in RDP as it would route the sound after the hardware issue so itl still be choppy

I've tried that. I run tsclient and got a dialog window where I entered the server ip, user name etc. When I clicked "connect" the window disappeared (without any error message) and nothing happened. The tsclient process seems to be still running but I don't see any client window.

What am I missing?

I launched it by typint "tsclient &" from a terminal (I'm on a ubuntu host).

But by the way won't that add a tremendous overhead to everything, especially graphics??

I had staticky audio using Virtual Box "Alsa / ICH AC97" emulation within Windows XP guest on Linux/ALSA/JACK. The other Alsa drivers, Intel HD and Soundblaster 16, failed to work. The OSS drivers also seemed to appear to fail in the past until now with virtualbox-4.1.24.

How I resolved my poor audio playback:

1) Choose Audio driver: OSS

2) Choose Audio Controller: ICH A97

3) Make sure you don't have Jack Audio running, or other audio processes using the audio device.

This is the first time in a long time I've finally gotten sound to work with decent quality in a long time! Now, to try to get things playing nice with Jack.

(For me, only Soundblaster 16 works on x86/32bit platforms, and the above for my 64bit platoform. No other driver/controller combo works, or works adequately.)

At the moment there is no direct investigation going on here. The reason is that quality of the sound emulation in a virtualized environment depends heavily on the environment (guest, host, host hardware) and it is hard to take every bit into account. Several audio backends allow the tuning of some buffer parameters (actually not yet documented, we want to fix this eventually). Also, there are many many other problems open, and it the goal of the VirtualBox developers at Oracle, to prioritize problems. Bugs/requests from paying customers have a higher priority. Bugs which affect the host/guest availability/stability or security have a higher priority either. It does not matter if a bug is open for 3 days, 3 weeks or 3 years, sorry.

As we are currently rewriting the VT-x/AMD-V code in VirtualBox, this might also influence such scheduling problems.

I ran into a problem with choppy sound with a Windows XP Pro SP3 guest and the ICH AC97 audio controller. It happened in VirtualBox versions 4.2.16 and 4.3 on hosts running Windows 8.1 and Ubuntu 12.04 (Linux kernel 3.2.0-55-generic, PulseAudio). Switching the guest audio controller to SB16 made the audio less choppy but did not eliminate the problem completely. What resolved the sound issues for me was the solution from http://superuser.com/a/271736. This resolved all sound issues with a Windows XP guest on every host computer/OS combination I tried. The instructions are reproduced below:

I also investigated the cause for the Windows XP guest selecting the wrong driver. In our case it looks like the use of the nLite deployment tool to integrate driver packs into the OS disc image before installation is to blame. Specifically, integrating DriverPack Sound B (http://driverpacks.net/node/735/drivers) into a Windows XP installation CD leads to the wrong driver being used for the virtual sound device. I tried it and it did not happen with an unaltered original Windows XP Professional installation CD.