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

[Volker Rümelin]

Am 04.09.23 um 14:11 schrieb Alex Bennée:
> Manos Pitsidianakis <manos.pitsidianakis@linaro.org> writes:
>
> > 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.
> Volker,
>
> Can you run with:
>
>    -d trace:virtio_snd\*
>
> to confirm you are seeing the same behaviour. The experience I had with
> ogg123 in an emulated guest was it would work fine but then the next run
> I would get audio corruption. You can see this if you see lots of
> START/STOP/RELEASE messages constantly restarting things. If you are
> getting corruption without this pattern that is something else which we
> should investigate before merging.

Hi Alex,

I only see a START message when I start recording with audacity and a 
STOP message approximately 5s after I stop recording. This is when guest 
PulseAudio disables the virtio-sound device.

9881@1693892230.558732:virtio_snd_handle_ctrl snd 0x55ac9e6eb590: handle 
ctrl event for queue 0x55ac9e6f4160
9881@1693892230.558780:virtio_snd_handle_code ctrl code msg val = 257 == 
VIRTIO_SND_R_PCM_SET_PARAMS
9881@1693892230.558797:virtio_snd_handle_pcm_set_params 
VIRTIO_SND_PCM_SET_PARAMS called for stream 1
9881@1693892230.559132:virtio_snd_handle_ctrl snd 0x55ac9e6eb590: handle 
ctrl event for queue 0x55ac9e6f4160
9881@1693892230.559158:virtio_snd_handle_code ctrl code msg val = 258 == 
VIRTIO_SND_R_PCM_PREPARE
9881@1693892230.562202:virtio_snd_handle_rx_xfer rx queue callback called
9881@1693892230.562365:virtio_snd_handle_ctrl snd 0x55ac9e6eb590: handle 
ctrl event for queue 0x55ac9e6f4160
9881@1693892230.562395:virtio_snd_handle_code ctrl code msg val = 260 == 
VIRTIO_SND_R_PCM_START
9881@1693892230.562411:virtio_snd_handle_pcm_start_stop 
VIRTIO_SND_R_PCM_START called for stream 1
9881@1693892230.562557:virtio_snd_handle_rx_xfer rx queue callback called
9881@1693892230.810029:virtio_snd_handle_rx_xfer rx queue callback called
9881@1693892230.840194:virtio_snd_handle_rx_xfer rx queue callback called
9881@1693892230.860279:virtio_snd_handle_rx_xfer rx queue callback called

... a lot of 'virtio_snd_handle_rx_xfer rx queue callback called' 
messages every 20ms - 30ms

9881@1693892238.510774:virtio_snd_handle_rx_xfer rx queue callback called
9881@1693892238.530895:virtio_snd_handle_rx_xfer rx queue callback called
9881@1693892238.561123:virtio_snd_handle_rx_xfer rx queue callback called
9881@1693892238.566280:virtio_snd_handle_ctrl snd 0x55ac9e6eb590: handle 
ctrl event for queue 0x55ac9e6f4160
9881@1693892238.566290:virtio_snd_handle_code ctrl code msg val = 261 == 
VIRTIO_SND_R_PCM_STOP
9881@1693892238.566293:virtio_snd_handle_pcm_start_stop 
VIRTIO_SND_R_PCM_STOP called for stream 1
9881@1693892238.566415:virtio_snd_handle_ctrl snd 0x55ac9e6eb590: handle 
ctrl event for queue 0x55ac9e6f4160
9881@1693892238.566424:virtio_snd_handle_code ctrl code msg val = 259 == 
VIRTIO_SND_R_PCM_RELEASE
9881@1693892238.566428:virtio_snd_handle_pcm_release 
VIRTIO_SND_PCM_RELEASE called for stream 1

With best regards,
Volker

> > > 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