All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anton Yakovlev <Anton.Yakovlev@opensynergy.com>
To: Stefan Hajnoczi <stefanha@redhat.com>
Cc: "Gerd Hoffmann" <kraxel@redhat.com>,
	"Mikhail Golubev" <Mikhail.Golubev@opensynergy.com>,
	"Marco Martinelli - 13Byte srl" <marco@13byte.com>,
	"virtio-dev@lists.oasis-open.org"
	<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: Wed, 15 May 2019 06:30:45 +0000	[thread overview]
Message-ID: <76D732A88286A1478FFA94B453B715C1EEA27A2B@MXS02.open-synergy.com> (raw)
In-Reply-To: <20190514134448.GB6555@stefanha-x1.localdomain>

>> So, our proposal is to support classic way of communications by default and introduce shared memory based approach as either non-standard extension or part of future VIRTIO device types. And switch to this mode where it's possible or make sense. Like, all modern type-2 hypervisors usually have no problems with sharing memory between guest and host, so why not provide to user high quality virtual audio device?
>
> virtqueues offer reliable delivery, so #2 isn't an issue.
>
> Real-time is achievable and can be done with low latency.  Make the
> receiver a real-time thread that polls the vring periodically (based on
> the latency/buffer size requirement).  The vring supports lock-free
> access so this is perfect for real-time.
>
> When I say "receiver" I mean the driver's capture and device's playback
> components.  Both of them have real-time requirements.
>
> Does this approach meet your requirements?

After careful consideration, I think polling mode should make it possible. Like, using dedicated "data" queue per stream in polling mode (multiplexing is not an option, since it reduces queue throughput in proportion to the number of multiplexed streams). How to describe it in specification?


--
Anton Yakovlev
Senior Software Engineer

OpenSynergy GmbH
Rotherstr. 20, 10245 Berlin

www.opensynergy.com

Please mind our privacy notice<https://www.opensynergy.com/datenschutzerklaerung/privacy-notice-for-business-partners-pursuant-to-article-13-of-the-general-data-protection-regulation-gdpr/> pursuant to Art. 13 GDPR. // Unsere Hinweise zum Datenschutz gem. Art. 13 DSGVO finden Sie hier.<https://www.opensynergy.com/de/datenschutzerklaerung/datenschutzhinweise-fuer-geschaeftspartner-gem-art-13-dsgvo/>
COQOS Hypervisor certified by TÜV SÜD
                [COQOS Hypervisor certified by TÜV SÜD]

---------------------------------------------------------------------
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-15  6:31 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
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 [this message]
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=76D732A88286A1478FFA94B453B715C1EEA27A2B@MXS02.open-synergy.com \
    --to=anton.yakovlev@opensynergy.com \
    --cc=Mikhail.Golubev@opensynergy.com \
    --cc=dirty.ice.hu@gmail.com \
    --cc=kraxel@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 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.