qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Philippe Mathieu-Daudé" <philmd@redhat.com>
To: Jakob Bohm <jb-gnumlists@wisemo.com>, qemu-discuss@nongnu.org
Cc: Markus Armbruster <armbru@redhat.com>,
	qemu-devel <qemu-devel@nongnu.org>
Subject: Re: qemu 4.2.0 audiodev soundhw
Date: Wed, 22 Apr 2020 18:23:57 +0200	[thread overview]
Message-ID: <7a90dead-ff67-589c-81a9-826c4d0bd86e@redhat.com> (raw)
In-Reply-To: <d6c04095-8ea7-30c2-29f1-61c26aed835a@wisemo.com>

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



       reply	other threads:[~2020-04-22 16:25 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CA+enFJ=UmKNam-7T5J6UM6JGY7wy492MNm-d_-qKf7rLa818TQ@mail.gmail.com>
     [not found] ` <CAFEAcA_GqNAS-5+081vhpvn=Zk4qbD-SJz5SmN8s5_1_zerpAA@mail.gmail.com>
     [not found]   ` <20200420144433.upkagl3qi3nc2lsj@sirius.home.kraxel.org>
     [not found]     ` <CA+enFJkFN7B=-6k44Sb8XC2yAy2EGWoLCDMW0tA=GwwaxaspyA@mail.gmail.com>
     [not found]       ` <d6c04095-8ea7-30c2-29f1-61c26aed835a@wisemo.com>
2020-04-22 16:23         ` Philippe Mathieu-Daudé [this message]
2020-04-22 19:48           ` qemu 4.2.0 audiodev soundhw BALATON Zoltan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7a90dead-ff67-589c-81a9-826c4d0bd86e@redhat.com \
    --to=philmd@redhat.com \
    --cc=armbru@redhat.com \
    --cc=jb-gnumlists@wisemo.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-discuss@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).