Re: [PATCH 00/12] audio: deprecate -soundhw

[Philippe Mathieu-Daudé]

On 4/30/20 9:41 AM, Gerd Hoffmann wrote:
> On Wed, Apr 29, 2020 at 06:54:08PM +0200, Philippe Mathieu-Daudé wrote:
> > Hi Gerd,
> >
> > On 4/29/20 1:02 PM, Gerd Hoffmann wrote:
> > > Gerd Hoffmann (12):
> > >     stubs: add isa_create_simple
> > >     stubs: add pci_create_simple
> > >     audio: add deprecated_register_soundhw
> > >     audio: deprecate -soundhw ac97
> > >     audio: deprecate -soundhw es1370
> > >     audio: deprecate -soundhw adlib
> > >     audio: deprecate -soundhw cs4231a
> > >     audio: deprecate -soundhw gus
> > >     audio: deprecate -soundhw sb16
> > >     audio: deprecate -soundhw hda
> > >     audio: deprecate -soundhw pcspk
> > >     [RFC] audio: try use onboard audiodev for pcspk
> >
> > I don't understand what you are trying to fix with this series.
>
> Almost nothing.  I'm just deprecating -soundhw, and I don't feel like
> putting too much effort into code which I want remove anyway.
>
> The new deprecated_register_soundhw() is there to allow removing the
> init callback for most hardware and have common code handle the simple
> cases.  Alternatively I could leave things as-is and just copy&paste the
> deprecation warning into each init callback.
>
> The only functional change (beside the added deprecation warnings) is
> that the pcspk realize function initializes audio in case audiodev is
> set, so "-global isa-pcspk.audiodev=<something>" is enough to activate
> the speaker.  The need to also have "-soundhw pcspk" on the command line
> is gone.
>
> > I suppose there is a problem with the pcspk, as I had a problem when I tried
> > to make the soundhw more QOM-friendly.
>
> I see your patch adds a deprecation warning for -soundhw too.  I'm
> wondering why you want convert this to QOM now just to throw away the
> code in a few months?

Well I didn't know you planed to throw them away. I started looking at 
the hw/audio/ files for the Arduino GSoC project because we want the ADC 
to sample data from a stream of floats (then opposite with PWM). Using 
.wav file seemed to make things simpler, then I noticed the AUD API. 
Then I started to have a cleaner producer/consumer API (i.e. the 8042 
PIT is a dsp stream producer, the pcspkr is a dsp stream consumer). To 
to that it was simpler to implement the producer/consumer interface 
split with the QOM API. The you know the NeverEnding Story... The 
-soundhw cleanup was part of it, as it was simple/contained I extracted it.

> cheers,
>    Gerd