On Thu, 14 Nov 2024 at 12:57, Marc-André Lureau <marcandre.lur...@gmail.com> wrote: > > Hi Paolo > > Did you see that patch? What do you say about it?
I think Paolo's patch seems like a cleaner fix for the leak than this one. Incidentally, to recap something I said on IRC: it seems to me like part of the problem here is that our AUD_* API doesn't match up well with what the Spice audio backend in QEMU needs. Specifically, the Spice channel (if I read the code correctly) always uses a fixed sample format and frequency. So even if the guest reconfigures the audio device with a different frequency there's no need to tear down the Spice audio channel. Awkwardly, our AUD_ layer APIs provide no way for the hda device model to say "this is just a change of the config parameters" -- all it can do is AUD_close-then-AUD_open. And at the Spice backend layer there's no way to tell "this is an AUD_close because we're really finished with audio" from "this is an AUD_close that's about to be followed by an AUD_open because it's just a config change". Even if the spice client end ought to cope better with the server end closing the audio connection, it's definitely not ideal to have a close-and-reconnect happening multiple times in less than a second (which is what you see in one of the logs provided in the bug report). thanks -- PMM
