[PATCH 0/2] hda-codec: reuse the audio device on format change

Paolo Bonzini posted 2 patches 1 week, 2 days ago
hw/audio/hda-codec.c | 41 +++++++++++++++++------------------------
1 file changed, 17 insertions(+), 24 deletions(-)
[PATCH 0/2] hda-codec: reuse the audio device on format change
Posted by Paolo Bonzini 1 week, 2 days ago
Commit 6d03242a7e47815ed56687ecd13f683d8da3f2fe fixes a memory leak
by calling hda_close_stream() when performing audio setup.  However,
hda_close_stream() closes the audio device, which is a change in
behavior because AUD_open_*() tries to keep the current device
if it's already up and configured properly.

Paolo

Paolo Bonzini (2):
  Revert "hw/audio/hda: fix memory leak on audio setup"
  hw/audio/hda: fix memory leak on audio setup

 hw/audio/hda-codec.c | 41 +++++++++++++++++------------------------
 1 file changed, 17 insertions(+), 24 deletions(-)

-- 
2.47.0
Re: [PATCH 0/2] hda-codec: reuse the audio device on format change
Posted by Philippe Mathieu-Daudé 5 days, 1 hour ago
On 14/11/24 12:53, Paolo Bonzini wrote:

> Paolo Bonzini (2):
>    Revert "hw/audio/hda: fix memory leak on audio setup"
>    hw/audio/hda: fix memory leak on audio setup

Series queued to hw-misc, thanks.
Re: [PATCH 0/2] hda-codec: reuse the audio device on format change
Posted by Michael Tokarev 1 week, 2 days ago
14.11.2024 15:53, Paolo Bonzini wrote:
> Commit 6d03242a7e47815ed56687ecd13f683d8da3f2fe fixes a memory leak
> by calling hda_close_stream() when performing audio setup.  However,
> hda_close_stream() closes the audio device, which is a change in
> behavior because AUD_open_*() tries to keep the current device
> if it's already up and configured properly.
> 
> Paolo
> 
> Paolo Bonzini (2):
>    Revert "hw/audio/hda: fix memory leak on audio setup"
>    hw/audio/hda: fix memory leak on audio setup
> 
>   hw/audio/hda-codec.c | 41 +++++++++++++++++------------------------
>   1 file changed, 17 insertions(+), 24 deletions(-)
Series:
Reviewed-by: Michael Tokarev <mjt@tls.msk.ru>

I think this is a better approach for now indeed.

The original intention was good, but it looks like we ended
up not understanding how audio is *supposed* to be used in
this context, when parameters has to be changed after connection
has been established - we need to agree with at least the major
users about how it is supposed to work in the first place.

Let's restore the status-quo which's been here for over 10
years and make a minimal fix first, and next let's think how
it should and can be done, having in mind existing users and
maybe negotiating the changes with them.

It's an interesting issue really, which also shows how various
parts of the whole picture interacts with each other.

Marc-André, I found it exciting and enlightening to watch this
whole thing happening.  And !2639 apparently has been one of
the hottest qemu issues so far, - I think it's been for good.

Thanks!

/mjt