Bug 81824

Summary:	audio from qemu guest suffers delay / pitch changes as of 5.x
Product:	PulseAudio	Reporter:	dimitris
Component:	clients	Assignee:	pulseaudio-bugs
Status:	RESOLVED MOVED	QA Contact:	pulseaudio-bugs
Severity:	major
Priority:	medium	CC:	dimitris, lennart
Version:	unspecified
Hardware:	x86-64 (AMD64)
OS:	Linux (All)
Whiteboard:
i915 platform:		i915 features:

Description dimitris 2014-07-28 01:38:55 UTC

I have a Fedora 20 guest running inside a Fedora 20 host, both using pulseaudio. Up until recently, I could use audio apps (mostly Skype) from inside the guest without issues.

As of Fedora's rebasing of pulseaudio to 5.x, there seems to be some sort of timing skew and delay. This isn't limited to Skype; a slightly simpler test case:

Running "paplay /usr/share/sounds/alsa/Front_Left.wav" repeatedly, I observe:

- In the host: no issues

- In the guest:

The clip's voice pitch sounds slightly lower. This is consistent with running the command under time(1), where the just over 1.5s clip consistently takes 50-60ms longer in reported real time to play in the guest.

Running the paplay command repeatedly in the guest, starting each new invocation after the sound has stopped playing, there seems to be a "back up" of audio stream building up. After 5 or so runs, the sound doesn't start playing until after the command has finished executing in the terminal. Waiting some time after that seems to exhaust whatever buffer is being emptied, but the effect is back if I try another sequence of paplay commands.

The guest's configuration hasn't changed; as I mentioned above, this correlated perfectly with the 4.x -> 5.x upgrade in Fedora. More specifically, this started happening when *only the host* was upgraded to 5.x, with the guest still running PA 4.x.

The guest virtual hardware has always been:

00:04.0 Audio device: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) High Definition Audio Controller (rev 01)
0 alsa_card.pci-0000_00_04.0 module-alsa-card.c

The host has two devices available, with the problem present no matter which one is used:

00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio Controller (rev 03)
Bus 001 Device 010: ID 0d8c:0139 C-Media Electronics, Inc.
0 alsa_card.usb-C-Media_Electronics_Inc._DYNEX_USB_Audio_Device-00-Device module-alsa-card.c
1 alsa_card.pci-0000_00_1b.0 module-alsa-card.c

Comment 1 Raymond 2014-07-28 02:26:02 UTC

which backend are you using ?

the emulated AC97 's 64 K buffer size of the guest is smaller than that of HDA of your host


http://git.kernel.org/cgit/virt/kvm/mst/qemu.git/tree/audio/alsaaudio.c

the alsa backend is using 4096

http://git.kernel.org/cgit/virt/kvm/mst/qemu.git/tree/audio/paaudio.c


pa_stream_connect_playback (stream, dev, attr,
                                        PA_STREAM_INTERPOLATE_TIMING
#ifdef PA_STREAM_ADJUST_LATENCY
                                        |PA_STREAM_ADJUST_LATENCY
#endif
                                        |PA_STREAM_AUTO_TIMING_UPDATE, NULL, NULL);
    } else {

Comment 2 dimitris 2014-07-28 04:22:32 UTC

ALSA (if I understood the question) in both host and guest.

Comment 3 Raymond 2014-07-28 16:00:03 UTC

unless you specify DAC_DEV and ADC_DEV  , virtualbox is using default device through alsa pulse plugin to the host pulsraudio server




   {
        .name        = "DAC_DEV",
        .tag         = AUD_OPT_STR,
        .valp        = &conf.pcm_name_out,
        .descr       = "DAC device name (for instance dmix)"
    },
    {
        .name        = "ADC_DEV",
        .tag         = AUD_OPT_STR,
        .valp        = &conf.pcm_name_in,
        .descr       = "ADC device name"
    },

Comment 4 Raymond 2014-07-31 07:15:15 UTC

http://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/?id=2780f4c24f67a439eab19c47059d6ab2ed8836c3

do you mean it is related to resampler refactoring ?

Comment 5 GitLab Migration User 2018-07-30 09:56:43 UTC

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/132.

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.