VirtualBox

Ticket #4605 (reopened defect)

Opened 5 years ago

Last modified 2 months ago

Ubuntu Linux guest audio output slow and distorted

Reported by: lshurr Owned by:
Priority: major Component: audio
Version: VirtualBox 3.0.2 Keywords: slow tempo low pitch distortion
Cc: Guest type: Linux
Host type: Windows

Description

There's some discussion in community forums related to this, but it doesn't go very far. Couldn't find any similar report in Bugtracker. Sorry if I overlooked.

This is an Ubuntu Linux 9.0.4 guest in Virtualbox 3.0.2 r49928 on a Vista SP1 host, a Presario C751 notebook. Following initial installation of the guest, sound playback works well. Only after shutting down the VM completely and then restarting will sound playback slow down with a commensurate lowering of pitch as though the clock is running slow. Sound distortion such as "chirping" and stuttering may be evident as well. The problem is temporarily repaired by reinstalling the Guest Additions and rebooting the VM (reboot only, don't shut it down!). Having done that, audio playback is restored to normal and will remain normal between reboots of the VM. Only after the VM is shut down will the problem recur. The same problem occurred in V 2.2.4 r47978. FWIW Video output seems to be affected as well.

A Windows XP SP3 guest does not seem to exhibit the same problem.

Using a VM for multimedia apps is silly, but what's amazing is how well it works when it works. It's not the way to go, but even if you don't, Ubuntu, for example, makes sounds like the drumbeat figure when GDM is ready for login, the Ubuntu "theme" as GNOME comes up and other sounds such as error notifications and the like and it is irritating for them to be slow, off pitch and distorted. More importantly, the fact that it sometimes works and sometimes doesn't implies an underlying problem that may be more significant.

If I can, I will dissect the Guest Additions installation and try to determine what seems to "fix" the problem.

Attachments

good_audio.dmesg Download (23.3 KB) - added by claudio_ 4 years ago.
This is the dmesg output in the good case, i.e. audio has correct pitch.
bad_audio.dmsg Download (23.2 KB) - added by claudio_ 4 years ago.
This is the dmesg output in the bad case, i.e. audio pitch is much lower than it should be.
dmesg.ac97.clock.slow.txt Download (17.9 KB) - added by lshurr 4 years ago.
This file as after the first reboot following reinstall of the Guest Additions. Sound output is slow and distorted.
dmesg.ac97.clock.48000.txt Download (17.7 KB) - added by lshurr 4 years ago.
This file is from a subsequent emulated power cycle. Sound is normal hereafter unless there is a crash or a new kernel is installed.
bad_high_audio.dmsg Download (23.1 KB) - added by claudio_ 4 years ago.
dmesg with high pitch
sound Download (150 bytes) - added by lshurr 4 years ago.
Place in /etc/modprobe.d to activate the ac97 clock workaround discussed in this thread

Change History

comment:1 Changed 5 years ago by lshurr

FWIW the fault does not occur on a Windows XP SP 3 host. Of course the XP host's hardware is different, as well, so the comparison's not "pure".

comment:2 Changed 5 years ago by lshurr

It's not much of a dissection so far, but it turns out that the Guest Addtions install scripts take arguments and "bash VBoxLinuxAdditions-x86.run kernel-module" followed by rebooting the VM is sufficient to correct the audio. This workaround still gets undone somehow when the VM is shut down. Audio is still slow and distorted when the VM is restarted. Curiously, the degree of slowdown/distortion varies from session to session.

comment:3 Changed 5 years ago by lshurr

Well, I made a mistake in my observations. It's true that the degree of slowdown/distortion seemed to vary, but in each instance, I had reinstalled Guest Additions. It turns out, at least in my case, that if you simply shutdown the VM completely and then restart it one more time, the problem goes away. Something funny's going on, but it seems to go away.

Looking back, I see that I let this bug report be rated major by default,which may not have been the right rating even given my understanding of the problem at the time. I think it should be rated lower, now.

comment:4 Changed 5 years ago by lshurr

If it tells you anything useful, software crashes cause a temporary return of symptoms. If Linux crashes or otherwise ends abnormally, it seems that the next boot will exhibit slow audio. You'll have to shutdown and restart the VM to "fix" it. After a little work, I have managed to get openSUSE 11.1 running the Plasma/KDE4 desktop running well as a guest. Once, Plasma took an abnormal exit on me and when it restarted, you guessed it, audio was slow. Had to shutdown and restart to "fix" it.

comment:5 follow-up: ↓ 6 Changed 4 years ago by claudio_

This problem still perstist in VirtualBox 3.1.0 r55467.

Host OS is OS X Snow Leopard 10.6.2 Darwin garfield1.lan 10.2.0 Darwin Kernel Version 10.2.0: Tue Nov 3 10:37:10 PST 2009; root:xnu-1486.2.11~1/RELEASE_I386 i386

Guest OS is Ubuntu 9.10 Linux garfield.inodes.ch 2.6.31-15-generic #50-Ubuntu SMP Tue Nov 10 14:54:29 UTC 2009 i686 GNU/Linux

After installing the VirtualBox GuestAddition for 3.1.0 (overwriting those of 3.0.12) and restarting Ubuntu audio was ok.

The next time I started VirtualBox and Ubuntu audio had a low pitch again.

In both instances I took dmesg outputs which I will attach to this bug report. One thing I notice towards the end: In the good case Linux tries to figure out the audio clock rate and does not succeed - I suppose it thinks the measured rate is off limits - thus sets the sample rate to 48000. In the bad case it seem to figure out an acceptable rate and sets that.

Changed 4 years ago by claudio_

This is the dmesg output in the good case, i.e. audio has correct pitch.

comment:6 in reply to: ↑ 5 Changed 4 years ago by claudio_

Replying to claudio_:

In both instances I took dmesg outputs which I will attach to this bug report. One thing I notice towards the end: In the good case Linux tries to figure out the audio clock rate and does not succeed - I suppose it thinks the measured rate is off limits - thus sets the sample rate to 48000. In the bad case it seem to figure out an acceptable rate and sets that.

What I forgot to write. The bad and good case also differ - as one can see in the first part of the dmesg output - in the CPU frequency detected. 470 MHz in one case 2 GHz in the other case.

Changed 4 years ago by claudio_

This is the dmesg output in the bad case, i.e. audio pitch is much lower than it should be.

comment:7 Changed 4 years ago by lshurr

O.K., I see the same thing that claudio_ reported. I'm currently running VB 3.0.12 r54655. My host is a Compaq Presario C700 running Vista SP1, but I can get the same failure on my desktops running Windows XP, as well. The guest is OpenSUSE 11.1 with the kernel recently updated to 2.6.27.37. The kernel update necessitates a reinstall of the Guest Additions and brings on a cycle of sound too slow until next emulated power cycle.

I've uploaded dmesg outputs, as well. In the file dmesg.ac97.clock.slow.txt, you see intel8x0_measure_ac97_clock() measure the clock and come up with a value it finds "acceptable" and the resulting clock rate is 41161 Hz. The sound is slow and distorted with that setting. In the file dmseg.ac97.clock.4800, you see intel8x0_measure_ac97_clock() measure the AC97 clock and come up with a value it finds unacceptable, causing it to set the clock to 48000 Hz. The result is undistorted sound from the emulated ac97.

It seems that the emulated ac97 sounds best when its default clock is something so unacceptable that the driver initializes it to 48000 Hz. The result is normal sound output. If the clock is already within the "acceptable" range (whatever that means), it is not changed and the sound quality you get is the luck of the draw.

Changed 4 years ago by lshurr

This file as after the first reboot following reinstall of the Guest Additions. Sound output is slow and distorted.

Changed 4 years ago by lshurr

This file is from a subsequent emulated power cycle. Sound is normal hereafter unless there is a crash or a new kernel is installed.

Changed 4 years ago by claudio_

dmesg with high pitch

comment:8 Changed 4 years ago by claudio_

Today for the first time I had a situation where the pitch was higher then it should be. Thus I attached a further dmesg output for this situation too.

By the way this is on a MacBook Pro 17" (Early 2009 model).

comment:9 Changed 4 years ago by lshurr

The high pitch outcome is interesting. When I look at your latest dmesg output, I see that it tried measuring the emulated ac97 chip's clock three times, rejecting outcomes of 62281 Hz & 64657 Hz before accepting 50732 Hz as a good setting. 'Course I'm talking almost like a really understand what's going on, whereas instead, so much is unknown, that I only have the vaguest of ideas. It seems to me, though, that the intel8x0 driver in Linux is making an assumption about the chip which does not hold in the VirtualBox emulation. Based on these few dmesg listings, I wonder what it means for the driver to accept whatever clock "setting" it "finds." It may be that the VBox emulation only gives good results if the clock is actually set to something. It looks like we always get good results when it decides to set the clock 48000 Hz instead of accepting whatever it thinks it found there.

comment:10 Changed 4 years ago by lshurr

The recent messages from claudio_ led to a little more looking around WRT the emulated ac97 chipset, a SigmaTel STAC9700. You can look at the status of the "chip" using

'cat /proc/asound/card0/codec97#0/ac97#0-0'.

You can view the registers using

'cat /proc/asound/card0/codec97#0/ac97#0-0+regs'

and you can alter register settings by writing the settings you want into the ac97#0-0+regs node as root... or so it appears, e.g.

'echo 2e ac44 >/proc/asound/card0/codec97#0/ac97#0-0+regs'

will write 0xac44 (44100 decimal) to register 0x2e.

If the sound is too slow or fast, the settings shown by ac97#0-0 will be obviously 'wrong' and it's easy to find the 'off' values in ac97#0-0+regs, too, by converting the off settings from decimal to hex and looking for those values in the registers. You can change the settings to what they should be, but... that still doesn't fix the sound.

Either I'm missing something, it just doesn't work or it just doesn't work the way it seems like it ought to. You can look for the STAC9700 docs online and find out what the registers mean, e.g., if you write any value to register 00, the chip resets and that does seem to work. All the registers are set to default values and sound stops working. You can then set all the registers to what they ought to be and sound will work again, but if was slow or fast and distorted when you started, it will be exactly the same as before -- still too slow or fast. This suggests that there are other settings somewhere that may or not be accessible using /proc that also need to be changed to get sound working correctly, but I've run out of ideas for now.

comment:11 Changed 4 years ago by lshurr

Workaround found -- see if it works for you. The workaround is in Linux's snd-intel8x0 driver, which has options for working around problems with various hardware and one of these allows you to disable auto-detect on the AC'97 codec clock and set it directly. Since I have never tried to use VB's Soundblaster 16 emulation, AFAIK nothing I say here applies to it.

I use openSUSE 11.1 now instead of Ubuntu, so I used YAST to change the setting. With other distros, YMMV. In YAST, select Hardware->Sound->Edit. In the Advanced Sound Options window, select the "AC'97 codec clock (0 = auto-detect)" option and click the Edit button. Enter the value 48000 and click the OK button, returning you to the "Sound Card Advanced Options" window, where you will click the Next button. This will return you to the Sound configuration window where you should click the OK button. At this point, you're finished, but YAST will first update the settings and reset the audio interface before returning you to the YAST Control Center window, which you can close.

O.K., this works for me. So far, there's no slow, distorted sound, even after powering down the emulated machine, which always induced the failure before now.

comment:12 Changed 4 years ago by claudio_

lshurr: I wonder where YAST stores the change. I think it might be one either the boot configuration (/boot/grub/menu.lst or /boot/grub/grub.conf) or the modprobe stuff i.e. some file in /etc/modprobe.d. Can you have a look which file was modified by YAST?

comment:13 Changed 4 years ago by lshurr

claudio_: It's in the modprobe parameter files, which would stand to reason I suppose. The file I'm uploading, 'sound', was found in /etc/modprobe.d in my openSUSE VM. I reactivated my long-dormant Ubuntu 9.04 VM and copied it into /etc/modprobe.d. It works like a charm. I powered-off the Ubuntu VM using the 'Machine' menu and then restarted it, a scenario guaranteed, in the past, to induce slow, distorted audio and sound came up just fine, not slow, not distorted. Looks like it's a confirmed workaround.

Changed 4 years ago by lshurr

Place in /etc/modprobe.d to activate the ac97 clock workaround discussed in this thread

comment:14 Changed 4 years ago by claudio_

lshurr: Thank you. I put just the line

options snd-intel8x0 ac97_clock=48000

into /etc/modprobe.d/sound and I notice that all the lines regarding to 8x0 trying to find the correct frequency disappear from dmesg output. So it really picks up the preset value instead of trying to guess it.

Thus I too think this is a way to solve this problem on Linux side.

comment:15 follow-up: ↓ 16 Changed 4 years ago by bewst

This workaround isn't helping me with an ubuntu 9.10 x64 guest on MacOS 10.6 x64 host :(. Maybe it's somehow a different problem

comment:16 in reply to: ↑ 15 Changed 4 years ago by lshurr

Replying to bewst:

This workaround isn't helping me with an ubuntu 9.10 x64 guest on MacOS 10.6 x64 host :(. Maybe it's somehow a different problem

I am disappointed to learn of its failure for you after the satisfactory outcomes that claudio_ and I have obtained. Do you find the same things in your guest's dmesg output that we found? Since I am not running on a Mac, there's obviously much I don't know, but I believe I understand that whereas your host and guest are both 64-bit, in his and my case, our hosts and guests are all 32-bit. Even if I have misunderstood something, it may still be instructive if you were to create and load a 32-bit guest and see if the workaround works in that case.

comment:17 follow-up: ↓ 20 Changed 4 years ago by bewst

I'm very pleased to say that with the latest VBox I am no longer having the problem. Audio is slightly glitchy, but not horrible like it was.

comment:18 Changed 4 years ago by frank

bewst, are you talking about a Mac OS X host? Which was the previous version which didn't work for you and which version works better?

comment:19 Changed 4 years ago by bewst

yes: 3.1.4/3.1.6

comment:20 in reply to: ↑ 17 Changed 4 years ago by lshurr

Replying to bewst:

I'm very pleased to say that with the latest VBox I am no longer having the problem. Audio is slightly glitchy, but not horrible like it was.

I'm glad to hear it. As long as power management is set to the max performance setting, I almost never have a glitch. I can even play videos in the guest with surprisingly good results as long as I use the VideoLan VLC player -- It is by far the most glitch-resistant video player. This is true even when running in a guest on my openSUSE laptop which has only a 1.6 GHz Celeron.

comment:21 follow-up: ↓ 22 Changed 4 years ago by bewst

Weird; I just had the same experience all over again with a Windows guest. The distortion sounds exactly the same.

comment:22 in reply to: ↑ 21 Changed 4 years ago by lshurr

Replying to bewst:

Weird; I just had the same experience all over again with a Windows guest. The distortion sounds exactly the same.

Interesting. I've never experienced distortion in a Windows guest, only with Linux guests and that was fully corrected by the workaround in my case.

comment:23 Changed 4 years ago by sandervl73

  • Status changed from new to closed
  • Resolution set to fixed

Retry with 3.2.10 please.

comment:24 Changed 3 years ago by claudio_

  • Status changed from closed to reopened
  • Resolution fixed deleted

It happens again with Lubuntu 11.10 guest in a VirtualBox 4.1.2 hosted on Mac OSX Lion (10.7.1):

[ 8.635720] intel8x0_measure_ac97_clock: measured 124579 usecs (7241 samples) [ 8.635994] intel8x0: clocking to 39640

comment:25 Changed 3 years ago by sunlover

  • Status changed from reopened to closed
  • Resolution set to fixed

The snd_intel8x0 audio driver tries to autodetect the ac97 device clock. The autodetection method does not work in a virtual machine. You have to specify the frequency in /etc/modprobe.d/alsa-base.conf:

options snd-intel8x0 ac97_clock=48000

comment:26 Changed 2 months ago by Ah Yes

  • Status changed from closed to reopened
  • Resolution fixed deleted

Sorry this is not fixed at all. The last post is a workaround, not a fix.

It's affecting FreeBSD guests too:

 https://forums.freebsd.org/viewtopic.php?f=19&t=44579&p=251349#p251349

The same VM image in VMware Player (free edition) does not exhibit any issues at all. Timing is perfect, no audio dramas. Please consider fixing the issue with virtualbox that is causing this (it has to be some sort of timing issue, if VMWare have a way of not having these problems, it HAS to be possible to fix this issue in virtualbox).

Note: See TracTickets for help on using tickets.

www.oracle.com
ContactPrivacy policyTerms of Use