Manos Pitsidianakis <manos.pitsidiana...@linaro.org> writes:
> Hello Volker :) > > On Mon, 04 Sep 2023 10:20, Volker Rümelin <vr_q...@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. > >> 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 -- Alex Bennée Virtualisation Tech Lead @ Linaro
