Re: qemu 4.2.0 audiodev soundhw

[Gerd Hoffmann]

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' creates two devices (intel-hda + hda-duplex), so it is an actual
> > shortcut compared to the longer -device version.
> >
> > Every other device basically is pci_create_simple(...) or
> > isa_create_simple(...), even the names are identical, so "-soundhw sb16"
> > translates to "-device sb16" etc.
> 
> What about embedded board sound devices (eg the pl041 on the
> arm vexpress/versatilepb/realview boards) ?

Probably the sound device is present unconditionally, at least they
don't register for -soundhw.

But, yes, they also need some way to figure the audiodev they should
use.  Hmm.  One option I see is allowing to mark an audiodev as backend
for onboard audio devices, either using an option ...

-audiodev pa,onboard=true

... or by naming convention:

-audiodev pa,id=onboard

Comments?

take care,
  Gerd

Re: qemu 4.2.0 audiodev soundhw

[BALATON Zoltan]

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 uncoordinated messages about what may or
may not have been implemented in unspecified versions.

I feel your pain and agree.

How can this get improved?

Keeping the command line backward compatible is not an easy task.

There is a quite important effort in progress to improve the documentation.

Users reporting bad/incomplete/outdated documentation would help and motivate 
developers to fix it. That would reduce the gap between developers 
implementing features and users.


Do you other have suggestions about what should be improved?


Not related to audio but something as simple as adding a disk is almost 
impossible for a newbie. See this thread for example:


https://lists.nongnu.org/archive/html/qemu-ppc/2020-04/msg00324.html

or this forum post:

https://www.emaculation.com/forum/viewtopic.php?f=34&t=10598

This should be easy to do but even I don't know what's the preferred 
option now and how to use it correctly. Fortunately the -hda and -cdrom 
options still work for some machines, although they produce a warning 
which I tend to ignore as long as it works or go for the long way which is 
impossible to type so I have to save it in a script:


-drive if=none,id=hd,file=harddisk.img,format=raw \
-device ide-hd,drive=hd,bus=ide.0

Probably there should be some sensible way to use QEMU from the command 
line and have some options that work and won't change all the time.


The current situation may be because the CLI and monitor interface that 
are primarily human interfaces are abused by management software as an API 
although probably those should use some real API instead to control QEMU 
and leave the human interface to humans which then can be less arcane and 
have more convenience options. However splitting human and software 
interfaces would probably result in them diverging and human interface 
being neglected and bitrotting so these should be somehow still based on 
some common ground and any change in machine interface should make sure 
human interface is not broken by it.


Regards,
BALATON Zoltan

Re: qemu 4.2.0 audiodev soundhw

[Philippe Mathieu-Daudé]

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 implemented in unspecified versions.

I feel your pain and agree.

How can this get improved?

Keeping the command line backward compatible is not an easy task.

There is a quite important effort in progress to improve the documentation.

Users reporting bad/incomplete/outdated documentation would help and 
motivate developers to fix it. That would reduce the gap between 
developers implementing features and users.


Do you other have suggestions about what should be improved?

Thanks,

Phil.



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 > wrote:


    On Fri, Apr 17, 2020 at 12:15:30PM +0100, Peter Maydell wrote:
    > On Fri, 17 Apr 2020 at 12:08, Idar Lund mailto:idarl...@gmail.com>> 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

Re: qemu 4.2.0 audiodev soundhw

[Philippe Mathieu-Daudé]

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.


Ah, right, the pcspk issue.  Thanks for refreshing my memory.

'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 compared to the longer -device version.

Every other device basically is pci_create_simple(...) or
isa_create_simple(...), even the names are identical, so "-soundhw sb16"
translates to "-device sb16" etc.

So deprecating -soundhw for everything but pcspk and hda is a
no-brainer, it isn't even a shortcut, '-device' is one character
shorter ;)

Question is what we do with hda + pcspk.  I'm wondering whenever pcspk
is actually used in practice ...


To play demos?

The first tried I tried it, it triggered a crash:
https://bugs.launchpad.net/qemu/+bug/1861677

I'm not sure my test is common, it is simply the first time I thought 
about using the pcspk.

Re: qemu 4.2.0 audiodev soundhw

[Peter Maydell]

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 compared to the longer -device version.
>
> Every other device basically is pci_create_simple(...) or
> isa_create_simple(...), even the names are identical, so "-soundhw sb16"
> translates to "-device sb16" etc.

What about embedded board sound devices (eg the pl041 on the
arm vexpress/versatilepb/realview boards) ?

thanks
-- PMM

Re: qemu 4.2.0 audiodev soundhw

[Gerd Hoffmann]

  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 for refreshing my memory.

'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 compared to the longer -device version.

Every other device basically is pci_create_simple(...) or
isa_create_simple(...), even the names are identical, so "-soundhw sb16"
translates to "-device sb16" etc.

So deprecating -soundhw for everything but pcspk and hda is a
no-brainer, it isn't even a shortcut, '-device' is one character
shorter ;)

Question is what we do with hda + pcspk.  I'm wondering whenever pcspk
is actually used in practice ...

cheers,
  Gerd

Re: qemu 4.2.0 audiodev soundhw

[Zoltán Kővágó]

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 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?


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.  See my commit [1]


I wouldn't recommend (2), we already deprecated creating sound cards 
without audiodev option, and that code should go away when we get rid of 
the environment variables based config.


I'm not completely against (3), it might be a bit messy, but probably 
still better than requiring the user to create an hda bus and attach a 
codec to it.  It would also solve the ugly -global needed to get pcspk work.


[1]: 
https://git.qemu.org/?p=qemu.git;a=commit;h=af2041ed2d659923b997333c0a4472afaf9cb19f


Thanks,
Zoltan

Re: qemu 4.2.0 audiodev soundhw

[Jakob Bohm]

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 > wrote:


On Fri, Apr 17, 2020 at 12:15:30PM +0100, Peter Maydell wrote:
> On Fri, 17 Apr 2020 at 12:08, Idar Lund mailto:idarl...@gmail.com>> 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

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  wrote:

> 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 (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
>
>

Re: qemu 4.2.0 audiodev soundhw

[Gerd Hoffmann]

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 (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

Re: qemu 4.2.0 audiodev soundhw

[Peter Maydell]

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

thanks
-- PMM