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.

Il 01/05/19 19:05, Stefan Hajnoczi ha scritto:

On Mon, Apr 29, 2019 at 07:39:17PM +0200, Marco Martinelli - 13Byte srl wrote:
Il 29/04/19 15:47, Stefan Hajnoczi ha scritto:
On Mon, Apr 29, 2019 at 12:22:41AM +0200, Marco Martinelli - 13Byte srl wrote:
I'm not sure how this works, is that number already assigned and I should
use that or should I get a new one?

For last, I have a question to clear the things up for me. It is my
understanding that in this mailing list you discuss about the
specifications, not the actual code. What's the usual process when writing a
new virtio device?
Should I start with writing the code and then document how it works or is it
the opposite? Should I document it and have it approved and then implement
the specifications?

I know that this may sound like a stupid question, but please be patient
with me, it's my first time.
I suggest posting a draft specification for the new device type before
investing too much time in the implementation.

Then work on the code while the spec discussion is ongoing.  This way
you won't have to wait too long before implementation but you also won't
find that reviewers are asking for large changes after you completed
your work.
I feared that would be the answer.
As I stated I'm not familiar with most of the technologies involved. I don't
know if I have the capabilities to write a draft of the specifications
without first working on some code to clear things up.
I'll try my best.
I'm happy to help you get started.

I have a basic understanding of sound cards (mostly from an audio API
and application perspective) and can explain the virtio device model.

Please post the requirements and scope of the device you'd like to
create.  Are you thinking of something general-purpose like the USB
Audio Device Class specification, which can handle many different types
of devices.  Or were you thinking of something more limited?

In terms of virtio concepts, audio streams would be transferred in
chunks over virtqueues.  A "control" virtqueue might be necessary to
configure the device.  It would process configuration request/response


Hi Stefan,

thank you for your offer.

I'll explain what I have in mind.

The scope of my project is to transfer a multichannel PCM stream from the VM to the host and another the other way.

The VM will see this transport interface like a generic soundcard with configurable input / output.

Both windows and alsa work with PCM internally and it's not a problem to feed the stream of one to the other, keeping in mind that channel mapping may vary. I'm not aware of systems where PCM isn't used, I don't expect problems with this.

In Scream ( https://github.com/duncanthrax/scream ) I've used IVSHMEM as a ring buffer. That worked very well, it reduced the latency and improved the performances quite a bit over the original network protocol, but it's one way only (windows VM to linux host) and not as fast as it can be with virtio I think.

My idea is to have a device configuration layout where both the host and the guest can expose their current audio configuration, more or less like this.

struct virtio_audio_config {
        le32 sample_rate;      //from 8000Hz up to 192000Hz
        le8  sample_size;      //8bit, 16bit, 32bit or floating point
        le8  channels;         //from 1 (mono) up to 8 (7.1 surround) or even more in theory (eg. Dolby Atmos, 64 channels, or MAudio 1010, 20+ channels)         le8  channel_map[...]; //it's a list of constants to identify the channel order in the PCM stream (eg. CH_LEFT, CH_RIGHT, CH_CENTER)

The struct will be double, one from audio out, one for audio in. When the host or the guest change it's configuration its struct should be updated and the other side notified.

If the other side can't handle the configuration I'd like to figure out a graceful fallback. I have a few ideas in mind but I want to do some tests first.

If the host or the guest don't support audio out they can write 0 as number of channel, or zero out the entire struct during device initialization.
If they don't support audio input

I imagine two separate virtqueues, one for the output stream, another for the input stream.

What I want to do in the end consist in a few modules:
- virtio-audio specifications
- a new QEMU device based on the specs
- Windows driver for guest, based on MSVAD sample driver or SYSVAD sample driver, both released under MS-PL (I'll have to figure out how to have them signed and distributed, is MS-PL a problem?)
- ALSA driver for linux guest

Maybe I'll focus more on audio output at first and audio input later, because that's the common use case.

This weekend I'll take the time to document this better.

If you have any question or I was not clear let me know.


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