Re: qemu 4.2.0 audiodev soundhw

[Idar Lund]

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> 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> 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) ...

Comments?

cheers,
  Gerd