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

["Philippe Mathieu-Daudé" <philmd@redhat.com>]

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
>