aboutsummaryrefslogtreecommitdiff
path: root/Makefile.target
diff options
context:
space:
mode:
authorVolker RĂ¼melin <vr_qemu@t-online.de>2020-01-04 10:11:21 +0100
committerGerd Hoffmann <kraxel@redhat.com>2020-01-06 08:47:16 +0100
commitacc3b63e1bdf806de1a520522dd43e494461d3bb (patch)
tree46b225a36811a8aaaa52a7d602b342168fd50341 /Makefile.target
parent4db3e634c77a671fadbba6d4d39e0d21232e5609 (diff)
downloadqemu-acc3b63e1bdf806de1a520522dd43e494461d3bb.zip
qemu-acc3b63e1bdf806de1a520522dd43e494461d3bb.tar.gz
qemu-acc3b63e1bdf806de1a520522dd43e494461d3bb.tar.bz2
paaudio: try to drain the recording stream
There is no guarantee a single call to pa_stream_peek every timer_period microseconds can read a recording stream faster than the data gets produced at the source. Let qpa_read try to drain the recording stream. To reproduce the problem: Start qemu with -audiodev pa,id=audio0,in.mixing-engine=off On the host connect the qemu recording stream to the monitor of a hardware output device. While the problem can also be seen with a hardware input device, it's obvious with the monitor of a hardware output device. In the guest start audio recording with audacity and notice the slow recording data rate. Signed-off-by: Volker RĂ¼melin <vr_qemu@t-online.de> Message-id: 20200104091122.13971-4-vr_qemu@t-online.de Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Diffstat (limited to 'Makefile.target')
0 files changed, 0 insertions, 0 deletions