[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: qemu 4.2.0 audiodev soundhw
From: |
Jakob Bohm |
Subject: |
Re: qemu 4.2.0 audiodev soundhw |
Date: |
Tue, 21 Apr 2020 00:06:44 +0200 |
User-agent: |
Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 |
As someone who doesn't always keep libvirt and qemu in sync (if using
libvirt
at all), keeping forward and backwards compatibility for command lines and
other interfaces becomes quite critical. For example doing a quick site
compile of a more recent qemu needs to work with whatever a distribution
libvirt or local script invokes, even if later upgrading libvirt without
recompiling qemu.
In that light, option 2 is not just preferable, but necessary.
It can however be simplified to silently assume a hard coded audiodev
value,
with the qemu-system man page explicitly stating that value, along with the
version dependency of both syntax generations.
In fact, over the years, I have found it excruciatingly difficult to find
valid qemu documentation, as each feature effort tends to leave behind
half-updated pages and a bunch of uncoordinated messages about what may or
may not have been implemented in unspecified versions.
On 20/04/2020 19:54, Idar Lund wrote:
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) ...
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com
Transformervej 29, 2860 Soborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
- qemu 4.2.0 audiodev soundhw, Idar Lund, 2020/04/17
- Re: qemu 4.2.0 audiodev soundhw, Zoltán Kővágó, 2020/04/20
- Re: qemu 4.2.0 audiodev soundhw, Gerd Hoffmann, 2020/04/22
- Re: qemu 4.2.0 audiodev soundhw, Peter Maydell, 2020/04/22
- Re: qemu 4.2.0 audiodev soundhw, Gerd Hoffmann, 2020/04/23
- Re: qemu 4.2.0 audiodev soundhw, Philippe Mathieu-Daudé, 2020/04/22