Host and client OS (identical installations of OS but different hardware): OpenSuse 11.4 Host with KVM 0.14 Guest OS: Windows XP SP3 and Windows 7 with latest stable qxl driver compiled from source spice-client-0.8.1 spice-server-0.8.1 Works fine with spice client on the host. But on both 32-bit and 64-bit client machines on the same network, playing a video will consistently result in the following symptoms. There is a very brief 0.5 sec blip in the audio when the video is started (so the initial audio is received) and then silence for 10-15 seconds and the audio starts with that delay. The video is playing smoothly. When the audio starts, it continues to play with the time offset (nothing is lost) and continues to play for the same offset even after the video is stopped. Seems like it is getting buffered somewhere. Network bandwidth isn't a problem. Videos play smoothly. Just the audio. This problem doesn't exist when the client is run on the host itself. Using bridged ethernet port on the host with virtio network drivers (happens without those drivers as well). I have been using the HTML5 and Flash player demo at http://sublimevideo.net/demo as a test page for audio/video. To see that this is not a problem related to video, I noticed the same problem with Skype calls. The Skype ringing audio starts 5-10 seconds after you see the call invite on the screen and continues for the same time after the call is answered. All audio is delayed after that point by the same amount. In each case there is a audio blip of the first fraction of a second. This happens even in the login music of Windows XP. A blip followed by a pause and the the rest of the music after a delay. Have tested with this two completely different client hardware one 32-bit and another 64-bit but with the same identical OS distro and software versions. Not sure what part I should be focusing on to investigate this. Server side delay? Client side delay? Alsa/Pulseaudio problems at the client? Problem with the Spice client (when on a remote client)?
This has become annoying enough to be not usable at all for anything with audio. I did some for empirical testing to see where the problem may be. Here are some observations: 1. When the audio starts to lag, the lag varies. Sometimes, it happens right at the Windows logon sound, sometimes later. But once it happens, the audio is consistently offset by that delay for further use, ie., there is no "catching up" possible even if you leave the guest and host on with no further audio sounds. 2. If I move to a different client machine and start spice client from there for the same guest desktop, the delay continues at that new client. This seems to suggest that the problem is at the host/guest end, not the client end. This client move could be to the host itself so that removes any network issues as being the problem. 3. To narrow it down between the guest and the host spice server, I bring up another VM guest and test. This seems to exhibit the same delay (not 100% sure about this but this test case should be tried). If this is consistent, then the problem would likely be in the spice host server, rather than in any guest drivers. I am running the 0.8.1 version of spice-server on OpenSuse 11.4 with KVM 0.14 as mentioned earlier. Anyone care about this? Any suggestion on what other empirical testing I can do to isolate it?
Am I the only one with this problem? I am able to reproduce this on three different hardware running the same configuration. To add to information, I have noticed that there is an initial audio that comes up for less than a second where it is supposed to and gets cut off and then continues after a delay. The longer the sound stream, longer seems to be the delay. Happens to any and all sound now. Happens to both Windows 7 and Windows XP guests. Even if the client is running on the host, so bandwidth is not the problem.
4 years since this bug was opened, there were a lot of improvements with audio in spice-gtk. I'll close this as fixed but feel free to open a new bug if you experience lag with audio again.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.