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

[Manos Pitsidianakis <manos.pitsidianakis@linaro.org>]

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