On 2020-06-17 22:44, Gerd Hoffmann wrote:
On Sat, Jun 13, 2020 at 02:05:17PM +1000, Geoffrey McRae wrote:
When the guest closes the audio device we must start dropping input
samples from JACK and zeroing the output buffer samples. Failure to do
so causes sound artifacts during operations such as guest OS reboot,
and
causes a hang of the input pipeline breaking it until QEMU is
restated.
Closing and reconnecting to JACK was tested during these
enable/disable
calls which works well for Linux guests, however Windows re-opens the
audio hardware repeatedly even when doing simple tasks like playing a
system sounds. As such it was decided it is better to feed silence to
JACK while the device is disabled.
Hmm, I guess feeding silence into jack needs some cpu cycles?
Maybe add a timer to close the jack server connection? Keep the
connection open for re-use for a while, but in case the guest stops
playing sound altogether close the jack connection after being unused
for a few minutes?
[ Doesn't render the patch invalid, consider it a suggestion for future
improvements ]
Thanks, I had considered that however there is a usability issue to
consider. Each time a jack client registers, it removes the client
entirely and disconnects any custom plumbing that may have been done by
the user. JACK does not remember this custom routing and as such it's
lost until the user re-establishes it, or they have some automation set
up to do it. While this could likely be worked around, it would likely
cause more headaches then the few CPU cycles lost in a memset.
Further to this, while I have added some automation to connect ports via
regex matching, this is likely not going to be used by many as it's not
the normal method of connecting things up. This was added to open up
this for general use for those that don't care for custom filters but
just want the reliable audio interface.
take care,
Gerd