Hi,
Thanks for your response!
Yes, I agree with you on the options. If you guys decide on (3), I
would suggest to make it dynamically like this; "-soundhw
hda,audiodev=sound1". This would then copy the 'audiodev' (and
possible other) parameter(s) to the '-device' option.
My personal preference would be to recommend option number 1.
The reason for this is that maintaining a shortcut like this makes it
hard to maintain for developers when adding features and fixes bugs on
other options. And of course documentation maintainers :)
The second reason as I see it is that people tend to create a .sh
script or similar to start their qemu virtual machines if they don't
use libvirt/xml schema. And for that, a more verbose command would
actually be easier to maintain for users since we then know where to
put parameters like this.
-Idar
On Mon, Apr 20, 2020 at 4:44 PM Gerd Hoffmann <address@hidden
<mailto:address@hidden>> wrote:
On Fri, Apr 17, 2020 at 12:15:30PM +0100, Peter Maydell wrote:
> On Fri, 17 Apr 2020 at 12:08, Idar Lund <address@hidden
<mailto:address@hidden>> wrote:
> > I'm using qemu-system-x86_64 with the following options:
> > -audiodev pa,id=sound1,server=/run/user/1000/pulse/native \
> > -soundhw hda
> >
> > After upgrade to 4.2.0 (qemu-4.2.0-7.fc32) I get the following
warning:
> > (qemu) audio: Device hda: audiodev default parameter is
deprecated, please specify audiodev=sound1
> >
> > The documentation `man qemu-system-x86_64` seems to not
reflect this.
> > How am I supposed to use audiodev and soundhw?
>
> This looks like another question for you, Gerd...
Hmm, good question how to proceed here best ...
"-soundhw hda" is a shortcut for "-device intel-hda -device
hda-duplex"
You can use "-device intel-hda -device hda-duplex,audiodev=sound1" to
make the warning go away. That is pretty verbose when compared to
"-soundhw hda" though ...
So the options I see are:
(1) deprecate the -soundhw shortcut, expect users to use -device
instead.
(2) have -soundhw lookup the audiodev and add it automatically.
Works
only with a single audiodev, but that isn't different from what
we have today. If you want do more complicated things you
already have to use the more verbose -device command line.
(3) add audiodev option to -soundhw.
I don't like (3) much, our command line is already messy enough.
So my
personal preference would be (1) or (2) ...