Audio input not working, Win Guest, Linux host => Fixed in SVN/3.1.4

[bvidinli]

Using on Ubuntu Linux 9.04 host, Windows xp guest,

audio input not working, I cannot record sound inside windows, or cannot use my microphone...

Using on Virtualbox 3.0 beta 2 I installed on Ubuntu using deb package of beta 2

[Viktor Ferenczi]

Host: Ubuntu 9.04 64 bit, 8Gbytes RAM, Intel Q6600 CPU (4 cores) @ 2.88GHz

VirtualBox 3.0.4 from its own repository.

Guest: Windows Server 2003, customized to have XP look and feel

Virtual sound card: ICH AC97

Guest Additions are installed.

• Both sound and microphone are working fine in the host OS.
• Both ALSA and Pulseaudio are working fine.

Selecting ALSA for the above guest OS gives me garbled sound and completely noisy, totally unusable microphone. Using Pulseaudio results in good sound output, but the microphone is still unusable, sounds "cropped" and almost as noisy as with ALSA. There's some difference, however.

I don't know what the problem can be in this case. Maybe the guest and the host do not agree on the size of sound samples or the number of channels (8 or 16 bit, mono or stereo) resulting in a data size or DMA buffer length mismatch. I'm not sure, however. It seems to be a data format negotiation issue IMHO.

I haven't tried the virtual Sound Blaster 16 yet...

[Viktor Ferenczi]

VM log of the Windows Server 2003 guest session affected by this issue

[Viktor Ferenczi]

One more note on this issue.

It is not an issue with the ALSA mixer or the microphone gain. I set those up correctly, then double checked my setting both using SkyPE and a sound recorder. Even 5.1 sound works perfectly, so the physical sound card works fine for sure.

Sound card on the host: 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 01)

[Crimson]

Facing the same problem.

Host: Fedora 11 with pulse audio

Guest: Windows XP configured with ICH AC97 sound controller.

I still havent found a solution for this having spent hours sarching or trying to come up with some hact to get this to work.

I hope this gets fixed in the next VB release whenever that is.

[Mattias Barletta]

Same here.

Ubuntu Karmic Koala. Xp SP3 Guest.

When recording with Pulseaudio in Soundrecorder (XP) time is going 1/4 clock time. So when 4 secs passed Sound Recorder shows only 1 sec.

Alsa backend produces something similiar. It records at normal speeds but playback is ~4 time faster.

Anyone from VB can say something? I saw several tickets with the same issue.

Thanks

[Crimson]

The timer on the recorder being slow seems to be a good catch. When I tried it on my Windows XP-SP3 guest on Fedora 11 host, my recorder timer was ~1.5 times slower than my Fedora system time seconds.

However, this applies only to the recorder timer because XP system time seconds were in sync with Fedora system time seconds.

[Crimson]

From my logs and the ones attached in the bug: ...

00:00:01.460 Audio: Trying driver 'pulse'.

00:00:01.470 Audio: set_record_source ars=0 als=0 (not implemented)

00:00:01.470 Pulse: open PCM_IN rate=44100Hz channels=2 format=s16le

00:00:01.490 Pulse: buffer settings: max=26460 tlength=17640 prebuf=15876 minreq=1764

00:00:01.491 Pulse: open PCM_OUT rate=44100Hz channels=2 format=s16le

00:00:01.513 Pulse: buffer settings: max=26460 tlength=17640 prebuf=15876 minreq=1764

On trying ALSA, I'm not even able to record anything(fast or slow).

The logs say this:

00:00:01.761 Audio: Trying driver 'alsa'.

00:00:01.770 Audio: set_record_source ars=0 als=0 (not implemented)

00:00:01.865 ALSA: ADC frequency 44100Hz, period size 1024, buffer size 4096

00:00:01.881 ALSA: DAC frequency 44100Hz, period size 256, buffer size 1024

[Crimson]

I was able to greatly improve the situation by setting tsched=0 in /etc/pulse/default.pa (to disable glitch free audio)

and default-fragment-size-msec = 75 in /etc/pulse/daemon.conf

