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
>