Audio Speed is fast in FreeBSD 10

Hello

I am a beginner user of FreeBSD, I have installed FreeBSD 10 STABLE version in VirtualBox. The only issue I am having with my installation is with the audio. I am running i3 tiling manager. Whenever I listen to an video/audio, either in any player or youtube etc. the speed of the audio is very fast, it sounds like as if a child is talking fast. I searched in google and I found some issues dating back to 2003 with the ac97rate. I have adjusted the rate of dev.pcm.0.ac97rate=55000 from 38735. The issue goes away but when the OS is shutdown and started again, the same speedy audio issues come up again and I have to do the complete procedure again.

I have even added the dev.pcm.0.ac97rate=55000 to /boot/loader.conf and /etc/rc.conf. I also have to change the rate to different values again and again to get the right setup. How can I solve this issue?

Here are my settings:

Code:
# cat /dev/sndstat
Installed devices:
pcm0: <Intel ICH (82801AA)> (play/rec) default


Code:
# dmesg | grep pcm
pcm0: <Intel ICH (82801AA)> port 0xd100-0xd1ff,0xd200-0xd23f irq 21 at device 5.0 on pci0
pcm0: <SigmaTel STAC9700/83/84 AC97 Codec>
pcm0: measured ac97 link rate at 39707 Hz


Code:
# cat /boot/loader.conf
sound_load="YES"
snd_driver_load="YES"
snd_ich_load="YES"
dev.pcm.0.ac97rate=55000


Code:
# sysctl dev.pcm
dev.pcm.0.%desc: Intel ICH (82801AA)
dev.pcm.0.%driver: pcm
dev.pcm.0.%location: slot=5 function=0
dev.pcm.0.%pnpinfo: vendor=0x8086 device=0x2415 subvendor=0x8086 subdevice=0x0000 class=0x040100
dev.pcm.0.%parent: pci0
dev.pcm.0.eapd: 1
dev.pcm.0.play.vchans: 2
dev.pcm.0.play.vchanmode: fixed
dev.pcm.0.play.vchanrate: 47998
dev.pcm.0.play.vchanformat: s16le:2.0
dev.pcm.0.rec.vchans: 1
dev.pcm.0.rec.vchanmode: fixed
dev.pcm.0.rec.vchanrate: 47998
dev.pcm.0.rec.vchanformat: s16le:2.0
dev.pcm.0.buffersize: 16384
dev.pcm.0.bitperfect: 0
dev.pcm.0.ac97rate: 55000
 
IbnSaeed said:
I have adjusted the rate of dev.pcm.0.ac97rate=55000 from 38735. The issue goes away but when the OS is shutdown and started again, the same speedy audio issues come up again and I have to do the complete procedure again.
You can set most of the sysctl(8) settings in /etc/sysctl.conf to have them loaded at boot.
 
I forgot to post the /etc/sysctl contents

Here they are

Code:
# cat /etc/sysctl.conf
# $FreeBSD: release/10.0.0/etc/sysctl.conf 112200 2003-03-13 18:43:50Z mux $
#
#  This file is read when going to multi-user and its contents piped thru
#  ``sysctl'' to adjust kernel values.  ``man 5 sysctl.conf'' for details.
#

# Uncomment this to prevent users from seeing information about processes that
# are being run under another UID.
#security.bsd.see_other_uids=0

# Shared memory support for Chromium
 kern.ipc.shm_allow_removed=1

dev.pcm.0.ac97rate=55000

I had already done that, but the audio distorts (speeds up) when I shutdown and start the system. I have to restart the complete process of changing the values up and down.
 
It might be due to it running inside a virtual machine. Try setting kern.hz=100 in /boot/loader.conf. That usually solves timing issues with a VM.
 
SirDice said:
It might be due to it running inside a virtual machine. Try setting kern.hz=100 in /boot/loader.conf. That usually solves timing issues with a VM.

Thanks, ill try your solution.
 
kern.hz=100 did not work.

Just shutdown and started again, same issue.

Now i have to change the rate again and reboot.
 
I just rebooted my system without making any changes, and after the reboot, the audio speed has slowed from normal. its not normal speed but now its slow. Before it was fast.

The ac97rate is still the same 55000

I did not make any changes.
 
Code:
# dmesg | grep pcm
pcm0: <Intel ICH (82801AA)> port 0xd100-0xd1ff,0xd200-0xd23f irq 21 at device 5.0 on pci0
pcm0: <SigmaTel STAC9700/83/84 AC97 Codec>
pcm0: measured ac97 link rate at 52657 Hz


I ran the above command. The rate seems to be different from before.
 
I think it's a timing issue due to running inside a virtual machine. It's also possible the VirtualBox virtual audio device may be causing it, is everything up to date on the host itself?
 
SirDice said:
I think it's a timing issue due to running inside a virtual machine. It's also possible the VirtualBox virtual audio device may be causing it, is everything up to date on the host itself?

Yes, everything is upto date

I think, ill try changing the audio driver in VirtualBox and see what happens.
 
That makes two of us. I think it would be best asked on the freebsd-virtualization@ mailing list. Perhaps a developer may have an idea why it's happening.
 
That does look like it's the same issue. Perhaps you should add your findings too. If only to show the problem isn't related to Ubuntu and other guest operating systems have similar issues.
 
This is absolutely a Virtualbox issue.

Same issue, chipmonk audio. Tried the kernel "hz" thing, but it was already at 100 Hz when I inspected it with sysctl.

Tried different sound devices in the VM settings didn't work. Guess what though, same VM (using VMDK image so I can move between virtualization software) in VMware Player, audio is perfect, even with kern.hz at 1000.

Have a look into VMware player, it's free and you can install the open-vm-tools package from ports or pkg if you want the guest tools.

Edit: Reopened the Virtualbox ticket.
 
ahhyes said:
This is absolutely a Virtualbox issue.

Same issue, chipmonk audio. Tried the kernel "hz" thing, but it was already at 100 Hz when I inspected it with sysctl.

Tried different sound devices in the VM settings didn't work. Guess what though, same VM (using VMDK image so I can move between virtualization software) in VMware Player, audio is perfect, even with kern.hz at 1000.

Have a look into VMware player, it's free and you can install the open-vm-tools package from ports or pkg if you want the guest tools.

Edit: Reopened the Virtualbox ticket.

Thanks for the help and for reopening the ticket.
 
That's a problem with VirtualBox, it was like that a whole year ago too, with the AC97 audio. Can't remember if setting the frequency in /etc/sysctl.conf fixed it or not though.
 
Back
Top