qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 4/4] audio/hda: detect output buffer overruns an


From: KONRAD Frederic
Subject: Re: [Qemu-devel] [PATCH 4/4] audio/hda: detect output buffer overruns and underruns
Date: Mon, 23 Apr 2018 11:31:34 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0



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 <address@hidden>
---
  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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]