OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [virtio-dev] Request for a new device number for a virtio-audio device.


> 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

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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]