diff options
author | Akihiko Odaki <akihiko.odaki@daynix.com> | 2025-03-17 17:05:29 +0900 |
---|---|---|
committer | Marc-André Lureau <marcandre.lureau@redhat.com> | 2025-05-25 15:25:21 +0200 |
commit | 2bccabe6df5e91145c1313bb79b98200aa13b5ff (patch) | |
tree | e8f62ba02ff438297960b4f197f0f7c78ce02039 /python/scripts | |
parent | f6ccfd5d166acf495f5d6d320da503fae8dc14a4 (diff) | |
download | qemu-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