Am 04.09.23 um 12:01 schrieb Manos Pitsidianakis:
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.
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.
For this test I only start QEMU with the mixing engine disabled. When I
start recording with audacity, audacity reports 'Recording' in the
status line but it actually doesn't record. The recording marker in the
tracks window stays a 0.
I don't think it's a hardware performance issue. Other QEMU audio
devices don't show this behaviour.
With best regards,
Volker
Thank you very much for your help,
Manos
