aboutsummaryrefslogtreecommitdiff
path: root/python/scripts
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 /python/scripts
parentf6ccfd5d166acf495f5d6d320da503fae8dc14a4 (diff)
downloadqemu-2bccabe6df5e91145c1313bb79b98200aa13b5ff.zip
qemu-2bccabe6df5e91145c1313bb79b98200aa13b5ff.tar.gz
qemu-2bccabe6df5e91145c1313bb79b98200aa13b5ff.tar.bz2
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 'python/scripts')
0 files changed, 0 insertions, 0 deletions