Discussion of the implementations of VIRTIO specification
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Marco Martinelli - 13Byte srl <marco@13byte.com>
Cc: Stefan Hajnoczi <stefanha@redhat.com>, virtio-dev@lists.oasis-open.org
Subject: Re: [virtio-dev] Request for a new device number for a virtio-audio device.
Date: Tue, 30 Apr 2019 10:00:11 -0400	[thread overview]
Message-ID: <20190430095954-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <de0e195b-c78f-3b5a-dad1-e326e168b6a1@13byte.com>

On Tue, Apr 30, 2019 at 03:56:19PM +0200, Marco Martinelli - 13Byte srl wrote:
> Il 30/04/19 14:55, Michael S. Tsirkin 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:
> > > > > Hi everyone,
> > > > > 
> > > > > my name is Marco, from Italy. I'm a developer that recently got an interest
> > > > > in improving the current situation of audio in qemu/kvm.
> > > > > 
> > > > > I've been working successfully on multiple patches for Scream
> > > > > (https://github.com/duncanthrax/scream
> > > > > <https://github.com/duncanthrax/scream> ), a virtual sound card for
> > > > > Microsoft Windows, that allow to transfer audio from a Windows VM to a Linux
> > > > > host. The project initially supported only stereo sound over the network,
> > > > > but with my patches now it support up to 7.1 surround and it can transfer
> > > > > the audio samples using shared memory between the VM and the host (based on
> > > > > IVSHMEM), for lower latency.
> > > > > 
> > > > > Now that was a good project, but I want to do more. I dream of an
> > > > > virtio-audio device that can handle multichannel audio in and out of the VM,
> > > > > to be used with more guest OSs than just Windows.
> > > > > 
> > > > > I know I have a long way to go to reach this goal, but I'm motivated and
> > > > > willing to learn. I admit I don't have much experience with the qemu source
> > > > > code or the virtio source code, but I learn fast.
> > > > > 
> > > > > My work on Scream was to familiarize with Windows driver development,
> > > > > VM-to-host communication and low latency audio processing.
> > > > > My idea is to start with small self-contained projects to familiarize with
> > > > > the source codes of the various projects and gain the experience I lack,
> > > > > then moving on the real virtio-audio project.
> > > > > This way I can both obtain more knowledge on the subjects and help the open
> > > > > source community that over the years have done so much for many.
> > > > > 
> > > > > As we speak I'm reading the VirtIO documentation, where I've found out that
> > > > > I need to require a new device number for this project (Appendix B.3). So,
> > > > > here I am.
> > > > > 
> > > > > I'm not quite sure if this email is enough to obtain a new number or if I
> > > > > need to follow some process I'm not aware of. In the meantime I'm using the
> > > > > device number 65535 as documented in the specifications.
> > > > > 
> > > > > Looking around I've seen there is a recent issue on GitHub to reserve a
> > > > > virtio-audio device id, and a patch was submitter to assign id 25 to audio
> > > > > devices.
> > > > Is this the same virtio-audio device type that you want to work on or is
> > > > this an independent effort from another author?  It seems important to
> > > > contact the author (if it's not you) to find out the status of their
> > > > device and see what work can be shared.
> > > It is not my device, but I don't think there is any work behind this either.
> > > 
> > > The number 25 I was referring to comes from this message
> > > https://lists.oasis-open.org/archives/virtio/201903/msg00074.html
> > > 
> > > It seems to me that this number was reserved for a virtio-audio device, but
> > > not a specific one. Maybe I'm misinterpreting that message.
> > I think it's this one:
> > 
> > https://projectacrn.org/
> > 
> > given this project started using an ID without talking to anyone (which
> > almost led to a conflict - it only didn't because Paolo was super
> > diligent), it's a good idea to ask them whether they will be willing to
> > be more careful and at least reserve feature bits through the TC before
> > using them.
> > 
> > If not then we should rename this one to audio device (legacy)
> > and reserve an ID for
> > 
> > Could you reach out to them?
> I'll contact them today, thank you.

Thanks!
Pls Cc me on that email.

> > 
> > 
> > > > > 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.
> > There are two other options for contributing which might be
> > easier for people not comfortable with writing specs:
> > 
> > 1. If project acrn guys are willing to work with us
> >     in the future (meaning not making future interface changes
> >     without reserving a feature bit through the TC):
> >     - figure out their virtio-audio device interface, write
> >       compatible qemu device and guest driver implementations
> > 
> > 2. if they are not willing
> >     - send a small patch just like
> > 	https://lists.oasis-open.org/archives/virtio/201903/msg00074.html
> >       reserving a new id (+ renaming old one to legacy)
> >       then start hacking on your own as per option 1
> > 
> Ok, I'll see what their answer is and then decide what to do. Thank you.
> > 
> > 
> > > > Stefan
> > > 
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
> > > For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
> 
> -- 
> Marco

---------------------------------------------------------------------
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-04-30 14:04 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 [this message]
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
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=20190430095954-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox