Re: [PATCH v8 00/12] Add VIRTIO sound card

[Manos Pitsidianakis]

Hello Volker :)

On Mon, 04 Sep 2023 10:20, Volker Rümelin <vr_qemu@t-online.de> wrote:
> All qemu_log_mask() format strings need a trailing \n.

Thank you, will fix it!

> I still hear a lot of playback dropouts. I had planned to look at the 
> playback code, but I didn't have the time until now.
>
> Compared to v6 audio recording has improved but there are bugs. When I 
> start QEMU with -audiodev 
> pipewire,out.frequency=48000,in.frequency=48000,id=audio0 there are two 
> either uninitialized or stale samples every 25ms in the recorded audio 
> stream.
>
> To reproduce the issue start audacity on the host and generate a 2s 
> square wave tone with 315Hz and an amplitude of 0.8. Use pavucontrol to 
> select the monitor of your host playback device as QEMU recording 
> device. In the guest start recording with audacity. Start playback of 
> the generated square wave on the host. Stop recording in the guest and 
> have a look at a 200ms sequence of the recorded square wave and notice 
> the wrong samples every 25ms.

We've noticed this and decided to fix it in the future. I think the 
problem lies when PCM release is called from the guest. Quoting the 
spec:

 The device MUST complete all pending I/O messages for the specified 
 stream ID.
 The device MUST NOT complete the control request while there are 
 pending I/O messages for the specified stream ID.

When RELEASE is received, buffers are simply dropped. This is pure 
conjecture but I think creating an in-device buffer could solve this.
Unless the bug is found to be caused by something else, I settled on 
accepting it for this patch series because it is spec conformant.

> When I start QEMU with -audiodev 
> pipewire,out.mixing-engine=off,in.mixing-engine=off,id=audio0 audio 
> recording starts but the recorded stream immediately stalls.

Can you elaborate? Do you mean you repeat the same process as before, 
but the stall happens immediately? I personally rarely get any drops I 
could notice, only one or two for many minutes of playback / capture. I 
also could not reproduce exactly the same behavior you had in the 
previous version. The bugs *were* there but it was not as severe. Maybe 
it's a hardware performance issue? Can someone else test this too? It'd 
be helpful.

Thank you very much for your help,
Manos