On Wed, Apr 22, 2020 at 04:13:29PM +0100, Peter Maydell wrote:
> On Wed, 22 Apr 2020 at 15:04, Gerd Hoffmann wrote:
> > 'pcspk' is the by far most tricky one. The device is present
> > unconditionally, -soundhw pcspk only triggers the registration
> > with the audiodev backend.
> >
> > 'hda'
On Wed, 22 Apr 2020, Philippe Mathieu-Daudé wrote:
Hi Jakob,
On 4/21/20 12:06 AM, Jakob Bohm wrote:
[...]
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
Hi Jakob,
On 4/21/20 12:06 AM, Jakob Bohm wrote:
[...]
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
On 4/22/20 4:04 PM, Gerd Hoffmann wrote:
Hi,
I think the original intention was to deprecate -soundhw altogether, and
only use -device in new configs. However that was problematic with some
special devices, like pcspk and maybe others that are created by the machine
and not user creatable.
On Wed, 22 Apr 2020 at 15:04, Gerd Hoffmann wrote:
> 'pcspk' is the by far most tricky one. The device is present
> unconditionally, -soundhw pcspk only triggers the registration
> with the audiodev backend.
>
> 'hda' creates two devices (intel-hda + hda-duplex), so it is an actual
> shortcut
Hi,
> I think the original intention was to deprecate -soundhw altogether, and
> only use -device in new configs. However that was problematic with some
> special devices, like pcspk and maybe others that are created by the machine
> and not user creatable.
Ah, right, the pcspk issue. Thanks
Hi,
On 2020-04-20 16:44, Gerd Hoffmann wrote:
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
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
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
On Fri, Apr 17, 2020 at 12:15:30PM +0100, Peter Maydell wrote:
> On Fri, 17 Apr 2020 at 12:08, Idar Lund 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
On Fri, 17 Apr 2020 at 12:08, Idar Lund 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
Hi,
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
12 matches
Mail list logo
