On 04/19/2018 03:10 PM, Gerd Hoffmann wrote:
If some event caused some larger playback hickup the fine-grained timer
adjust isn't able to recover. Use a buffer overruns and underruns as
indicator for that. Reset timer adjust logic in case we detected one.
It seems that this patch causes big lockup of my Win10 KVM guest
when it tries to output a sound.
The three previous patches improved considerably the audio
output though!
Signed-off-by: Gerd Hoffmann <kra...@redhat.com>
---
hw/audio/hda-codec.c | 22 ++++++++++++++++++++++
hw/audio/trace-events | 2 ++
2 files changed, 24 insertions(+)
diff --git a/hw/audio/hda-codec.c b/hw/audio/hda-codec.c
index f6fb1d0fa0..623021b7c7 100644
--- a/hw/audio/hda-codec.c
+++ b/hw/audio/hda-codec.c
@@ -261,6 +261,13 @@ static void hda_audio_input_cb(void *opaque, int avail)
int64_t to_transfer = audio_MIN(B_SIZE - (wpos - rpos), avail);
+ if (to_transfer == 0) {
+ /* reset timer adjust */
+ st->buft_start = qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL);
+ trace_hda_audio_underrun(st->node->name);
+ return;
+ }
+
hda_timer_sync_adjust(st, -((wpos - rpos) + to_transfer - (B_SIZE >> 1)));
while (to_transfer) {
@@ -325,6 +332,21 @@ static void hda_audio_output_cb(void *opaque, int avail)
int64_t to_transfer = audio_MIN(wpos - rpos, avail);
+ if (to_transfer == 0) {
+ /* reset timer adjust */
+ st->buft_start = qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL);
+ trace_hda_audio_underrun(st->node->name);
+ return;
+ }
The lock happen here:
hda_audio_output_cb is called a lot and keeps running in
underrun. While the 1kHz callback is called regularly and
always "already have the data". So I wonder if the adjust here is
not confusing the 1kHz callback which refuse to get new data.
Regards,
Fred
