All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gerd Hoffmann <kraxel@redhat.com>
To: Marco Martinelli - 13Byte srl <marco@13byte.com>
Cc: "Stefan Hajnoczi" <stefanha@redhat.com>,
	virtio-dev@lists.oasis-open.org,
	"Kővágó Zoltán" <dirty.ice.hu@gmail.com>
Subject: Re: [virtio-dev] Request for a new device number for a virtio-audio device.
Date: Mon, 6 May 2019 07:27:15 +0200	[thread overview]
Message-ID: <20190506052715.vkdopunuauyhl22m@sirius.home.kraxel.org> (raw)
In-Reply-To: <863e1be1-11cc-816b-896d-3954427e98f3@13byte.com>

  Hi,

> It's possible to enquiry the virtio-audio device about the host capabilities
> at this time but I'm not sure how to implement this in every audio backend
> of qemu (alsa, pulse, oss, coreaudio, dsound, ...)

It is probably a good idea to coordinate this with Kővágó Zoltán (Cc'ed)
who has a stack of patches to rework the qemu audio configuration.  The
first batch (adding -audiodev command line switch) has been merged in
4.1, the remaining bits will hopefully follow in 4.2.  The not-yet
merged patches include:

  (1) linking guest sound cards to host backends.
  (2) 5.1 support (IIRC: usb-audio and pa + alsa backends).

In general looking: following current qemu capabilities too closely when
designing a virtio spec is a bad idea, we don't want have qemu
implementation details baked in there ...

> Another thing to consider is that the host may have multiple sound cards.
> For example I have three sound cards at the moment, an integrated one with
> stereo at max 96kHZ, a dedicated one with 7.1 surround up to 192kHz and my
> video card has HDMI audio out (not sure of the specs).
> 
> What can be considered a valid configuration in this scenario?

If you want allow your guest use all three sound cards, then you
probably want create three sound cards in the guest too, each with
different capabilities and linked to one of the host devices.

> Another possibility is that the user can configure the virtio-audio device
> with the capabilities that he want to expose to the guest, regardless if the
> host really support them or not. What do you think?

Not a good idea.  We don't want qemu do audio processing.  It already
does to (it can resample audio data in case there is a sample rate
mismatch between guest and host), but we certainly don't want extend
that.

> Another idea is that the user may want to record the stream to process it
> later. It doesn't matter if the host audio card is not capable of
> reproducing it. The host may not even have a sound card in this case.

There already is a backend writing the guest audio stream to a wav file.

> I guess the simple answer is that users can attach as many virtio-audio
> devices as they want with different configurations but I'll look around to
> see if there is any benefit in having multiple input or output in the same
> device.

One advantage I see with multiple inputs/outputs on a single device is
that synchronization will probably easier that way.

On the other hand supporting multiple outputs doesn't seem to be a
feature people want use, I can't remember any requests for that.

cheers,
  Gerd


---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org


  reply	other threads:[~2019-05-06  5:27 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-28 22:22 [virtio-dev] Request for a new device number for a virtio-audio device Marco Martinelli - 13Byte srl
2019-04-29 13:47 ` Stefan Hajnoczi
2019-04-29 17:39   ` Marco Martinelli - 13Byte srl
2019-04-30 12:55     ` Michael S. Tsirkin
2019-04-30 13:56       ` Marco Martinelli - 13Byte srl
2019-04-30 14:00         ` Michael S. Tsirkin
2019-05-01 17:05     ` Stefan Hajnoczi
2019-05-02 11:18       ` Marco Martinelli - 13Byte srl
2019-05-03 16:45         ` Stefan Hajnoczi
2019-05-03 19:52           ` Marco Martinelli - 13Byte srl
2019-05-06  5:27             ` Gerd Hoffmann [this message]
2019-05-09 10:10               ` Marco Martinelli - 13Byte srl
2019-05-09 12:27                 ` Gerd Hoffmann
2019-05-10  9:45                   ` Mikhail Golubev
2019-05-10 12:16                     ` Gerd Hoffmann
2019-05-10 14:15                       ` Anton Yakovlev
2019-05-10 15:48                         ` Stefan Hajnoczi
2019-05-10 17:13                           ` Anton Yakovlev
2019-05-11 20:49                             ` Marco Martinelli - 13Byte srl
2019-05-12 20:01                               ` Matti Moell
2019-05-14 13:44                             ` Stefan Hajnoczi
2019-05-15  6:30                               ` Anton Yakovlev
2019-05-15  8:31                                 ` Anton Yakovlev
2019-05-15 16:03                                 ` Stefan Hajnoczi
2019-05-15 16:33                                   ` Anton Yakovlev
2019-05-16 10:24                                     ` Stefan Hajnoczi
2019-05-13  9:32                         ` Gerd Hoffmann
2019-05-14 19:14                           ` Anton Yakovlev
2019-05-10 10:34                   ` Stefan Hajnoczi

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=20190506052715.vkdopunuauyhl22m@sirius.home.kraxel.org \
    --to=kraxel@redhat.com \
    --cc=dirty.ice.hu@gmail.com \
    --cc=marco@13byte.com \
    --cc=stefanha@redhat.com \
    --cc=virtio-dev@lists.oasis-open.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.