Windows 11 Host, Debian 10 guest, choppy audio

[ribo]

Host machine is a AMD Ryzen 7 16 cores, running Windows 11. Only application running is Virtual Box.

One guest machine running Debian 10. 8192 Meg Ram, 8 CPU.

On guest machine, Firefox visiting YouTube (for example), 1 second audio, 1 second no audio, repeats. Log shows many lines of the form:
"Giving up catchup attempt"

What should be done to get smooth audio?

attached log file truncated as max attachment size is 2 MB .. on second try to attach the log, the forum says, "The file is too big, maximum allowed size is 128 KiB", so either it is attached and not saying so, or there is a bug in the forum code and it did not attach but changed the byte count. Just in case, here are some lines from the log:

00:00:03.680009 VirtualBox VM 7.0.4 r154605 win.amd64 (Nov 16 2022 15:33:13) release log
00:00:03.680011 Log opened 2022-11-20T15:10:33.299777100Z
00:00:03.680012 Build Type: release
00:00:03.680016 OS Product: Windows 11
00:00:03.680017 OS Release: 10.0.22621
00:00:03.680017 OS Service Pack:
00:00:03.761493 DMI Product Name: Vivobook_ASUSLaptop M7600QC_M7600QC
00:00:03.764978 DMI Product Version: 1.0
00:00:03.764992 Firmware type: UEFI
00:00:03.765426 Secure Boot: VERR_PRIVILEGE_NOT_HELD
00:00:03.765449 Host RAM: 15775MB (15.4GB) total, 11461MB (11.1GB) available
00:00:03.765451 Executable: C:\Program Files\Oracle\VirtualBox\VirtualBoxVM.exe
00:00:03.765452 Process ID: 7264
00:00:03.765453 Package type: WINDOWS_64BITS_GENERIC
00:00:03.766282 Installed Extension Packs:
00:00:03.766298 Oracle VM VirtualBox Extension Pack (Version: 7.0.4 r154605; VRDE Module: VBoxVRDP; Crypto Module: VBoxPuelCrypto)
00:00:03.766723 Console: Machine state changed to 'Starting'
...

01:29:20.172142 Audio: Device configuration of driver 'WasAPI' has changed
01:29:20.176788 Audio: The output device for WasAPI is changing.
01:29:20.176850 Audio: Device configuration of driver 'WasAPI' has changed
01:29:20.511609 Audio: Found 4 devices for driver 'WasAPI'
01:29:20.511629 Audio: Device 'Speakers (Realtek(R) Audio)':
01:29:20.511630 Audio: ID = {0.0.0.00000000}.{2f8e4945-3e17-4492-b053-c9032c8db20f}
01:29:20.511630 Audio: Usage = output
01:29:20.511630 Audio: Flags = DEFAULT_OUT
01:29:20.511630 Audio: Input channels = 0
01:29:20.511631 Audio: Output channels = 2
01:29:20.511636 Audio: Device 'Speakers (Realtek(R) Audio)':
01:29:20.511637 Audio: ID = {0.0.0.00000000}.{2f8e4945-3e17-4492-b053-c9032c8db20f}
01:29:20.511637 Audio: Usage = output
01:29:20.511637 Audio: Flags = NONE
01:29:20.511637 Audio: Input channels = 0
01:29:20.511637 Audio: Output channels = 2
01:29:20.511641 Audio: Device 'Microphone Array (Realtek(R) Audio)':
01:29:20.511641 Audio: ID = {0.0.1.00000000}.{10011c55-8d9b-4c36-8c74-78ff99ef5175}
01:29:20.511641 Audio: Usage = input
01:29:20.511642 Audio: Flags = DEFAULT_IN
01:29:20.511642 Audio: Input channels = 2
01:29:20.511642 Audio: Output channels = 0
01:29:20.511646 Audio: Device 'Microphone Array (Realtek(R) Audio)':
01:29:20.511646 Audio: ID = {0.0.1.00000000}.{10011c55-8d9b-4c36-8c74-78ff99ef5175}
01:29:20.511646 Audio: Usage = input
01:29:20.511646 Audio: Flags = NONE
01:29:20.511646 Audio: Input channels = 2
01:29:20.511646 Audio: Output channels = 0
01:32:17.375867 TM: Giving up catch-up attempt at a 60 000 727 782 ns lag; new total: 960 008 527 806 ns
01:36:36.910483 TM: Giving up catch-up attempt at a 60 000 111 492 ns lag; new total: 1 020 008 639 298 ns
01:40:24.913907 TM: Giving up catch-up attempt at a 60 000 022 627 ns lag; new total: 1 080 008 661 925 ns
01:44:19.966377 TM: Giving up catch-up attempt at a 60 000 235 386 ns lag; new total: 1 140 008 897 311 ns

[mpack]

Zipped logs fit.

[ribo]

wow that is amazing what zip does to a log file

[mpack]

00:00:03.876297 NumCPUs <integer> = 0x0000000000000008 (8)
...
00:00:04.620320 CPUM: Physical host cores: 8

Lack of stability is hardly a surprise with that config. Reduce the VM CPU allocation to 2 cores.

Consider switching the guest to stereo audio, as that has much lower overhead.

[ribo]

> Lack of stability is hardly a surprise with that config. Reduce the VM CPU allocation to 2 cores.

Are you saying that VirtualBox becomes unstable if several cores are used? That surprises the heck out of me. Please elaborate as this is good information.

> Consider switching the guest to stereo audio, as that has much lower overhead.

There is no option on the GUI for mono or stereo. There are the options: default, windows session, windows direct, null. There are also three controller choices. ICH AC97, SoundBlaster 16, and Intel HD Audio. Being a newbie I was afraid to play with those, ... but it turns out that
windows session combined with ICH AC97
works well. .. even with the 8 cores.

Thanks for pointing me at the audio settings! (I feel like 'ah duh' now ...)

[fth0]

Are you saying that VirtualBox becomes unstable if several cores are used?

I wouldn't say it that way. But audio playback likes isochronous/real-time behavior, and VirtualBox cannot guarantee any response time to a VM at all. The guest OS needs CPU resources to provide the audio data and to send it to the virtual audio device, and VirtualBox needs CPU resources on the host to emulate all virtual devices, including the virtual audio device. In consequence, VirtualBox itself needs considerable CPU resources on the host and in the guest, so each should have a fair share.

[mpack]

Are you saying that VirtualBox becomes unstable if several cores are used?

No, I'm saying that assigning 100% of CPU resources to one function is always a bad idea, especially when that one function is not related to VM performance (cores assigned to guest code are therefore not assigned to VirtualBox and the host OS where VirtualBox runs).

You will seldom go wrong sticking to 2 cores per VM, always.