summary refs log tree commit diff stats
path: root/tests/functional/test_m68k_replay.py
diff options
context:
space:
mode:
authorAkihiko Odaki <akihiko.odaki@daynix.com>2025-03-17 17:05:29 +0900
committerMarc-André Lureau <marcandre.lureau@redhat.com>2025-05-25 15:25:21 +0200
commit2bccabe6df5e91145c1313bb79b98200aa13b5ff (patch)
treee8f62ba02ff438297960b4f197f0f7c78ce02039 /tests/functional/test_m68k_replay.py
parentf6ccfd5d166acf495f5d6d320da503fae8dc14a4 (diff)
downloadfocaccia-qemu-2bccabe6df5e91145c1313bb79b98200aa13b5ff.tar.gz
focaccia-qemu-2bccabe6df5e91145c1313bb79b98200aa13b5ff.zip
audio: Reset rate control when adding bytes
Commit 90320051ea99 ("spiceaudio: add a pcm_ops buffer_get_free
function") caused to emit messages saying "Resetting rate control"
frequently when the guest generates no frames.

audio_rate_peek_bytes() resets the rate control when frames < 0 ||
frames > 65536 where frames is the rate-limited number of frames.
Resetting when frames < 0 is sensible as the number simply doesn't make
sense.

There is a problem when frames > 65536. It implies the guest stopped
generating frames for a while so it makes sense to reset the rate
control when the guest resumed generating frames. However, the
commit mentioned earlier broke this assumption by letting spiceaudio
call audio_rate_peek_bytes() whether the guest is generating frames or
not.

Reset the rate control in audio_rate_add_bytes(), which is called only
when actually adding frames, according to the previous call to
audio_rate_peek_bytes() to avoid frequent rate control resets even when
the guest generates no frame.

Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
Message-Id: <20250317-rate-v1-1-da9df062747c@daynix.com>
Diffstat (limited to 'tests/functional/test_m68k_replay.py')
0 files changed, 0 insertions, 0 deletions