Bug 81824 - audio from qemu guest suffers delay / pitch changes as of 5.x
Summary: audio from qemu guest suffers delay / pitch changes as of 5.x
Status: RESOLVED MOVED
Alias: None
Product: PulseAudio
Classification: Unclassified
Component: clients (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium major
Assignee: pulseaudio-bugs
QA Contact: pulseaudio-bugs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-07-28 01:38 UTC by dimitris
Modified: 2018-07-30 09:56 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments

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.