The default fragment size for my system was 25 and the more I increased it (followed by restarting VB and my Pulseaudio daemon), the more -in-sync- the recorder timer and the host system timer got. However this happened only till fragment size of 75 after which the recording again began going out of sync. At 75 the recording was 1.25 times slower( if some one tries this out then he'll find out its still unusable although some words are more audible in playback now.)

If I remember correct then in pulseaudio parlance, fragment size is the number of samples after processing which the audio card generates an interrupt.

I'm more inclined to believe now that the emulated sound card in VB and PulseAudio are not agreeing on some parameter. I really hope this provides enough info for at least some VB dev guy to have a look into this.

[Crimson]

I recorded two .wav files - one on my linux host and the other in windows and analysed the parameter of their headers to see what the difference was.

Sampling Rate = 22050 Hz (same for host and guest)

Sample size = 32 bits(host), 16 bits(guest)

kbps(host) = 2 * kbps(guest) - as expected

Ok, so no issues here. Next I saw the file size of both the recordings (after saving the 32 bit signed PCM as 16 bit signed PCM)

The file sizes were in the ratio of (time elapsed on host)/(time elapsed on recorder timer) ; which means that the number of samples that the windows sound recorder received was not the same as the number of samples that were sent by the host.

So it seems that the VB sound_in driver is dropping samples. A rough calculation(the ratio of recorder and host time) showed that for every 3 or so samples received, 2 are dropped.

This explains the recorder time going slow because the recorder increments its time based on the number of samples it receives. If it receives less samples then the time incremented will be less. The explanation for the recorded audio playing fast is that whatever samples the sound recorder got (1 out of every 3) are spread uniformly over the duration of recorded audio and the time allocated to play them is less (as I pointed out before, the recorder incremented its time lesser than the host). So... effectively one ends up playing the entire recording in less time which means faster sounding audio.

[Viktor Ferenczi]

Could you please change VirtualBox 2.2.4 to 3.0.x in this ticket's properties?

It'd help to bring attention to this issue, I think.

[Mattias Barletta]

Nice finding crimsonflame123!

I found something interesting as well.

If I set alsa default device to pulse and set VirtualBox to Alsa, I can record normally but playback is choppy and I think I 'know' why. Pulseaudio Manager says that Virtualbox connection Index changes several times per seconds during playback. That dropping and reconnection to pulse may explain why alsa output is choppy.

my 2 cents

[Crimson]

It could even be a PulseAudio bug. PA is not as stable as it should be. The reason I am saying this is because we still dont know the reason why there is a variation in the percentage of samples dropped when we set tsched=0/1 and vary the fragment size.

[Mattias Barletta]

It could be!.

As letezo said this ticket should be bound to VB 3.0.X. How we do it? Anyone?

[Crimson]

I uninstalled pulseaudio and the recording/playback works like charm in VirtualBox. Still PulseAudio has its advantages so a proper VB support for PA is still desirable.

[theboxman]

I can confirm this bug with VB 3.0.x. Did somebody test it with 3.1.x? Can the devs please look into it?

[darylb]

I have this issue too, with Ubuntu 9.10 host, and Ubuntu 9.10 in guest. Audio seems to record in the guest at a quarter speed. I'm using VirtualBox 3.0.8_OSE r53138 as in the Ubuntu 9.10 repository.

[theboxman]

Just for the record.

This issue was fixed in latest SVN (development version) thanks to a patch by Arthur Taylor.

[bvidinli]

I hope the development version will be converted to ubuntu packages soon..

[Crimson]

theboxman, I too saw the changes by Arthur Taylor go in but didnt get a chance to test it. Have you tested the development version?

[theboxman]

yes, it works.

[pernikovka]

Hi, can someane say when will be new release which will contain this fix? Thanks for your answer

[Frank Mehnert]

This will take some weeks but not months. We can't say more, sorry.

[Sander van Leeuwen]

Please check if 3.1.4 beta 1 solves the problem: ​http://forums.virtualbox.org/viewtopic.php?f=15&t=27300

[Crimson]

Yes it works in beta.