From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: virtio-dev-return-5698-cohuck=redhat.com@lists.oasis-open.org Sender: List-Post: List-Help: List-Unsubscribe: List-Subscribe: Received: from lists.oasis-open.org (oasis.ws5.connectedcommunity.org [10.110.1.242]) by lists.oasis-open.org (Postfix) with ESMTP id 0591598434E for ; Sun, 28 Apr 2019 22:22:44 +0000 (UTC) From: Marco Martinelli - 13Byte srl Message-ID: Date: Mon, 29 Apr 2019 00:22:41 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------2936571D3BB5FA8550ED4B92" Content-Language: en-US Subject: [virtio-dev] Request for a new device number for a virtio-audio device. To: virtio-dev@lists.oasis-open.org List-ID: --------------2936571D3BB5FA8550ED4B92 Content-Type: text/plain; charset=iso-8859-15; format=flowed Content-Transfer-Encoding: 7bit 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 ), 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. 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. Best Regards, Marco --------------2936571D3BB5FA8550ED4B92 Content-Type: text/html; charset=iso-8859-15 Content-Transfer-Encoding: 7bit

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

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.


Best Regards,

Marco --------------2936571D3BB5FA8550ED4B92-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: virtio-dev-return-5700-cohuck=redhat.com@lists.oasis-open.org Sender: List-Post: List-Help: List-Unsubscribe: List-Subscribe: Received: from lists.oasis-open.org (oasis.ws5.connectedcommunity.org [10.110.1.242]) by lists.oasis-open.org (Postfix) with ESMTP id 7CBB8984364 for ; Mon, 29 Apr 2019 13:48:07 +0000 (UTC) Date: Mon, 29 Apr 2019 09:47:54 -0400 From: Stefan Hajnoczi Message-ID: <20190429134754.GI7587@stefanha-x1.localdomain> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7IgncvKP0CVPV/ZZ" Content-Disposition: inline In-Reply-To: Subject: Re: [virtio-dev] Request for a new device number for a virtio-audio device. To: Marco Martinelli - 13Byte srl Cc: virtio-dev@lists.oasis-open.org List-ID: --7IgncvKP0CVPV/ZZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 29, 2019 at 12:22:41AM +0200, Marco Martinelli - 13Byte srl wro= te: > Hi everyone, >=20 > my name is Marco, from Italy. I'm a developer that recently got an intere= st > in improving the current situation of audio in qemu/kvm. >=20 > I've been working successfully on multiple patches for Scream > (https://github.com/duncanthrax/scream > ), a virtual sound card for > Microsoft Windows, that allow to transfer audio from a Windows VM to a Li= nux > 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. >=20 > 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. >=20 > 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 sour= ce > code or the virtio source code, but I learn fast. >=20 > 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 op= en > source community that over the years have done so much for many. >=20 > As we speak I'm reading the VirtIO documentation, where I've found out th= at > I need to require a new device number for this project (Appendix B.3). So, > here I am. >=20 > 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 t= he > device number 65535 as documented in the specifications. >=20 > 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. > I'm not sure how this works, is that number already assigned and I should > use that or should I get a new one? >=20 > 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 writin= g 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? >=20 > 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. Stefan --7IgncvKP0CVPV/ZZ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJcxwCKAAoJEJykq7OBq3PIk/sH/0lhwruiPh6omaNYZELl2d53 ZZ9jojZz93qI4PeIb0OYwQOFepeQ2wnH6gzP2GUXeEYQP+Nh9PfsTKlGdLVI4g9a 6dvIZDtkWlYxlyjfQf5ikeZuFes8sp3AaU5CKazEbbDmm716x5SB4AXDgollrxXX CGOYLORpaOSB9bFINTDyQXdqhAs+9ZgODlkIHeqsqHOPuKQZJIyjMtLse2cyh+9F ukSke2fDhCL8vVEWFTU1F0t58zg4ti3xmgIBCcUV9/YQXePhD4kLKI4N74YOjS3d 3lYEIEx9fbiLdUHF4wDGctkxsIhR8gN5ofQ4nLZgfs1vbW159HL8jtuSMIm6rgY= =DgO2 -----END PGP SIGNATURE----- --7IgncvKP0CVPV/ZZ-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: virtio-dev-return-5701-cohuck=redhat.com@lists.oasis-open.org Sender: List-Post: List-Help: List-Unsubscribe: List-Subscribe: Received: from lists.oasis-open.org (oasis.ws5.connectedcommunity.org [10.110.1.242]) by lists.oasis-open.org (Postfix) with ESMTP id 8AD78984634 for ; Mon, 29 Apr 2019 17:39:21 +0000 (UTC) References: <20190429134754.GI7587@stefanha-x1.localdomain> From: Marco Martinelli - 13Byte srl Message-ID: <4fcd7456-de22-7f6d-d5ef-939cd3d7cf95@13byte.com> Date: Mon, 29 Apr 2019 19:39:17 +0200 MIME-Version: 1.0 In-Reply-To: <20190429134754.GI7587@stefanha-x1.localdomain> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Subject: Re: [virtio-dev] Request for a new device number for a virtio-audio device. To: Stefan Hajnoczi Cc: virtio-dev@lists.oasis-open.org List-ID: 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 >> ), 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'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. > Stefan --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: virtio-dev-return-5705-cohuck=redhat.com@lists.oasis-open.org Sender: List-Post: List-Help: List-Unsubscribe: List-Subscribe: Received: from lists.oasis-open.org (oasis.ws5.connectedcommunity.org [10.110.1.242]) by lists.oasis-open.org (Postfix) with ESMTP id A55F5985B8C for ; Tue, 30 Apr 2019 12:56:03 +0000 (UTC) Date: Tue, 30 Apr 2019 08:55:59 -0400 From: "Michael S. Tsirkin" Message-ID: <20190430084722-mutt-send-email-mst@kernel.org> References: <20190429134754.GI7587@stefanha-x1.localdomain> <4fcd7456-de22-7f6d-d5ef-939cd3d7cf95@13byte.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4fcd7456-de22-7f6d-d5ef-939cd3d7cf95@13byte.com> Subject: Re: [virtio-dev] Request for a new device number for a virtio-audio device. To: Marco Martinelli - 13Byte srl Cc: Stefan Hajnoczi , virtio-dev@lists.oasis-open.org List-ID: 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 > > > ), 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'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 > > Stefan > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org > For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: virtio-dev-return-5707-cohuck=redhat.com@lists.oasis-open.org Sender: List-Post: List-Help: List-Unsubscribe: List-Subscribe: Received: from lists.oasis-open.org (oasis.ws5.connectedcommunity.org [10.110.1.242]) by lists.oasis-open.org (Postfix) with ESMTP id B8644985B8C for ; Tue, 30 Apr 2019 13:56:24 +0000 (UTC) References: <20190429134754.GI7587@stefanha-x1.localdomain> <4fcd7456-de22-7f6d-d5ef-939cd3d7cf95@13byte.com> <20190430084722-mutt-send-email-mst@kernel.org> From: Marco Martinelli - 13Byte srl Message-ID: Date: Tue, 30 Apr 2019 15:56:19 +0200 MIME-Version: 1.0 In-Reply-To: <20190430084722-mutt-send-email-mst@kernel.org> Content-Type: text/plain; charset=iso-8859-15; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Subject: Re: [virtio-dev] Request for a new device number for a virtio-audio device. To: "Michael S. Tsirkin" Cc: Stefan Hajnoczi , virtio-dev@lists.oasis-open.org List-ID: 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 >>>> ), 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. > > >>>> 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: virtio-dev-return-5708-cohuck=redhat.com@lists.oasis-open.org Sender: List-Post: List-Help: List-Unsubscribe: List-Subscribe: Received: from lists.oasis-open.org (oasis.ws5.connectedcommunity.org [10.110.1.242]) by lists.oasis-open.org (Postfix) with ESMTP id AFEDE9879C8 for ; Tue, 30 Apr 2019 14:04:14 +0000 (UTC) Date: Tue, 30 Apr 2019 10:00:11 -0400 From: "Michael S. Tsirkin" Message-ID: <20190430095954-mutt-send-email-mst@kernel.org> References: <20190429134754.GI7587@stefanha-x1.localdomain> <4fcd7456-de22-7f6d-d5ef-939cd3d7cf95@13byte.com> <20190430084722-mutt-send-email-mst@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [virtio-dev] Request for a new device number for a virtio-audio device. To: Marco Martinelli - 13Byte srl Cc: Stefan Hajnoczi , virtio-dev@lists.oasis-open.org List-ID: 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 > > > > > ), 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: virtio-dev-return-5714-cohuck=redhat.com@lists.oasis-open.org Sender: List-Post: List-Help: List-Unsubscribe: List-Subscribe: Received: from lists.oasis-open.org (oasis.ws5.connectedcommunity.org [10.110.1.242]) by lists.oasis-open.org (Postfix) with ESMTP id B64F79875CD for ; Fri, 3 May 2019 18:09:38 +0000 (UTC) Date: Wed, 1 May 2019 13:05:25 -0400 From: Stefan Hajnoczi Message-ID: <20190501170525.GB22391@stefanha-x1.localdomain> References: <20190429134754.GI7587@stefanha-x1.localdomain> <4fcd7456-de22-7f6d-d5ef-939cd3d7cf95@13byte.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="bCsyhTFzCvuiizWE" Content-Disposition: inline In-Reply-To: <4fcd7456-de22-7f6d-d5ef-939cd3d7cf95@13byte.com> Subject: Re: [virtio-dev] Request for a new device number for a virtio-audio device. To: Marco Martinelli - 13Byte srl Cc: virtio-dev@lists.oasis-open.org, kraxel@redhat.com List-ID: --bCsyhTFzCvuiizWE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 29, 2019 at 07:39:17PM +0200, Marco Martinelli - 13Byte srl wro= te: > 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 sh= ould > > > use that or should I get a new one? > > >=20 > > > 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 wr= iting a > > > new virtio device? > > > Should I start with writing the code and then document how it works o= r is it > > > the opposite? Should I document it and have it approved and then impl= ement > > > the specifications? > > >=20 > > > I know that this may sound like a stupid question, but please be pati= ent > > > 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. > >=20 > > 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 do= n'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 packets. Stefan --bCsyhTFzCvuiizWE Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhpWov9P5fNqsNXdanKSrs4Grc8gFAlzJ0cIACgkQnKSrs4Gr c8jC6Af+N0Ry9gHP+QwroJEKZIBhzHObT9pLW2oslPKBRY07g+cWLxy4QpTCd0D8 5VVIzupvLwb5NHbLyPtIP8Vy/sl3R2+JfLHEUtggoVTf1eT0ox0rXvJxMAyGcBd+ FGQd12qjyZh3keACcYfguoRi2KV3CEC4viT+rWpaiuUeqbHUE+jjTTk3n60obAWD cwQxUHWhZzpbmAdjoMWdYXq9pMPo3Ob+2cGnbDDMGh5NPUgfZlji8KQZ9qi+cIQu pOpeuIqM0usDS7MOGMXhVQA6RTu1fxbykt7HQYvIiLsmZb+bxCLMRL9+gK7fjjqQ AtFh1lJjHH6JuCaJ+U/tw9z6gecO3w== =Shc8 -----END PGP SIGNATURE----- --bCsyhTFzCvuiizWE-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: virtio-dev-return-5713-cohuck=redhat.com@lists.oasis-open.org Sender: List-Post: List-Help: List-Unsubscribe: List-Subscribe: Received: from lists.oasis-open.org (oasis.ws5.connectedcommunity.org [10.110.1.242]) by lists.oasis-open.org (Postfix) with ESMTP id F330F986198 for ; Fri, 3 May 2019 17:54:02 +0000 (UTC) References: <20190429134754.GI7587@stefanha-x1.localdomain> <4fcd7456-de22-7f6d-d5ef-939cd3d7cf95@13byte.com> <20190501170525.GB22391@stefanha-x1.localdomain> From: Marco Martinelli - 13Byte srl Message-ID: Date: Thu, 2 May 2019 13:18:40 +0200 MIME-Version: 1.0 In-Reply-To: <20190501170525.GB22391@stefanha-x1.localdomain> Content-Type: text/plain; charset="windows-1252"; format="flowed" Content-Transfer-Encoding: quoted-printable Content-Language: en-US Subject: Re: [virtio-dev] Request for a new device number for a virtio-audio device. To: Stefan Hajnoczi Cc: virtio-dev@lists.oasis-open.org, kraxel@redhat.com List-ID: Il 01/05/19 19:05, Stefan Hajnoczi ha scritto: > On Mon, Apr 29, 2019 at 07:39:17PM +0200, Marco Martinelli - 13Byte srl w= rote: >> 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 sho= uld >>>> 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 wri= ting 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 imple= ment >>>> the specifications? >>>> >>>> I know that this may sound like a stupid question, but please be patie= nt >>>> 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 d= on'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 > packets. > > Stefan 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=20 the VM to the host and another the other way. The VM will see this transport interface like a generic soundcard with=20 configurable input / output. Both windows and alsa work with PCM internally and it's not a problem to=20 feed the stream of one to the other, keeping in mind that channel=20 mapping may vary. I'm not aware of systems where PCM isn't used, I don't expect problems=20 with this. In Scream ( https://github.com/duncanthrax/scream ) I've used IVSHMEM as=20 a ring buffer. That worked very well, it reduced the latency and=20 improved the performances quite a bit over the original network=20 protocol, but it's one way only (windows VM to linux host) and not as=20 fast as it can be with virtio I think. My idea is to have a device configuration layout where both the host and=20 the guest can expose their current audio configuration, more or less=20 like this. struct virtio_audio_config { =A0=A0=A0=A0=A0=A0=A0 le32 sample_rate;=A0=A0=A0=A0=A0 //from 8000Hz up to= 192000Hz =A0=A0=A0=A0=A0=A0=A0 le8=A0 sample_size;=A0=A0=A0=A0=A0 //8bit, 16bit, 32= bit or floating point =A0=A0=A0=A0=A0=A0=A0 le8=A0 channels;=A0=A0=A0=A0=A0=A0=A0=A0 //from 1 (m= ono) up to 8 (7.1 surround)=20 or even more in theory (eg. Dolby Atmos, 64 channels, or MAudio 1010,=20 20+ channels) =A0=A0=A0=A0=A0=A0=A0 le8=A0 channel_map[...]; //it's a list of constants = to identify=20 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=20 the host or the guest change it's configuration its struct should be=20 updated and the other side notified. If the other side can't handle the configuration I'd like to figure out=20 a graceful fallback. I have a few ideas in mind but I want to do some=20 tests first. If the host or the guest don't support audio out they can write 0 as=20 number of channel, or zero out the entire struct during device=20 initialization. If they don't support audio input I imagine two separate virtqueues, one for the output stream, another=20 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=20 sample driver, both released under MS-PL (I'll have to figure out how to=20 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,=20 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. Marco --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: virtio-dev-return-5712-cohuck=redhat.com@lists.oasis-open.org Sender: List-Post: List-Help: List-Unsubscribe: List-Subscribe: Received: from lists.oasis-open.org (oasis.ws5.connectedcommunity.org [10.110.1.242]) by lists.oasis-open.org (Postfix) with ESMTP id F28B2985BE7 for ; Fri, 3 May 2019 17:12:39 +0000 (UTC) Date: Fri, 3 May 2019 10:45:01 -0600 From: Stefan Hajnoczi Message-ID: <20190503164501.GB8373@stefanha-x1.localdomain> References: <20190429134754.GI7587@stefanha-x1.localdomain> <4fcd7456-de22-7f6d-d5ef-939cd3d7cf95@13byte.com> <20190501170525.GB22391@stefanha-x1.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="zx4FCpZtqtKETZ7O" Content-Disposition: inline In-Reply-To: Subject: Re: [virtio-dev] Request for a new device number for a virtio-audio device. To: Marco Martinelli - 13Byte srl Cc: virtio-dev@lists.oasis-open.org, kraxel@redhat.com List-ID: --zx4FCpZtqtKETZ7O Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, May 02, 2019 at 01:18:40PM +0200, Marco Martinelli - 13Byte srl wro= te: > Il 01/05/19 19:05, Stefan Hajnoczi ha scritto: >=20 > > 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? > > > > >=20 > > > > > 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 whe= n writing a > > > > > new virtio device? > > > > > Should I start with writing the code and then document how it wor= ks or is it > > > > > the opposite? Should I document it and have it approved and then = implement > > > > > the specifications? > > > > >=20 > > > > > 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 bef= ore > > > > investing too much time in the implementation. > > > >=20 > > > > Then work on the code while the spec discussion is ongoing. This w= ay > > > > 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. > >=20 > > I have a basic understanding of sound cards (mostly from an audio API > > and application perspective) and can explain the virtio device model. > >=20 > > 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? > >=20 > > 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 > > packets. > >=20 > > Stefan >=20 > Hi Stefan, >=20 > thank you for your offer. >=20 > I'll explain what I have in mind. Thanks. Some random thoughts (not strong opinions) below: >=20 > The scope of my project is to transfer a multichannel PCM stream from the= VM > to the host and another the other way. >=20 > The VM will see this transport interface like a generic soundcard with > configurable input / output. >=20 > 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 wi= th > this. >=20 > 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 t= he > 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 vir= tio > I think. >=20 > 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 thi= s. >=20 > struct virtio_audio_config { > =A0=A0=A0=A0=A0=A0=A0 le32 sample_rate;=A0=A0=A0=A0=A0 //from 8000Hz up t= o 192000Hz > =A0=A0=A0=A0=A0=A0=A0 le8=A0 sample_size;=A0=A0=A0=A0=A0 //8bit, 16bit, 3= 2bit or floating point > =A0=A0=A0=A0=A0=A0=A0 le8=A0 channels;=A0=A0=A0=A0=A0=A0=A0=A0 //from 1 (= mono) up to 8 (7.1 surround) or > even more in theory (eg. Dolby Atmos, 64 channels, or MAudio 1010, 20+ > channels) > =A0=A0=A0=A0=A0=A0=A0 le8=A0 channel_map[...]; //it's a list of constants= to identify the > channel order in the PCM stream (eg. CH_LEFT, CH_RIGHT, CH_CENTER) > }; >=20 > 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. >=20 > 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. This does not offer a way to enumerate supported configurations. The other side blindly suggests a configuration which may or may not be accepted. Enumeration of sample rates, channel topologies, sample formats, etc would allow for negotiation that works the first time and instead of guessing a configuration that ends up being rejected by the other side. > If the host or the guest don't support audio out they can write 0 as numb= er > of channel, or zero out the entire struct during device initialization. > If they don't support audio input >=20 > I imagine two separate virtqueues, one for the output stream, another for > the input stream. >=20 > 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 th= em > signed and distributed, is MS-PL a problem?) > - ALSA driver for linux guest This is also what I'd imagine. >=20 > Maybe I'll focus more on audio output at first and audio input later, > because that's the common use case. >=20 > This weekend I'll take the time to document this better. >=20 > If you have any question or I was not clear let me know. Okay, it sounds like an audio API-level interface, not lower-level like what the USB Audio Device Class does. I'm not sure if we lose any important functionality by choosing a high level interface. How would soundcards with multiple inputs work? Is each input represented as a separate virtio-audio device? The alternative is to use an arbitrary number of mono or stereo channel pairs... Stefan --zx4FCpZtqtKETZ7O Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhpWov9P5fNqsNXdanKSrs4Grc8gFAlzMb/AACgkQnKSrs4Gr c8in+Qf+LqSTQlaHYlWNguXRwvcLyqRYk/eEGA7v7obtLR0/equG//4JvAh4Pxdc D4LSMOMZa4mJA8n7UPtT9cLBHMunpTG/TJN8jOoTHNLcuX84wM+JOYqi+KxpGbCl i4G0Zg28aE6jyuWMoZ4X6y2DJFXypGRmLBCSj6T4k5nFgJyIg8s2gJyJ7kY4J7yS 3R+BQs+SMO4CWq7NY4vktWVkmkuY2AAmc2dGMyGG0T5DvVyXi0osbsexUruf7/Mz 5yp6t7LQRS7dF7At4i40t7y29IVqyfQ8DeyBqMgC5W4vV4yDTg3JkLnV3b9zk2BF KSnzqfIJF75ITNpioefdMqYogfqybw== =KmKK -----END PGP SIGNATURE----- --zx4FCpZtqtKETZ7O-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: virtio-dev-return-5717-cohuck=redhat.com@lists.oasis-open.org Sender: List-Post: List-Help: List-Unsubscribe: List-Subscribe: Received: from lists.oasis-open.org (oasis.ws5.connectedcommunity.org [10.110.1.242]) by lists.oasis-open.org (Postfix) with ESMTP id AB9E8985B4A for ; Fri, 3 May 2019 19:52:14 +0000 (UTC) References: <20190429134754.GI7587@stefanha-x1.localdomain> <4fcd7456-de22-7f6d-d5ef-939cd3d7cf95@13byte.com> <20190501170525.GB22391@stefanha-x1.localdomain> <20190503164501.GB8373@stefanha-x1.localdomain> From: Marco Martinelli - 13Byte srl Message-ID: <863e1be1-11cc-816b-896d-3954427e98f3@13byte.com> Date: Fri, 3 May 2019 21:52:10 +0200 MIME-Version: 1.0 In-Reply-To: <20190503164501.GB8373@stefanha-x1.localdomain> Content-Type: text/plain; charset="windows-1252"; format="flowed" Content-Transfer-Encoding: quoted-printable Content-Language: en-US Subject: Re: [virtio-dev] Request for a new device number for a virtio-audio device. To: Stefan Hajnoczi , virtio-dev@lists.oasis-open.org Cc: kraxel@redhat.com List-ID: Il 03/05/19 18:45, Stefan Hajnoczi ha scritto: > On Thu, May 02, 2019 at 01:18:40PM +0200, Marco Martinelli - 13Byte srl w= rote: >> 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 s= rl wrote: >>>>>> I'm not sure how this works, is that number already assigned and I s= hould >>>>>> 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 w= riting 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 imp= lement >>>>>> the specifications? >>>>>> >>>>>> I know that this may sound like a stupid question, but please be pat= ient >>>>>> 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 wo= n'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 >>> packets. >>> >>> Stefan >> Hi Stefan, >> >> thank you for your offer. >> >> I'll explain what I have in mind. > Thanks. Some random thoughts (not strong opinions) below: > >> The scope of my project is to transfer a multichannel PCM stream from th= e 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 w= ith >> 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 vi= rtio >> 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 th= is. >> >> struct virtio_audio_config { >> =A0=A0=A0=A0=A0=A0=A0 le32 sample_rate;=A0=A0=A0=A0=A0 //from 8000Hz up= to 192000Hz >> =A0=A0=A0=A0=A0=A0=A0 le8=A0 sample_size;=A0=A0=A0=A0=A0 //8bit, 16bit,= 32bit or floating point >> =A0=A0=A0=A0=A0=A0=A0 le8=A0 channels;=A0=A0=A0=A0=A0=A0=A0=A0 //from 1= (mono) up to 8 (7.1 surround) or >> even more in theory (eg. Dolby Atmos, 64 channels, or MAudio 1010, 20+ >> channels) >> =A0=A0=A0=A0=A0=A0=A0 le8=A0 channel_map[...]; //it's a list of constan= ts 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. > This does not offer a way to enumerate supported configurations. The > other side blindly suggests a configuration which may or may not be > accepted. > > Enumeration of sample rates, channel topologies, sample formats, etc > would allow for negotiation that works the first time and instead of > guessing a configuration that ends up being rejected by the other side. I agree with you on this. The reason I opted to keep it simple in my=20 description is that I have yet to clear my ideas on how to implement=20 this particular feature. From my previous experience with MSVAD driver I saw that the driver=20 enumerate all the possible configurations when it's initialized. I think ALSA works in the same way but I have yet to verify this. It's possible to enquiry the virtio-audio device about the host=20 capabilities at this time but I'm not sure how to implement this in=20 every audio backend of qemu (alsa, pulse, oss, coreaudio, dsound, ...) Another thing to consider is that the host may have multiple sound=20 cards. For example I have three sound cards at the moment, an integrated=20 one with stereo at max 96kHZ, a dedicated one with 7.1 surround up to=20 192kHz and my video card has HDMI audio out (not sure of the specs). What can be considered a valid configuration in this scenario? Another possibility is that the user can configure the virtio-audio=20 device with the capabilities that he want to expose to the guest,=20 regardless if the host really support them or not. What do you think? In this scenario the user can even setup two separate VM with one=20 virtio-audio device each and route the audio from one to another with=20 something like JACK even if the host don't support the VM configuration.=20 Anything capable of piping the stream from one VM to the other will do=20 just fine. Another idea is that the user may want to record the stream to process=20 it later. It doesn't matter if the host audio card is not capable of=20 reproducing it. The host may not even have a sound card in this case. Can you think of any other use case? > >> If the host or the guest don't support audio out they can write 0 as num= ber >> of channel, or zero out the entire struct during device initialization. >> If they don't support audio input they can ignore it. >> >> 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 t= hem >> signed and distributed, is MS-PL a problem?) >> - ALSA driver for linux guest > This is also what I'd imagine. > >> 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. > Okay, it sounds like an audio API-level interface, not lower-level like > what the USB Audio Device Class does. I'm not sure if we lose any > important functionality by choosing a high level interface. Yes, it's not too low level, all I want is to push the PCM stream to the=20 host (or pull one if it's an input). No channel mixing, no signal processing, .. this will be the host job. > How would soundcards with multiple inputs work? Is each input > represented as a separate virtio-audio device? The alternative is to > use an arbitrary number of mono or stereo channel pairs... I admit I never considered this. I always pictured one input and one=20 output with different number of channels. I guess the simple answer is that users can attach as many virtio-audio=20 devices as they want with different configurations but I'll look around=20 to see if there is any benefit in having multiple input or output in the=20 same device. > > Stefan Marco --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: virtio-dev-return-5719-cohuck=redhat.com@lists.oasis-open.org Sender: List-Post: List-Help: List-Unsubscribe: List-Subscribe: Received: from lists.oasis-open.org (oasis.ws5.connectedcommunity.org [10.110.1.242]) by lists.oasis-open.org (Postfix) with ESMTP id 46914985B98 for ; Mon, 6 May 2019 05:27:21 +0000 (UTC) Date: Mon, 6 May 2019 07:27:15 +0200 From: Gerd Hoffmann Message-ID: <20190506052715.vkdopunuauyhl22m@sirius.home.kraxel.org> References: <20190429134754.GI7587@stefanha-x1.localdomain> <4fcd7456-de22-7f6d-d5ef-939cd3d7cf95@13byte.com> <20190501170525.GB22391@stefanha-x1.localdomain> <20190503164501.GB8373@stefanha-x1.localdomain> <863e1be1-11cc-816b-896d-3954427e98f3@13byte.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <863e1be1-11cc-816b-896d-3954427e98f3@13byte.com> Subject: Re: [virtio-dev] Request for a new device number for a virtio-audio device. To: Marco Martinelli - 13Byte srl Cc: Stefan Hajnoczi , virtio-dev@lists.oasis-open.org, =?utf-8?B?S8WRdsOhZ8OzIFpvbHTDoW4=?= List-ID: 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: virtio-dev-return-5721-cohuck=redhat.com@lists.oasis-open.org Sender: List-Post: List-Help: List-Unsubscribe: List-Subscribe: Received: from lists.oasis-open.org (oasis.ws5.connectedcommunity.org [10.110.1.242]) by lists.oasis-open.org (Postfix) with ESMTP id F31FC985DAB for ; Thu, 9 May 2019 10:10:11 +0000 (UTC) References: <20190429134754.GI7587@stefanha-x1.localdomain> <4fcd7456-de22-7f6d-d5ef-939cd3d7cf95@13byte.com> <20190501170525.GB22391@stefanha-x1.localdomain> <20190503164501.GB8373@stefanha-x1.localdomain> <863e1be1-11cc-816b-896d-3954427e98f3@13byte.com> <20190506052715.vkdopunuauyhl22m@sirius.home.kraxel.org> From: Marco Martinelli - 13Byte srl Message-ID: <7ac2ae97-bcb7-22cc-272a-723e7209910c@13byte.com> Date: Thu, 9 May 2019 12:10:07 +0200 MIME-Version: 1.0 In-Reply-To: <20190506052715.vkdopunuauyhl22m@sirius.home.kraxel.org> Content-Type: text/plain; charset="utf-8"; format="flowed" Content-Transfer-Encoding: 8bit Content-Language: en-US Subject: Re: [virtio-dev] Request for a new device number for a virtio-audio device. To: Gerd Hoffmann , virtio-dev@lists.oasis-open.org Cc: Stefan Hajnoczi , =?UTF-8?B?S8WRdsOhZ8OzIFpvbHTDoW4=?= List-ID: Hi Gerd, thank you for your feedback and sorry for the late reply. > 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). Interesting, I wasn't aware of that. I'll make sure to look at his work. > 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 ... I absolutely agree. While my desire is to work on qemu the specifications must be agnostic. >> 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. I don't really agree here, I don't see why I have to tie a virtual soundcard 1-to-1 to a real soundcard. While the guest will support multiple virtio-audio cards what I imagine as a common scenario is something like the following. The guest see one virtio-audio card. On the host I open pavucontrol  (just an example) and set the default output to my internal sound card, where I have my headset attached. On the guest I open my browser and listen to some music in stereo. After a while I want to see a movie, I launch my movie player and in pavucontrol I switch the output to my external 7.1 amplifier. Then I have to call a friend on skype, again I switch to my headset and as an input I select an usb microphone I just connected to my linux box. All of this without touching the VM configuration. This exact scenario is possible. It is what I have already done in Scream and it's working very well. Having a 1-to-1 map between host sound cards  and virtio-audio sound cards just seems inconvenient. You attached a plug and play soundcard? Too bad. Stop your VM, add a new device, restart.. No, I don't really want that. >> 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. I don't want qemu to do audio processing either. It's not its job. Having virtio-audio support configuration that the host sound card doesn't support doesn't mean that qemu have to do the audio processing. Imagine this scenario. In a windows VM I can run some professional digital audio workstation software that currently don't support linux. I can set these software to work with whatever settings I want (say, 192kHz, floating point, 8 channels). Virtio-audio will be able to transport the resulting PCM stream from the VM to the host unaltered, where for example JACK will take it and route them to, say, Ardour. I don't need the host sound card support here. I really don't care if it can't play this stream directly. As another example, I can have a virtio-audio with 10 input channels, and with JACK I can map different sources from the host to different channels to work on my audio workstation in the windows VM. This will open the door to professional uses that are currently not possible. Yes, in the end something will have to do the resampling, but that can be my linux DAW (eg. Ardour), or JACK, or Pulseaudio or anything. It will be up to the user to route the stream where he wants. > 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. Agree. >> 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. Yes, I didn't explain it very well, sorry. I wasn't really thinking of writing this to a wav file but routing to professional audio tools like in the example above. >> 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. Yeah, I thought about it and I don't think it's a common use case. That said I can see a few uses for it. For example, I can set a virtio-audio card with 2 outputs and 1 input and set in my VM, say, spotify to output 2 and skype on output 1 and input 1. On the host I can set the output of spotify to one soundcard, say, a bluetooth speaker in the room next door while I can skype chat with a friend on the headset. Nowdays most softwares can remember the assigned input/output devices, so I can set this once and forget about it. As a general note, I see virtio-audio as a generic interface to transfer PCM streams in and out of the VM. I don't want to limit it or tying it too much to a particular system or backend. I want it to be simple and flexible. I'm sure the end users will imagine use cases that I can't even think about now. Maybe they'll be bizarre configurations, who knows, but I certainly don't want to limit them. I think we agree that the specification should be independent of the end system. The qemu device that will implement this specification is a specific implementation but now we don't really have to care what it will do with the streams it will receive from the guest. It can send them to /dev/null for all I care. For the sake of the specification I think we need to focus on is how to transport these streams and how to share a configuration for each one. How the stream will be handled by the host it's a matter of implementation in the qemu device (or whatever other software will implement this spec) and that's out of the scope of the specification. Or at least this is how I think a specification should work, but please correct me if I'm wrong, I'm new to all of this. > cheers, > Gerd > Regards, Marco --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: virtio-dev-return-5722-cohuck=redhat.com@lists.oasis-open.org Sender: List-Post: List-Help: List-Unsubscribe: List-Subscribe: Received: from lists.oasis-open.org (oasis.ws5.connectedcommunity.org [10.110.1.242]) by lists.oasis-open.org (Postfix) with ESMTP id 53A9D985DB0 for ; Thu, 9 May 2019 12:27:16 +0000 (UTC) Date: Thu, 9 May 2019 14:27:10 +0200 From: Gerd Hoffmann Message-ID: <20190509122710.rfhfnhqez2u7inju@sirius.home.kraxel.org> References: <20190429134754.GI7587@stefanha-x1.localdomain> <4fcd7456-de22-7f6d-d5ef-939cd3d7cf95@13byte.com> <20190501170525.GB22391@stefanha-x1.localdomain> <20190503164501.GB8373@stefanha-x1.localdomain> <863e1be1-11cc-816b-896d-3954427e98f3@13byte.com> <20190506052715.vkdopunuauyhl22m@sirius.home.kraxel.org> <7ac2ae97-bcb7-22cc-272a-723e7209910c@13byte.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <7ac2ae97-bcb7-22cc-272a-723e7209910c@13byte.com> Subject: Re: [virtio-dev] Request for a new device number for a virtio-audio device. To: Marco Martinelli - 13Byte srl Cc: virtio-dev@lists.oasis-open.org, Stefan Hajnoczi , =?utf-8?B?S8WRdsOhZ8OzIFpvbHTDoW4=?= List-ID: Hi, > > 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. >=20 > I don't really agree here, I don't see why I have to tie a virtual soundc= ard > 1-to-1 to a real soundcard. Yes, but you still have to manage output capabilities somehow. > While the guest will support multiple virtio-audio cards what I imagine a= s a > common scenario is something like the following. >=20 > The guest see one virtio-audio card. >=20 > On the host I open pavucontrol=A0 (just an example) and set the default o= utput > to my internal sound card, where I have my headset attached. >=20 > On the guest I open my browser and listen to some music in stereo. >=20 > After a while I want to see a movie, I launch my movie player and in > pavucontrol I switch the output to my external 7.1 amplifier. Ok, so the question is how you present that to the guest. The guests sound device suddenly changing capabilities (when you re-route from host stereo to host 7.1) isn't going to work. You could present a single output which is able to support both stereo and 7.1. You need somehow handle the case that your guest sends 7.1 while the output is routed to stereo on the host (can pulseaudio resample that for us?) You could present two outputs to the guest (doesn't matter much whenever one card with two outputs or two cards with one output each), where one supports stereo and the other 7.1. Then allow routing the guests 7.1 output only to 7.1-capable host outputs, likewise for stereo. Not sure which of the two options will work better in practice. > Virtio-audio will be able to transport the resulting PCM stream from the = VM > to the host unaltered, where for example JACK will take it and route them > to, say, Ardour. >=20 > I don't need the host sound card support here. I really don't care if it > can't play this stream directly. Yes, sure. It's not so much about host soundcards, but about host audio backends. In some cases the qemu audio backend is linked to a specific sound card (alsa, oss), but on other cases it isn't (pulseaudio). With qemu sending the pcm stream to a sound server like pulseaudio (or jack when someone writes a backend) the sound server can of course re-route and/or process the stream as it pleases. > For the sake of the specification I think we need to focus on is how to > transport these streams and how to share a configuration for each one. I think we need at least three virt queues. One control queue for commands (query capabilities, set configuration, start/stop streams, volume control, ...). One queue for input streams. One queue for output streams. If we want allow for multiple inputs/outputs we have basically two options: (a) one queue per stream, or (b) use a small header for each data packet, telling what stream it belongs to. Maybe a small header is a good idea anyway, for timestamps. > Or at least this is how I think a specification should work, but please > correct me if I'm wrong, I'm new to all of this. That is correct. 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: virtio-dev-return-5723-cohuck=redhat.com@lists.oasis-open.org Sender: List-Post: List-Help: List-Unsubscribe: List-Subscribe: Received: from lists.oasis-open.org (oasis.ws5.connectedcommunity.org [10.110.1.242]) by lists.oasis-open.org (Postfix) with ESMTP id 57676985DFA for ; Fri, 10 May 2019 09:45:50 +0000 (UTC) References: <20190429134754.GI7587@stefanha-x1.localdomain> <4fcd7456-de22-7f6d-d5ef-939cd3d7cf95@13byte.com> <20190501170525.GB22391@stefanha-x1.localdomain> <20190503164501.GB8373@stefanha-x1.localdomain> <863e1be1-11cc-816b-896d-3954427e98f3@13byte.com> <20190506052715.vkdopunuauyhl22m@sirius.home.kraxel.org> <7ac2ae97-bcb7-22cc-272a-723e7209910c@13byte.com> <20190509122710.rfhfnhqez2u7inju@sirius.home.kraxel.org> From: Mikhail Golubev Message-ID: <5d316321-2c48-342b-f2ce-359e3596dae0@opensynergy.com> Date: Fri, 10 May 2019 11:45:24 +0200 MIME-Version: 1.0 In-Reply-To: <20190509122710.rfhfnhqez2u7inju@sirius.home.kraxel.org> Content-Type: multipart/mixed; boundary="------------27E016126600CA6DDCC71654" Content-Language: en-US Subject: Re: [virtio-dev] Request for a new device number for a virtio-audio device. To: Gerd Hoffmann , Marco Martinelli - 13Byte srl Cc: virtio-dev@lists.oasis-open.org, Stefan Hajnoczi , =?UTF-8?B?S8WRdsOhZ8OzIFpvbHTDoW4=?= List-ID: --------------27E016126600CA6DDCC71654 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: quoted-printable Hi all! Sorry for breaking in the middle of the virtio audio driver and device development discussion. But we are developing a virtio sound card prototype= for a while and we would like to share our specification draft and public heade= r file (attaching 'virtio_snd.h' and 'virtio-snd-spec-draft.md'). The PoC for proposed approach was tested with virtio audio driver in Linux and in Windo= ws 10 as well. It would be really great if we can collaborate on this topic. I would be ha= ppy to answer any questions. -- Mikhail Golubev Software Engineer OpenSynergy GmbH Rotherstr. 20, 10245 Berlin Telefon: +49 (30) 60 98 54 0 - 903 Fax: +49 (30) 60 98 54 0 - 99 EMail: mikhail.golubev@opensynergy.com www.opensynergy.com Handelsregister/Commercial Registry: Amtsgericht Charlottenburg, HRB 108616= B Gesch=C3=A4ftsf=C3=BChrer/Managing Director: Stefaan Sonck Thiebaut Please mind our privacy notice pursuant to Art. 13 GDPR. // Unsere= Hinweise zum Datenschutz gem. Art. 13 DSGVO finden Sie hier. COQOS Hypervisor certified by T=C3=9CV S=C3=9CD [COQOS Hypervisor certified by T=C3=9CV S=C3=9CD] --------------27E016126600CA6DDCC71654 Content-Type: text/markdown; name="virtio-snd-spec-draft.md" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="virtio-snd-spec-draft.md" # VirtIO sound card draft specification The VirtIO sound card is an extendible virtual audio device. It provides its functionality in a form of device functions that can be configured and managed in an independent way. ## Device ID TBD ## Virtqueues 0 > controlq ## Feature Bits None currently defined ## Device Configuration Layout Configuration space provides a maximum amount of available virtual queues. The nqueues value MUST be at least one. ``` struct virtio_snd_config { le32 nqueues; }; ``` ## Device Initialization The driver SHOULD perform the following initialization sequence: 1. Initialize all available virtual queues. 2. Read a device configuration. 3. For every available function perform function-specific initialization. ## Device Operation All control messages are placed into a single virtual queue with index zero. A control message consumes two virtual queue descriptors: one containing a read-only request and one containing a writable response. Each request begins with a 2-byte field that identifies a recipient function followed by a 2-byte field that identifies a function-specific request type. Each response begins with a 4-byte field that contains a status code. The values 0-31 are reserved for common status codes, a function can define function-specific status codes starting from 32. ``` struct virtio_snd_req { le16 function; le16 request; }; /* no errors */ #define VIRTIO_SND_E_SUCCESS 0 /* an undefined error */ #define VIRTIO_SND_E_GENERAL 1 /* not supported input parameter(s) */ #define VIRTIO_SND_E_NOTSUPPORTED 2 /* invalid input parameter(s) */ #define VIRTIO_SND_E_INVALID 3 /* I/O error */ #define VIRTIO_SND_E_IO 4 struct virtio_snd_rsp { le32 status; /* VIRTIO_SND_E_XXX */ }; ``` If a request consists only of a generic header, it's referred as a *generic request*. If a response consists only of a generic header, it's referred as a *generic response*. ### Device Configuration The device reports its configuration using descriptors. A descriptor is a data structure with a defined format. Each descriptor begins with a byte-wide field that contains the total number of bytes in the descriptor followed by a byte-wide field that identifies the descriptor type. ``` struct virtio_snd_generic_desc { u8 length; u8 type; u16 padding; }; ``` With the exception of the base function, all implemented functions MUST define its own descriptor(s) format (either presented in this specification or vendor-specific) and MUST includes these in configuration only if a particular function (or part of its functionality) is enabled in the device. ## Device Operation: Base Function A function identifier zero is reserved for base messages that can affect the entire device. The device MUST support all base requests and responses defined in this specification. ``` #define VIRTIO_SND_FN_BASE 0 /* --- BASE REQUEST TYPES --- */ #define VIRTIO_SND_BASE_R_GET_CFG 0 #define VIRTIO_SND_BASE_R_SUSPEND 1 #define VIRTIO_SND_BASE_R_RESUME 2 ``` ### Function Operation #### Get Device Configuration The driver sends the VIRTIO_SND_BASE_R_GET_CFG generic request, the device answers with a response containing device configuration. The driver MUST examine response content, initialize all presented and supported device functions and ignore all unsupported ones. ``` #define VIRTIO_SND_BASE_CFG_MAX_SIZE 1024 /* a response containing device configuration */ struct virtio_snd_base_configuration { struct virtio_snd_rsp hdr; /* size in bytes of configuration data */ le32 length; /* configuration data */ u8 data[VIRTIO_SND_BASE_CFG_MAX_SIZE]; }; ``` #### Suspend The driver sends the VIRTIO_SND_BASE_R_SUSPEND generic request, the device answers with a generic response. For each initialized function, the device SHOULD be able to preserve its runtime state and MUST put it into function-specific suspended state. #### Resume The driver sends the VIRTIO_SND_BASE_R_RESUME generic request, the device answers with a generic response. For each initialized function, the device SHOULD be able to restore its runtime state and MUST put it into function-specific non-suspended state. ## Device Operation: PCM Function The PCM function provides up to one playback and up to one capture PCM streams. If the device supports more than one PCM streams of the same type, it MUST provide them as separate PCM functions. A PCM stream contains one or more PCM substreams sharing the same capabilities reported in configuration, and all further function manipulations are happened on per dedicated substream basis. The function supports only the interleaved channels and MUST support at least one of the following operational modes: - *Manual mode*: the driver assigns a dedicated virtual queue for a PCM substream and use it to transmit data buffers to the device. The device writes/reads PCM frames only upon receiving a buffer from the driver. - *Automatic mode*: the driver allocates and shares with the device a pseudophysically continuous memory area containing runtime control registers and data buffer itself. In case of the playback stream, the device reads constant amount of PCM frames with constant time intervals without any requests from the driver. In case of the capture stream, the device writes constant amount of PCM frames with constant time intervals without any notifications to the driver. Regardless of the mode of operation, the device MAY require to specify an approximate data buffer update frequency. In such case, the driver MUST specify an approximate update frequency (expressed in both microseconds and bytes units) before starting a PCM substream. The function also MAY provide an ability to get and set supported channel maps. The device reports mentioned functional features using the features field in a PCM stream configuration descriptor. A PCM request consists of or is preceded by a header: ``` #define VIRTIO_SND_FN_PCM 1 /* --- PCM REQUEST TYPES --- */ #define VIRTIO_SND_PCM_R_GET_FEATURE 0 #define VIRTIO_SND_PCM_R_SET_FEATURE 1 #define VIRTIO_SND_PCM_R_SET_FORMAT 2 #define VIRTIO_SND_PCM_R_PREPARE 3 #define VIRTIO_SND_PCM_R_START 4 #define VIRTIO_SND_PCM_R_STOP 5 #define VIRTIO_SND_PCM_R_PAUSE 6 #define VIRTIO_SND_PCM_R_UNPAUSE 7 #define VIRTIO_SND_PCM_R_REWIND 8 #define VIRTIO_SND_PCM_R_FORWARD 9 /* a PCM substream request header */ struct virtio_snd_pcm_hdr { /* VIRTIO_SND_FN_PCM */ le16 function; /* a PCM request type (VIRTIO_SND_PCM_R_XXX) */ le16 request; /* a PCM identifier (assigned in configuration) */ u8 pcm_id; /* a PCM stream type (VIRTIO_SND_PCM_T_XXX) */ u8 stream_type; /* a PCM substream identifier */ u8 substream_id; u8 padding; }; ``` If a PCM request consists only of a generic PCM header, it's referred to as a *generic PCM request*. A PCM response consists of or is preceded by a generic response header. It contains one of the generic or PCM-specific error codes: ``` /* --- PCM ERROR CODES --- */ /* a PCM substream is not ready */ #define VIRTIO_SND_PCM_E_NOT_READY 32 ``` ### Function Configuration The function puts into device configuration a PCM function descriptor followed by up to two PCM stream descriptors. ``` #define VIRTIO_SND_DESC_PCM 0 #define VIRTIO_SND_DESC_PCM_STREAM 1 /* a PCM function descriptor */ struct virtio_snd_pcm_desc { /* sizeof(struct virtio_snd_pcm_desc) */ u8 length; /* VIRTIO_SND_DESC_PCM */ u8 type; /* a PCM function ID (assigned by the device) */ u8 pcm_id; /* # of PCM stream descriptors in the configuration (one per supported PCM stream type) */ u8 nstreams; }; /* supported PCM stream types */ #define VIRTIO_SND_PCM_T_PLAYBACK 0 #define VIRTIO_SND_PCM_T_CAPTURE 1 /* supported PCM stream features */ #define VIRTIO_SND_PCM_FEAT_COMMAND_MODE 0 #define VIRTIO_SND_PCM_FEAT_POLLING_MODE 1 #define VIRTIO_SND_PCM_FEAT_UPDATE_FREQUENCY 2 #define VIRTIO_SND_PCM_FEAT_CHANNEL_MAP 3 #define VIRTIO_SND_PCM_FEATBIT(bit) (1U << VIRTIO_SND_PCM_FEAT_ ## bit) #define VIRTIO_SND_PCM_FEATBIT_COMMAND_MODE \ VIRTIO_SND_PCM_FEATBIT(COMMAND_MODE) #define VIRTIO_SND_PCM_FEATBIT_POLLING_MODE \ VIRTIO_SND_PCM_FEATBIT(POLLING_MODE) #define VIRTIO_SND_PCM_FEATBIT_UPDATE_FREQUENCY \ VIRTIO_SND_PCM_FEATBIT(UPDATE_FREQUENCY) #define VIRTIO_SND_PCM_FEATBIT_CHANNEL_MAP \ VIRTIO_SND_PCM_FEATBIT(CHANNEL_MAP) /* supported PCM sample formats */ #define VIRTIO_SND_PCM_FMT_MU_LAW 0 #define VIRTIO_SND_PCM_FMT_A_LAW 1 #define VIRTIO_SND_PCM_FMT_S8 2 #define VIRTIO_SND_PCM_FMT_U8 3 #define VIRTIO_SND_PCM_FMT_S16_LE 4 #define VIRTIO_SND_PCM_FMT_S16_BE 5 #define VIRTIO_SND_PCM_FMT_U16_LE 6 #define VIRTIO_SND_PCM_FMT_U16_BE 7 #define VIRTIO_SND_PCM_FMT_S24_LE 8 #define VIRTIO_SND_PCM_FMT_S24_BE 9 #define VIRTIO_SND_PCM_FMT_U24_LE 10 #define VIRTIO_SND_PCM_FMT_U24_BE 11 #define VIRTIO_SND_PCM_FMT_S32_LE 12 #define VIRTIO_SND_PCM_FMT_S32_BE 13 #define VIRTIO_SND_PCM_FMT_U32_LE 14 #define VIRTIO_SND_PCM_FMT_U32_BE 15 #define VIRTIO_SND_PCM_FMT_FLOAT_LE 16 #define VIRTIO_SND_PCM_FMT_FLOAT_BE 17 #define VIRTIO_SND_PCM_FMT_FLOAT64_LE 18 #define VIRTIO_SND_PCM_FMT_FLOAT64_BE 19 #define VIRTIO_SND_PCM_FMT_S20_LE 20 #define VIRTIO_SND_PCM_FMT_S20_BE 21 #define VIRTIO_SND_PCM_FMT_U20_LE 22 #define VIRTIO_SND_PCM_FMT_U20_BE 23 #define VIRTIO_SND_PCM_FMT_S24_3LE 24 #define VIRTIO_SND_PCM_FMT_S24_3BE 25 #define VIRTIO_SND_PCM_FMT_U24_3LE 26 #define VIRTIO_SND_PCM_FMT_U24_3BE 27 #define VIRTIO_SND_PCM_FMT_S20_3LE 28 #define VIRTIO_SND_PCM_FMT_S20_3BE 29 #define VIRTIO_SND_PCM_FMT_U20_3LE 30 #define VIRTIO_SND_PCM_FMT_U20_3BE 31 #define VIRTIO_SND_PCM_FMT_S18_3LE 32 #define VIRTIO_SND_PCM_FMT_U18_3LE 33 #define VIRTIO_SND_PCM_FMT_S18_3BE 34 #define VIRTIO_SND_PCM_FMT_U18_3BE 35 #define VIRTIO_SND_PCM_FMTBIT(bit) (1ULL << VIRTIO_SND_PCM_FMT_ ## bit) #define VIRTIO_SND_PCM_FMTBIT_MU_LAW VIRTIO_SND_PCM_FMTBIT(MU_LAW) #define VIRTIO_SND_PCM_FMTBIT_A_LAW VIRTIO_SND_PCM_FMTBIT(A_LAW) #define VIRTIO_SND_PCM_FMTBIT_S8 VIRTIO_SND_PCM_FMTBIT(S8) #define VIRTIO_SND_PCM_FMTBIT_U8 VIRTIO_SND_PCM_FMTBIT(U8) #define VIRTIO_SND_PCM_FMTBIT_S16_LE VIRTIO_SND_PCM_FMTBIT(S16_LE) #define VIRTIO_SND_PCM_FMTBIT_S16_BE VIRTIO_SND_PCM_FMTBIT(S16_BE) #define VIRTIO_SND_PCM_FMTBIT_U16_LE VIRTIO_SND_PCM_FMTBIT(U16_LE) #define VIRTIO_SND_PCM_FMTBIT_U16_BE VIRTIO_SND_PCM_FMTBIT(U16_BE) #define VIRTIO_SND_PCM_FMTBIT_S24_LE VIRTIO_SND_PCM_FMTBIT(S24_LE) #define VIRTIO_SND_PCM_FMTBIT_S24_BE VIRTIO_SND_PCM_FMTBIT(S24_BE) #define VIRTIO_SND_PCM_FMTBIT_U24_LE VIRTIO_SND_PCM_FMTBIT(U24_LE) #define VIRTIO_SND_PCM_FMTBIT_U24_BE VIRTIO_SND_PCM_FMTBIT(U24_BE) #define VIRTIO_SND_PCM_FMTBIT_S32_LE VIRTIO_SND_PCM_FMTBIT(S32_LE) #define VIRTIO_SND_PCM_FMTBIT_S32_BE VIRTIO_SND_PCM_FMTBIT(S32_BE) #define VIRTIO_SND_PCM_FMTBIT_U32_LE VIRTIO_SND_PCM_FMTBIT(U32_LE) #define VIRTIO_SND_PCM_FMTBIT_U32_BE VIRTIO_SND_PCM_FMTBIT(U32_BE) #define VIRTIO_SND_PCM_FMTBIT_FLOAT_LE VIRTIO_SND_PCM_FMTBIT(FLOAT_LE) #define VIRTIO_SND_PCM_FMTBIT_FLOAT_BE VIRTIO_SND_PCM_FMTBIT(FLOAT_BE) #define VIRTIO_SND_PCM_FMTBIT_FLOAT64_LE VIRTIO_SND_PCM_FMTBIT(FLOAT64_LE) #define VIRTIO_SND_PCM_FMTBIT_FLOAT64_BE VIRTIO_SND_PCM_FMTBIT(FLOAT64_BE) #define VIRTIO_SND_PCM_FMTBIT_S20_LE VIRTIO_SND_PCM_FMTBIT(S20_LE) #define VIRTIO_SND_PCM_FMTBIT_S20_BE VIRTIO_SND_PCM_FMTBIT(S20_BE) #define VIRTIO_SND_PCM_FMTBIT_U20_LE VIRTIO_SND_PCM_FMTBIT(U20_LE) #define VIRTIO_SND_PCM_FMTBIT_U20_BE VIRTIO_SND_PCM_FMTBIT(U20_BE) #define VIRTIO_SND_PCM_FMTBIT_S24_3LE VIRTIO_SND_PCM_FMTBIT(S24_3LE) #define VIRTIO_SND_PCM_FMTBIT_S24_3BE VIRTIO_SND_PCM_FMTBIT(S24_3BE) #define VIRTIO_SND_PCM_FMTBIT_U24_3LE VIRTIO_SND_PCM_FMTBIT(U24_3LE) #define VIRTIO_SND_PCM_FMTBIT_U24_3BE VIRTIO_SND_PCM_FMTBIT(U24_3BE) #define VIRTIO_SND_PCM_FMTBIT_S20_3LE VIRTIO_SND_PCM_FMTBIT(S20_3LE) #define VIRTIO_SND_PCM_FMTBIT_S20_3BE VIRTIO_SND_PCM_FMTBIT(S20_3BE) #define VIRTIO_SND_PCM_FMTBIT_U20_3LE VIRTIO_SND_PCM_FMTBIT(U20_3LE) #define VIRTIO_SND_PCM_FMTBIT_U20_3BE VIRTIO_SND_PCM_FMTBIT(U20_3BE) #define VIRTIO_SND_PCM_FMTBIT_S18_3LE VIRTIO_SND_PCM_FMTBIT(S18_3LE) #define VIRTIO_SND_PCM_FMTBIT_S18_3BE VIRTIO_SND_PCM_FMTBIT(S18_3BE) #define VIRTIO_SND_PCM_FMTBIT_U18_3LE VIRTIO_SND_PCM_FMTBIT(U18_3LE) #define VIRTIO_SND_PCM_FMTBIT_U18_3BE VIRTIO_SND_PCM_FMTBIT(U18_3BE) /* supported PCM frame rates */ #define VIRTIO_SND_PCM_RATE_5512 0 #define VIRTIO_SND_PCM_RATE_8000 1 #define VIRTIO_SND_PCM_RATE_11025 2 #define VIRTIO_SND_PCM_RATE_16000 3 #define VIRTIO_SND_PCM_RATE_22050 4 #define VIRTIO_SND_PCM_RATE_32000 5 #define VIRTIO_SND_PCM_RATE_44100 6 #define VIRTIO_SND_PCM_RATE_48000 7 #define VIRTIO_SND_PCM_RATE_64000 8 #define VIRTIO_SND_PCM_RATE_88200 9 #define VIRTIO_SND_PCM_RATE_96000 10 #define VIRTIO_SND_PCM_RATE_176400 11 #define VIRTIO_SND_PCM_RATE_192000 12 #define VIRTIO_SND_PCM_RATEBIT(bit) (1U << VIRTIO_SND_PCM_RATE_ ## bit) #define VIRTIO_SND_PCM_RATEBIT_5512 VIRTIO_SND_PCM_RATEBIT(5512) #define VIRTIO_SND_PCM_RATEBIT_8000 VIRTIO_SND_PCM_RATEBIT(8000) #define VIRTIO_SND_PCM_RATEBIT_11025 VIRTIO_SND_PCM_RATEBIT(11025) #define VIRTIO_SND_PCM_RATEBIT_16000 VIRTIO_SND_PCM_RATEBIT(16000) #define VIRTIO_SND_PCM_RATEBIT_22050 VIRTIO_SND_PCM_RATEBIT(22050) #define VIRTIO_SND_PCM_RATEBIT_32000 VIRTIO_SND_PCM_RATEBIT(32000) #define VIRTIO_SND_PCM_RATEBIT_44100 VIRTIO_SND_PCM_RATEBIT(44100) #define VIRTIO_SND_PCM_RATEBIT_48000 VIRTIO_SND_PCM_RATEBIT(48000) #define VIRTIO_SND_PCM_RATEBIT_64000 VIRTIO_SND_PCM_RATEBIT(64000) #define VIRTIO_SND_PCM_RATEBIT_88200 VIRTIO_SND_PCM_RATEBIT(88200) #define VIRTIO_SND_PCM_RATEBIT_96000 VIRTIO_SND_PCM_RATEBIT(96000) #define VIRTIO_SND_PCM_RATEBIT_176400 VIRTIO_SND_PCM_RATEBIT(176400) #define VIRTIO_SND_PCM_RATEBIT_192000 VIRTIO_SND_PCM_RATEBIT(192000) /* a PCM stream descriptor */ struct virtio_snd_pcm_stream_desc { /* sizeof(struct virtio_snd_pcm_stream_desc) */ u8 length; /* VIRTIO_SND_DESC_PCM_STREAM */ u8 type; /* a PCM stream type (VIRTIO_SND_PCM_T_XXX) */ u8 stream_type; /* # of substreams for the specified stream type */ u8 nsubstreams; /* minimum # of supported channels */ le16 channels_min; /* maximum # of supported channels */ le16 channels_max; /* supported sample formats (VIRTIO_SND_PCM_FMTBIT_XXX, can be ORed) */ le64 formats; /* supported frame rates (VIRTIO_SND_PCM_RATEBIT_XXX, can be ORed) */ le32 rates; /* supported PCM stream features (VIRTIO_SND_PCM_FEATBIT_XXX, can be ORed) */ le16 features; /* # of supported channel maps */ le16 nchmaps; }; ``` ### Function Initialization Upon function initialization, the driver MUST set selected operational mode per each available substream for all available streams. ### Function Operation #### Features The driver sends the VIRTIO_SND_PCM_R_GET_FEATURE/VIRTIO_SND_PCM_R_SET_FEATURE to get/set substream feature-specific value. ``` /* get/set a PCM substream feature */ struct virtio_snd_pcm_feature { /* VIRTIO_SND_FN_PCM */ le16 function; /* VIRTIO_SND_PCM_R_GET_FEATURE / VIRTIO_SND_PCM_R_SET_FEATURE */ le16 request; /* a PCM identifier (assigned in configuration) */ u8 pcm_id; /* a PCM stream type (VIRTIO_SND_PCM_T_XXX) */ u8 stream_type; /* a PCM substream identifier [0 .. virtio_snd_pcm_stream_desc::nsubstreams - 1] */ u8 substream_id; /* a selected PCM substream feature (VIRTIO_SND_PCM_FEAT_XXX) */ u8 feature; /* a feature-specific optional request data */ union { /* VIRTIO_SND_PCM_FEAT_UPDATE_FREQUENCY [SET-only] */ struct { /* an approximate update frequency in microseconds */ le32 microseconds; /* an approximate update frequency in bytes */ le32 bytes; } update_frequency; /* * VIRTIO_SND_PCM_FEAT_MANUAL_MODE [SET-only] * .data = a virtual queue index * VIRTIO_SND_PCM_FEAT_AUTO_MODE [SET-only] * .data = a pseudophysical start address of the virtio_snd_pcm_shmem structure * VIRTIO_SND_PCM_FEAT_CHANNEL_MAP [GET/SET] * GET: * .data = a channel map index [0 .. virtio_snd_pcm_stream_desc::nchmaps - 1] * SET: * .data = a pseudophysical start address of the virtio_snd_pcm_chmap_data structure */ le64 data; }; }; ``` Manual mode (VIRTIO_SND_PCM_FEAT_MANUAL_MODE) If the device supports the manual operating mode, it sets the VIRTIO_SND_PCM_FEATBIT_MANUAL_MODE bit in the features field value in PCM stream configuration descriptor. In manual mode, the driver assigns a dedicated virtual queue for a PCM substream and uses it to transmit data buffers to the device. In the playback mode, upon receiving a data buffer, the device reads next available PCM frames from it. In the capture mode, upon receiving a data buffer, the device writes available PCM frames into it and notifies the driver only when the buffer is full. The driver can move its read/write pointer using the VIRTIO_SND_PCM_R_REWIND or the VIRTIO_SND_PCM_R_FORWARD requests. The driver enables manual mode by setting the VIRTIO_SND_PCM_FEAT_MANUAL_MODE feature for a substream and specifying virtual queue index as a request argument. The device answers with a generic response. Automatic mode (VIRTIO_SND_PCM_FEAT_AUTO_MODE) If the device supports the automatic operating mode, it sets the VIRTIO_SND_PCM_FEATBIT_AUTO_MODE bit in the features field value in PCM stream configuration descriptor. In automatic mode, the driver allocates a pseudophysically continuous memory area consisted of: 1. *Hardware registers*: represents the device runtime state. 2. *Software registers*: represents the driver runtime state. 3. *DMA buffer*: PCM frames storage. ``` /* --- PCM HARDWARE STATE BITMAP --- */ #define VIRTIO_SND_PCM_HW_S_RUNNING 0x0001 #define VIRTIO_SND_PCM_HW_S_PAUSED 0x0002 struct virtio_snd_pcm_hw_regs { /* * Bits | Mnemonic | Description * ------+-----------+------------------------------------------------------ * 0 | RUNNING | 0 = Substream is not running * | | 1 = Substream is running * ------+-----------+------------------------------------------------------ * 1 | PAUSED | 0 = Substream is not paused * | | 1 = Substream is paused * ------+-----------+------------------------------------------------------ * 2:31 | | Reserved, must be zero. */ le32 state; /* additional hardware latency: unsigned value in bytes */ le32 latency; /* current hardware position: unsigned value in bytes [0 .. dma_size - 1] */ le32 dma_position; }; struct virtio_snd_pcm_sw_regs { /* current DMA buffer size in bytes */ le32 dma_size; }; /* a PCM substream shared memory structure */ struct virtio_snd_pcm_shmem { /* * automatic mode hardware registers * device: writable * driver: read-only */ struct virtio_snd_pcm_hw_regs hwrs; /* * automatic mode software registers * device: read-only * driver: writable */ struct virtio_snd_pcm_sw_regs swrs; /* * followed by a variable sized DMA buffer * in the playback mode: * device: read-only * driver: writable * in the capture mode: * device: writable * driver: read-only */ }; ``` The driver enables automatic mode by setting the VIRTIO_SND_PCM_FEAT_AUTO_MODE feature for a substream and specifying a pseudophysical start address of the virtio_snd_pcm_shmem structure as a request argument. The device answers with a generic response. The driver MUST allocates DMA buffer of maximum possible size and set the dma_size field value to this size while sending the VIRTIO_SND_PCM_R_SET_FEATURE request. Depending on selected PCM format, the actual buffer size can be less or equal to maximum possible one. In case of the playback stream, the device reads constant amount of PCM frames with constant time intervals without any requests from the driver. In case of the capture stream, the device writes constant amount of PCM frames with constant time intervals without any notifications to the driver. Update frequency (VIRTIO_SND_PCM_FEAT_UPDATE_FREQUENCY) If the device requires specifying an approximate data buffer update frequency, it sets the VIRTIO_SND_PCM_FEATBIT_UPDATE_FREQUENCY bit in the features field value in PCM stream configuration descriptor. In such case, the driver MUST set the VIRTIO_SND_PCM_FEAT_UPDATE_FREQUENCY feature and specify an approximate update frequency (expressed in both microseconds and bytes units) as a request argument before starting a PCM substream. The device answers with a generic response. Channel map (VIRTIO_SND_PCM_FEAT_CHANNEL_MAP) If the device provides an ability to get supported channel maps, it sets the VIRTIO_SND_PCM_FEATBIT_CHANNEL_MAP bit in the features field value and specifies an amount of supported channel maps in the nchmaps field in PCM stream configuration descriptor. The driver gets the VIRTIO_SND_PCM_FEAT_CHANNEL_MAP feature value in order to obtain a channel map with specified index, the device answers with the virtio_snd_pcm_chmap PCM response. If channel map type allows to swap channels, the driver can set the VIRTIO_SND_PCM_FEAT_CHANNEL_MAP feature value specifying selected channel map data as a request argument. The device answers with a generic response. ``` /* a PCM channel map definitions */ /* All channels have fixed channel positions */ #define VIRTIO_SND_PCM_CHMAP_FIXED 0 /* All channels are swappable (e.g. {FL/FR/RL/RR} -> {RR/RL/FR/FL}) */ #define VIRTIO_SND_PCM_CHMAP_VARIABLE 1 /* Only pair-wise channels are swappable (e.g. {FL/FR/RL/RR} -> {RL/RR/FL/FR}) */ #define VIRTIO_SND_PCM_CHMAP_PAIRED 2 /* Standard channel position definition */ #define VIRTIO_SND_PCM_CH_NONE 0 /* undefined */ #define VIRTIO_SND_PCM_CH_NA 1 /* silent */ #define VIRTIO_SND_PCM_CH_MONO 2 /* mono stream */ #define VIRTIO_SND_PCM_CH_FL 3 /* front left */ #define VIRTIO_SND_PCM_CH_FR 4 /* front right */ #define VIRTIO_SND_PCM_CH_RL 5 /* rear left */ #define VIRTIO_SND_PCM_CH_RR 6 /* rear right */ #define VIRTIO_SND_PCM_CH_FC 7 /* front center */ #define VIRTIO_SND_PCM_CH_LFE 8 /* low frequency (LFE) */ #define VIRTIO_SND_PCM_CH_SL 9 /* side left */ #define VIRTIO_SND_PCM_CH_SR 10 /* side right */ #define VIRTIO_SND_PCM_CH_RC 11 /* rear center */ #define VIRTIO_SND_PCM_CH_FLC 12 /* front left center */ #define VIRTIO_SND_PCM_CH_FRC 13 /* front right center */ #define VIRTIO_SND_PCM_CH_RLC 14 /* rear left center */ #define VIRTIO_SND_PCM_CH_RRC 15 /* rear right center */ #define VIRTIO_SND_PCM_CH_FLW 16 /* front left wide */ #define VIRTIO_SND_PCM_CH_FRW 17 /* front right wide */ #define VIRTIO_SND_PCM_CH_FLH 18 /* front left high */ #define VIRTIO_SND_PCM_CH_FCH 19 /* front center high */ #define VIRTIO_SND_PCM_CH_FRH 20 /* front right high */ #define VIRTIO_SND_PCM_CH_TC 21 /* top center */ #define VIRTIO_SND_PCM_CH_TFL 22 /* top front left */ #define VIRTIO_SND_PCM_CH_TFR 23 /* top front right */ #define VIRTIO_SND_PCM_CH_TFC 24 /* top front center */ #define VIRTIO_SND_PCM_CH_TRL 25 /* top rear left */ #define VIRTIO_SND_PCM_CH_TRR 26 /* top rear right */ #define VIRTIO_SND_PCM_CH_TRC 27 /* top rear center */ #define VIRTIO_SND_PCM_CH_TFLC 28 /* top front left center */ #define VIRTIO_SND_PCM_CH_TFRC 29 /* top front right center */ #define VIRTIO_SND_PCM_CH_TSL 30 /* top side left */ #define VIRTIO_SND_PCM_CH_TSR 31 /* top side right */ #define VIRTIO_SND_PCM_CH_LLFE 32 /* left LFE */ #define VIRTIO_SND_PCM_CH_RLFE 33 /* right LFE */ #define VIRTIO_SND_PCM_CH_BC 34 /* bottom center */ #define VIRTIO_SND_PCM_CH_BLC 35 /* bottom left center */ #define VIRTIO_SND_PCM_CH_BRC 36 /* bottom right center */ /* * The channel is phase inverted (thus summing left and right channels would * result in almost silence). */ #define VIRTIO_SND_PCM_CH_F_PHASE_INVERSE 0x01 #define VIRTIO_SND_PCM_CH_MAX 256 /* a PCM channel information */ struct virtio_snd_pcm_chinfo { /* a PCM channel position (VIRTIO_SND_PCM_CH_XXX) */ u8 position; /* a PCM channel flags (VIRTIO_SND_PCM_CH_F_XXX, can be ORed) */ u8 flags; }; /* a PCM channel map data */ struct virtio_snd_pcm_chmap_data { /* # of valid entries in the PCM channel map */ le32 nchannels; /* a PCM channel map */ struct virtio_snd_pcm_chinfo channel_map[VIRTIO_SND_PCM_CH_MAX]; }; /* a response containing PCM channel map */ struct virtio_snd_pcm_chmap { struct virtio_snd_rsp hdr; /* a channel map type (VIRTIO_SND_PCM_CHMAP_XXX) */ u8 type; /* reserved, must be zero */ u8 reserved[3]; /* a channel map data */ struct virtio_snd_pcm_chmap_data data; }; ``` #### Set Format The driver MUST send the VIRTIO_SND_PCM_R_SET_FORMAT request containing selected PCM stream parameters, the device answers with a generic response. ``` /* set a PCM substream format */ struct virtio_snd_pcm_set_format { /* .request = VIRTIO_SND_PCM_R_SET_FORMAT */ struct virtio_snd_pcm_hdr hdr; /* # of channels */ le16 channels; /* a PCM sample format (VIRTIO_SND_PCM_FMT_XXX) */ le16 format; /* a PCM frame rate (VIRTIO_SND_PCM_RATE_XXX) */ le16 rate; u16 padding; }; ``` #### Prepare The driver MUST send the VIRTIO_SND_PCM_R_PREPARE generic PCM request to prepare a substream for running, the device answers with a generic response. #### Start The driver sends the VIRTIO_SND_PCM_R_START generic PCM request, the device answers with a generic response. In automatic mode: - on success, the VIRTIO_SND_PCM_HW_S_RUNNING substream state bit MUST be set, - the device MUST start to read/write PCM frames from/to shared DMA buffer. #### Stop The driver sends the VIRTIO_SND_PCM_R_STOP generic PCM request, the device answers with a generic response. In manual mode: - the device MUST release all provided buffers by setting result length to zero and notifying the driver. In automatic mode: - the VIRTIO_SND_PCM_HW_S_RUNNING substream state bit MUST be cleared, - the device MUST stop to read/write PCM frames from/to shared DMA buffer. #### Pause The driver sends the VIRTIO_SND_PCM_R_PAUSE generic PCM request, the device answers with a generic response. In automatic mode: - on success, the VIRTIO_SND_PCM_HW_S_PAUSED substream state bit MUST be set. #### Unpause The driver sends the VIRTIO_SND_PCM_R_UNPAUSE generic PCM request, the device answers with a generic response. In automatic mode: - the VIRTIO_SND_PCM_HW_S_PAUSED substream state bit MUST be cleared. #### Rewind/Forward [Available only in manual mode] The driver sends the VIRTIO_SND_PCM_R_REWIND or the VIRTIO_SND_PCM_R_FORWARD request containing seek count, the device answers with a generic response. ``` /* seek (rewind/forward) a PCM substream read/write position */ struct virtio_snd_pcm_seek { /* .request = VIRTIO_SND_PCM_R_REWIND / VIRTIO_SND_PCM_R_FORWARD */ struct virtio_snd_pcm_hdr hdr; /* seek count: unsigned value in bytes */ le32 count; u32 padding; }; ``` --------------27E016126600CA6DDCC71654 Content-Type: text/x-chdr; name="virtio_snd.h" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="virtio_snd.h" /* * Copyright (C) 2019 OpenSynergy GmbH * * This header is BSD licensed so anyone can use the definitions to * implement compatible drivers/servers. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * 3. Neither the name of OpenSynergy GmbH nor the names of its contributors * may be used to endorse or promote products derived from this software * without specific prior written permission. * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS * ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS * FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL IBM OR * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. */ #ifndef VIRTIO_SND_IF_H #define VIRTIO_SND_IF_H #include /******************************************************************************* * COMMON DEFINITIONS */ /* a configuration space */ struct virtio_snd_config { /* maximum # of available virtual queues */ __virtio32 nqueues; }; /* --- GENERIC ERROR CODES --- */ /* no errors */ #define VIRTIO_SND_E_SUCCESS 0 /* an undefined error */ #define VIRTIO_SND_E_GENERAL 1 /* not supported input parameter(s) */ #define VIRTIO_SND_E_NOTSUPPORTED 2 /* invalid input parameter(s) */ #define VIRTIO_SND_E_INVALID 3 /* I/O error */ #define VIRTIO_SND_E_IO 4 /* a generic request header */ struct virtio_snd_req { __virtio16 function; __virtio16 request; }; /* a generic response header */ struct virtio_snd_rsp { __virtio32 status; /* VIRTIO_SND_E_XXX */ }; /* supported function types */ #define VIRTIO_SND_FN_BASE 0 #define VIRTIO_SND_FN_PCM 1 /* supported descriptor types */ #define VIRTIO_SND_DESC_PCM 0 #define VIRTIO_SND_DESC_PCM_STREAM 1 /* a generic descriptor */ struct virtio_snd_generic_desc { __u8 length; __u8 type; __u16 padding; }; /******************************************************************************* * BASE FUNCTION DEFINITIONS */ /* --- BASE REQUEST TYPES --- */ #define VIRTIO_SND_BASE_R_GET_CFG 0 #define VIRTIO_SND_BASE_R_SUSPEND 1 #define VIRTIO_SND_BASE_R_RESUME 2 /* a maximum possible configuration data size (in bytes) */ #define VIRTIO_SND_BASE_CFG_MAX_SIZE 1024 /* a response containing device configuration */ struct virtio_snd_base_configuration { struct virtio_snd_rsp hdr; /* size in bytes of configuration data */ __virtio32 length; /* configuration data */ __u8 data[VIRTIO_SND_BASE_CFG_MAX_SIZE]; }; /******************************************************************************* * PCM FUNCTION DEFINITIONS */ /* supported PCM stream types */ #define VIRTIO_SND_PCM_T_PLAYBACK 0 #define VIRTIO_SND_PCM_T_CAPTURE 1 /* supported PCM stream features */ #define VIRTIO_SND_PCM_FEAT_MANUAL_MODE 0 #define VIRTIO_SND_PCM_FEAT_AUTO_MODE 1 #define VIRTIO_SND_PCM_FEAT_UPDATE_FREQUENCY 2 #define VIRTIO_SND_PCM_FEAT_CHANNEL_MAP 3 #define VIRTIO_SND_PCM_FEATBIT(bit) (1U << VIRTIO_SND_PCM_FEAT_ ## bit) #define VIRTIO_SND_PCM_FEATBIT_MANUAL_MODE \ VIRTIO_SND_PCM_FEATBIT(MANUAL_MODE) #define VIRTIO_SND_PCM_FEATBIT_AUTO_MODE \ VIRTIO_SND_PCM_FEATBIT(AUTO_MODE) #define VIRTIO_SND_PCM_FEATBIT_UPDATE_FREQUENCY \ VIRTIO_SND_PCM_FEATBIT(UPDATE_FREQUENCY) #define VIRTIO_SND_PCM_FEATBIT_CHANNEL_MAP \ VIRTIO_SND_PCM_FEATBIT(CHANNEL_MAP) /* supported PCM sample formats */ #define VIRTIO_SND_PCM_FMT_MU_LAW 0 #define VIRTIO_SND_PCM_FMT_A_LAW 1 #define VIRTIO_SND_PCM_FMT_S8 2 #define VIRTIO_SND_PCM_FMT_U8 3 #define VIRTIO_SND_PCM_FMT_S16_LE 4 #define VIRTIO_SND_PCM_FMT_S16_BE 5 #define VIRTIO_SND_PCM_FMT_U16_LE 6 #define VIRTIO_SND_PCM_FMT_U16_BE 7 #define VIRTIO_SND_PCM_FMT_S24_LE 8 #define VIRTIO_SND_PCM_FMT_S24_BE 9 #define VIRTIO_SND_PCM_FMT_U24_LE 10 #define VIRTIO_SND_PCM_FMT_U24_BE 11 #define VIRTIO_SND_PCM_FMT_S32_LE 12 #define VIRTIO_SND_PCM_FMT_S32_BE 13 #define VIRTIO_SND_PCM_FMT_U32_LE 14 #define VIRTIO_SND_PCM_FMT_U32_BE 15 #define VIRTIO_SND_PCM_FMT_FLOAT_LE 16 #define VIRTIO_SND_PCM_FMT_FLOAT_BE 17 #define VIRTIO_SND_PCM_FMT_FLOAT64_LE 18 #define VIRTIO_SND_PCM_FMT_FLOAT64_BE 19 #define VIRTIO_SND_PCM_FMT_S20_LE 20 #define VIRTIO_SND_PCM_FMT_S20_BE 21 #define VIRTIO_SND_PCM_FMT_U20_LE 22 #define VIRTIO_SND_PCM_FMT_U20_BE 23 #define VIRTIO_SND_PCM_FMT_S24_3LE 24 #define VIRTIO_SND_PCM_FMT_S24_3BE 25 #define VIRTIO_SND_PCM_FMT_U24_3LE 26 #define VIRTIO_SND_PCM_FMT_U24_3BE 27 #define VIRTIO_SND_PCM_FMT_S20_3LE 28 #define VIRTIO_SND_PCM_FMT_S20_3BE 29 #define VIRTIO_SND_PCM_FMT_U20_3LE 30 #define VIRTIO_SND_PCM_FMT_U20_3BE 31 #define VIRTIO_SND_PCM_FMT_S18_3LE 32 #define VIRTIO_SND_PCM_FMT_U18_3LE 33 #define VIRTIO_SND_PCM_FMT_S18_3BE 34 #define VIRTIO_SND_PCM_FMT_U18_3BE 35 #define VIRTIO_SND_PCM_FMTBIT(bit) (1ULL << VIRTIO_SND_PCM_FMT_ ## bit) #define VIRTIO_SND_PCM_FMTBIT_MU_LAW VIRTIO_SND_PCM_FMTBIT(MU_LAW) #define VIRTIO_SND_PCM_FMTBIT_A_LAW VIRTIO_SND_PCM_FMTBIT(A_LAW) #define VIRTIO_SND_PCM_FMTBIT_S8 VIRTIO_SND_PCM_FMTBIT(S8) #define VIRTIO_SND_PCM_FMTBIT_U8 VIRTIO_SND_PCM_FMTBIT(U8) #define VIRTIO_SND_PCM_FMTBIT_S16_LE VIRTIO_SND_PCM_FMTBIT(S16_LE) #define VIRTIO_SND_PCM_FMTBIT_S16_BE VIRTIO_SND_PCM_FMTBIT(S16_BE) #define VIRTIO_SND_PCM_FMTBIT_U16_LE VIRTIO_SND_PCM_FMTBIT(U16_LE) #define VIRTIO_SND_PCM_FMTBIT_U16_BE VIRTIO_SND_PCM_FMTBIT(U16_BE) #define VIRTIO_SND_PCM_FMTBIT_S24_LE VIRTIO_SND_PCM_FMTBIT(S24_LE) #define VIRTIO_SND_PCM_FMTBIT_S24_BE VIRTIO_SND_PCM_FMTBIT(S24_BE) #define VIRTIO_SND_PCM_FMTBIT_U24_LE VIRTIO_SND_PCM_FMTBIT(U24_LE) #define VIRTIO_SND_PCM_FMTBIT_U24_BE VIRTIO_SND_PCM_FMTBIT(U24_BE) #define VIRTIO_SND_PCM_FMTBIT_S32_LE VIRTIO_SND_PCM_FMTBIT(S32_LE) #define VIRTIO_SND_PCM_FMTBIT_S32_BE VIRTIO_SND_PCM_FMTBIT(S32_BE) #define VIRTIO_SND_PCM_FMTBIT_U32_LE VIRTIO_SND_PCM_FMTBIT(U32_LE) #define VIRTIO_SND_PCM_FMTBIT_U32_BE VIRTIO_SND_PCM_FMTBIT(U32_BE) #define VIRTIO_SND_PCM_FMTBIT_FLOAT_LE VIRTIO_SND_PCM_FMTBIT(FLOAT_LE) #define VIRTIO_SND_PCM_FMTBIT_FLOAT_BE VIRTIO_SND_PCM_FMTBIT(FLOAT_BE) #define VIRTIO_SND_PCM_FMTBIT_FLOAT64_LE VIRTIO_SND_PCM_FMTBIT(FLOAT64_LE) #define VIRTIO_SND_PCM_FMTBIT_FLOAT64_BE VIRTIO_SND_PCM_FMTBIT(FLOAT64_BE) #define VIRTIO_SND_PCM_FMTBIT_S20_LE VIRTIO_SND_PCM_FMTBIT(S20_LE) #define VIRTIO_SND_PCM_FMTBIT_S20_BE VIRTIO_SND_PCM_FMTBIT(S20_BE) #define VIRTIO_SND_PCM_FMTBIT_U20_LE VIRTIO_SND_PCM_FMTBIT(U20_LE) #define VIRTIO_SND_PCM_FMTBIT_U20_BE VIRTIO_SND_PCM_FMTBIT(U20_BE) #define VIRTIO_SND_PCM_FMTBIT_S24_3LE VIRTIO_SND_PCM_FMTBIT(S24_3LE) #define VIRTIO_SND_PCM_FMTBIT_S24_3BE VIRTIO_SND_PCM_FMTBIT(S24_3BE) #define VIRTIO_SND_PCM_FMTBIT_U24_3LE VIRTIO_SND_PCM_FMTBIT(U24_3LE) #define VIRTIO_SND_PCM_FMTBIT_U24_3BE VIRTIO_SND_PCM_FMTBIT(U24_3BE) #define VIRTIO_SND_PCM_FMTBIT_S20_3LE VIRTIO_SND_PCM_FMTBIT(S20_3LE) #define VIRTIO_SND_PCM_FMTBIT_S20_3BE VIRTIO_SND_PCM_FMTBIT(S20_3BE) #define VIRTIO_SND_PCM_FMTBIT_U20_3LE VIRTIO_SND_PCM_FMTBIT(U20_3LE) #define VIRTIO_SND_PCM_FMTBIT_U20_3BE VIRTIO_SND_PCM_FMTBIT(U20_3BE) #define VIRTIO_SND_PCM_FMTBIT_S18_3LE VIRTIO_SND_PCM_FMTBIT(S18_3LE) #define VIRTIO_SND_PCM_FMTBIT_S18_3BE VIRTIO_SND_PCM_FMTBIT(S18_3BE) #define VIRTIO_SND_PCM_FMTBIT_U18_3LE VIRTIO_SND_PCM_FMTBIT(U18_3LE) #define VIRTIO_SND_PCM_FMTBIT_U18_3BE VIRTIO_SND_PCM_FMTBIT(U18_3BE) /* supported PCM frame rates */ #define VIRTIO_SND_PCM_RATE_5512 0 #define VIRTIO_SND_PCM_RATE_8000 1 #define VIRTIO_SND_PCM_RATE_11025 2 #define VIRTIO_SND_PCM_RATE_16000 3 #define VIRTIO_SND_PCM_RATE_22050 4 #define VIRTIO_SND_PCM_RATE_32000 5 #define VIRTIO_SND_PCM_RATE_44100 6 #define VIRTIO_SND_PCM_RATE_48000 7 #define VIRTIO_SND_PCM_RATE_64000 8 #define VIRTIO_SND_PCM_RATE_88200 9 #define VIRTIO_SND_PCM_RATE_96000 10 #define VIRTIO_SND_PCM_RATE_176400 11 #define VIRTIO_SND_PCM_RATE_192000 12 #define VIRTIO_SND_PCM_RATEBIT(bit) (1U << VIRTIO_SND_PCM_RATE_ ## bit) #define VIRTIO_SND_PCM_RATEBIT_5512 VIRTIO_SND_PCM_RATEBIT(5512) #define VIRTIO_SND_PCM_RATEBIT_8000 VIRTIO_SND_PCM_RATEBIT(8000) #define VIRTIO_SND_PCM_RATEBIT_11025 VIRTIO_SND_PCM_RATEBIT(11025) #define VIRTIO_SND_PCM_RATEBIT_16000 VIRTIO_SND_PCM_RATEBIT(16000) #define VIRTIO_SND_PCM_RATEBIT_22050 VIRTIO_SND_PCM_RATEBIT(22050) #define VIRTIO_SND_PCM_RATEBIT_32000 VIRTIO_SND_PCM_RATEBIT(32000) #define VIRTIO_SND_PCM_RATEBIT_44100 VIRTIO_SND_PCM_RATEBIT(44100) #define VIRTIO_SND_PCM_RATEBIT_48000 VIRTIO_SND_PCM_RATEBIT(48000) #define VIRTIO_SND_PCM_RATEBIT_64000 VIRTIO_SND_PCM_RATEBIT(64000) #define VIRTIO_SND_PCM_RATEBIT_88200 VIRTIO_SND_PCM_RATEBIT(88200) #define VIRTIO_SND_PCM_RATEBIT_96000 VIRTIO_SND_PCM_RATEBIT(96000) #define VIRTIO_SND_PCM_RATEBIT_176400 VIRTIO_SND_PCM_RATEBIT(176400) #define VIRTIO_SND_PCM_RATEBIT_192000 VIRTIO_SND_PCM_RATEBIT(192000) /* a PCM channel map definitions */ /* All channels have fixed channel positions */ #define VIRTIO_SND_PCM_CHMAP_FIXED 0 /* All channels are swappable (e.g. {FL/FR/RL/RR} -> {RR/RL/FR/FL}) */ #define VIRTIO_SND_PCM_CHMAP_VARIABLE 1 /* Only pair-wise channels are swappable (e.g. {FL/FR/RL/RR} -> {RL/RR/FL/FR}) */ #define VIRTIO_SND_PCM_CHMAP_PAIRED 2 /* Standard channel position definition */ #define VIRTIO_SND_PCM_CH_NONE 0 /* undefined */ #define VIRTIO_SND_PCM_CH_NA 1 /* silent */ #define VIRTIO_SND_PCM_CH_MONO 2 /* mono stream */ #define VIRTIO_SND_PCM_CH_FL 3 /* front left */ #define VIRTIO_SND_PCM_CH_FR 4 /* front right */ #define VIRTIO_SND_PCM_CH_RL 5 /* rear left */ #define VIRTIO_SND_PCM_CH_RR 6 /* rear right */ #define VIRTIO_SND_PCM_CH_FC 7 /* front center */ #define VIRTIO_SND_PCM_CH_LFE 8 /* low frequency (LFE) */ #define VIRTIO_SND_PCM_CH_SL 9 /* side left */ #define VIRTIO_SND_PCM_CH_SR 10 /* side right */ #define VIRTIO_SND_PCM_CH_RC 11 /* rear center */ #define VIRTIO_SND_PCM_CH_FLC 12 /* front left center */ #define VIRTIO_SND_PCM_CH_FRC 13 /* front right center */ #define VIRTIO_SND_PCM_CH_RLC 14 /* rear left center */ #define VIRTIO_SND_PCM_CH_RRC 15 /* rear right center */ #define VIRTIO_SND_PCM_CH_FLW 16 /* front left wide */ #define VIRTIO_SND_PCM_CH_FRW 17 /* front right wide */ #define VIRTIO_SND_PCM_CH_FLH 18 /* front left high */ #define VIRTIO_SND_PCM_CH_FCH 19 /* front center high */ #define VIRTIO_SND_PCM_CH_FRH 20 /* front right high */ #define VIRTIO_SND_PCM_CH_TC 21 /* top center */ #define VIRTIO_SND_PCM_CH_TFL 22 /* top front left */ #define VIRTIO_SND_PCM_CH_TFR 23 /* top front right */ #define VIRTIO_SND_PCM_CH_TFC 24 /* top front center */ #define VIRTIO_SND_PCM_CH_TRL 25 /* top rear left */ #define VIRTIO_SND_PCM_CH_TRR 26 /* top rear right */ #define VIRTIO_SND_PCM_CH_TRC 27 /* top rear center */ #define VIRTIO_SND_PCM_CH_TFLC 28 /* top front left center */ #define VIRTIO_SND_PCM_CH_TFRC 29 /* top front right center */ #define VIRTIO_SND_PCM_CH_TSL 30 /* top side left */ #define VIRTIO_SND_PCM_CH_TSR 31 /* top side right */ #define VIRTIO_SND_PCM_CH_LLFE 32 /* left LFE */ #define VIRTIO_SND_PCM_CH_RLFE 33 /* right LFE */ #define VIRTIO_SND_PCM_CH_BC 34 /* bottom center */ #define VIRTIO_SND_PCM_CH_BLC 35 /* bottom left center */ #define VIRTIO_SND_PCM_CH_BRC 36 /* bottom right center */ /* * The channel is phase inverted (thus summing left and right channels would * result in almost silence). */ #define VIRTIO_SND_PCM_CH_F_PHASE_INVERSE 0x01 /* a PCM function descriptor */ struct virtio_snd_pcm_desc { /* sizeof(struct virtio_snd_pcm_desc) */ __u8 length; /* VIRTIO_SND_DESC_PCM */ __u8 type; /* a PCM function ID (assigned by the device) */ __u8 pcm_id; /* # of PCM stream descriptors in the configuration (one per supported PCM stream type) */ __u8 nstreams; }; /* a PCM stream descriptor */ struct virtio_snd_pcm_stream_desc { /* sizeof(struct virtio_snd_pcm_stream_desc) */ __u8 length; /* VIRTIO_SND_DESC_PCM_STREAM */ __u8 type; /* a PCM stream type (VIRTIO_SND_PCM_T_XXX) */ __u8 stream_type; /* # of substreams for the specified stream type */ __u8 nsubstreams; /* minimum # of supported channels */ __virtio16 channels_min; /* maximum # of supported channels */ __virtio16 channels_max; /* supported sample formats (VIRTIO_SND_PCM_FMTBIT_XXX, can be ORed) */ __virtio64 formats; /* supported frame rates (VIRTIO_SND_PCM_RATEBIT_XXX, can be ORed) */ __virtio32 rates; /* supported PCM stream features (VIRTIO_SND_PCM_FEATBIT_XXX, can be ORed) */ __virtio16 features; /* # of supported channel maps */ __virtio16 nchmaps; }; /* --- PCM HARDWARE STATE BITMAP --- */ #define VIRTIO_SND_PCM_HW_S_RUNNING 0x0001 #define VIRTIO_SND_PCM_HW_S_PAUSED 0x0002 struct virtio_snd_pcm_hw_regs { /* * Bits | Mnemonic | Description * ------+-----------+------------------------------------------------------ * 0 | RUNNING | 0 = Substream is not running * | | 1 = Substream is running * ------+-----------+------------------------------------------------------ * 1 | PAUSED | 0 = Substream is not paused * | | 1 = Substream is paused * ------+-----------+------------------------------------------------------ * 2:31 | | Reserved, must be zero. */ __virtio32 state; /* additional hardware latency: unsigned value in bytes */ __virtio32 latency; /* current hardware position: unsigned value in bytes [0 .. dma_size - 1] */ __virtio32 dma_position; }; struct virtio_snd_pcm_sw_regs { /* current DMA buffer size in bytes */ __virtio32 dma_size; }; /* a PCM substream shared memory structure */ struct virtio_snd_pcm_shmem { /* * automatic mode hardware registers * device: writable * driver: read-only */ struct virtio_snd_pcm_hw_regs hwrs; /* * automatic mode software registers * device: read-only * driver: writable */ struct virtio_snd_pcm_sw_regs swrs; /* * followed by a variable sized DMA buffer * in the playback mode: * device: read-only * driver: writable * in the capture mode: * device: writable * driver: read-only */ }; /* --- PCM REQUEST TYPES --- */ #define VIRTIO_SND_PCM_R_GET_FEATURE 0 #define VIRTIO_SND_PCM_R_SET_FEATURE 1 #define VIRTIO_SND_PCM_R_SET_FORMAT 2 #define VIRTIO_SND_PCM_R_PREPARE 3 #define VIRTIO_SND_PCM_R_START 4 #define VIRTIO_SND_PCM_R_STOP 5 #define VIRTIO_SND_PCM_R_PAUSE 6 #define VIRTIO_SND_PCM_R_UNPAUSE 7 #define VIRTIO_SND_PCM_R_REWIND 8 #define VIRTIO_SND_PCM_R_FORWARD 9 /* --- PCM ERROR CODES --- */ #define VIRTIO_SND_PCM_E_NOT_READY 32 /* a PCM substream request header */ struct virtio_snd_pcm_hdr { /* VIRTIO_SND_FN_PCM */ __virtio16 function; /* a PCM request type (VIRTIO_SND_PCM_R_XXX) */ __virtio16 request; /* a PCM identifier (assigned in configuration) */ __u8 pcm_id; /* a PCM stream type (VIRTIO_SND_PCM_T_XXX) */ __u8 stream_type; /* a PCM substream identifier [0 .. virtio_snd_pcm_stream_desc::nsubstreams - 1] */ __u8 substream_id; __u8 padding; }; /* get/set a PCM substream feature */ struct virtio_snd_pcm_feature { /* VIRTIO_SND_FN_PCM */ __virtio16 function; /* VIRTIO_SND_PCM_R_GET_FEATURE / VIRTIO_SND_PCM_R_SET_FEATURE */ __virtio16 request; /* a PCM identifier (assigned in configuration) */ __u8 pcm_id; /* a PCM stream type (VIRTIO_SND_PCM_T_XXX) */ __u8 stream_type; /* a PCM substream identifier [0 .. virtio_snd_pcm_stream_desc::nsubstreams - 1] */ __u8 substream_id; /* a selected PCM substream feature (VIRTIO_SND_PCM_FEAT_XXX) */ __u8 feature; /* a feature-specific optional request data */ union { /* VIRTIO_SND_PCM_FEAT_UPDATE_FREQUENCY [SET-only] */ struct { /* an approximate update frequency in microseconds */ __virtio32 microseconds; /* an approximate update frequency in bytes */ __virtio32 bytes; } update_frequency; /* * VIRTIO_SND_PCM_FEAT_MANUAL_MODE [SET-only] * .data = a virtual queue index * VIRTIO_SND_PCM_FEAT_AUTO_MODE [SET-only] * .data = a pseudophysical start address of the virtio_snd_pcm_shmem structure * VIRTIO_SND_PCM_FEAT_CHANNEL_MAP [GET/SET] * GET: * .data = a channel map index [0 .. virtio_snd_pcm_stream_desc::nchmaps - 1] * SET: * .data = a pseudophysical start address of the virtio_snd_pcm_chmap_data structure */ __virtio64 data; }; }; #define VIRTIO_SND_PCM_CH_MAX 256 /* a PCM channel information */ struct virtio_snd_pcm_chinfo { /* a PCM channel position (VIRTIO_SND_PCM_CH_XXX) */ __u8 position; /* a PCM channel flags (VIRTIO_SND_PCM_CH_F_XXX, can be ORed) */ __u8 flags; }; /* a PCM channel map data */ struct virtio_snd_pcm_chmap_data { /* # of valid entries in the PCM channel map */ __virtio32 nchannels; /* a PCM channel map */ struct virtio_snd_pcm_chinfo channel_map[VIRTIO_SND_PCM_CH_MAX]; }; /* a response containing PCM channel map */ struct virtio_snd_pcm_chmap { struct virtio_snd_rsp hdr; /* a channel map type (VIRTIO_SND_PCM_CHMAP_XXX) */ __u8 type; /* reserved, must be zero */ __u8 reserved[3]; /* a channel map data */ struct virtio_snd_pcm_chmap_data data; }; /* set a PCM substream format */ struct virtio_snd_pcm_set_format { /* .request = VIRTIO_SND_PCM_R_SET_FORMAT */ struct virtio_snd_pcm_hdr hdr; /* # of channels */ __virtio16 channels; /* a PCM sample format (VIRTIO_SND_PCM_FMT_XXX) */ __virtio16 format; /* a PCM frame rate (VIRTIO_SND_PCM_RATE_XXX) */ __virtio16 rate; __u16 padding; }; /* seek (rewind/forward) a PCM substream read/write position */ struct virtio_snd_pcm_seek { /* .request = VIRTIO_SND_PCM_R_REWIND / VIRTIO_SND_PCM_R_FORWARD */ struct virtio_snd_pcm_hdr hdr; /* seek count: unsigned value in bytes */ __virtio32 count; __u32 padding; }; #endif /* VIRTIO_SND_IF_H */ --------------27E016126600CA6DDCC71654 Content-Type: text/plain; charset=us-ascii --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org --------------27E016126600CA6DDCC71654-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: virtio-dev-return-5727-cohuck=redhat.com@lists.oasis-open.org Sender: List-Post: List-Help: List-Unsubscribe: List-Subscribe: Received: from lists.oasis-open.org (oasis.ws5.connectedcommunity.org [10.110.1.242]) by lists.oasis-open.org (Postfix) with ESMTP id 514F3985DFA for ; Fri, 10 May 2019 12:17:02 +0000 (UTC) Date: Fri, 10 May 2019 14:16:56 +0200 From: Gerd Hoffmann Message-ID: <20190510121656.3ab7w5xef6io764o@sirius.home.kraxel.org> References: <20190429134754.GI7587@stefanha-x1.localdomain> <4fcd7456-de22-7f6d-d5ef-939cd3d7cf95@13byte.com> <20190501170525.GB22391@stefanha-x1.localdomain> <20190503164501.GB8373@stefanha-x1.localdomain> <863e1be1-11cc-816b-896d-3954427e98f3@13byte.com> <20190506052715.vkdopunuauyhl22m@sirius.home.kraxel.org> <7ac2ae97-bcb7-22cc-272a-723e7209910c@13byte.com> <20190509122710.rfhfnhqez2u7inju@sirius.home.kraxel.org> <5d316321-2c48-342b-f2ce-359e3596dae0@opensynergy.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5d316321-2c48-342b-f2ce-359e3596dae0@opensynergy.com> Subject: Re: [virtio-dev] Request for a new device number for a virtio-audio device. To: Mikhail Golubev Cc: Marco Martinelli - 13Byte srl , virtio-dev@lists.oasis-open.org, Stefan Hajnoczi , =?utf-8?B?S8WRdsOhZ8OzIFpvbHTDoW4=?= List-ID: On Fri, May 10, 2019 at 11:45:24AM +0200, Mikhail Golubev wrote: > Hi all! > > Sorry for breaking in the middle of the virtio audio driver and device > development discussion. But we are developing a virtio sound card prototype for > a while and we would like to share our specification draft and public header > file (attaching 'virtio_snd.h' and 'virtio-snd-spec-draft.md'). The PoC for > proposed approach was tested with virtio audio driver in Linux and in Windows 10 > as well. > > It would be really great if we can collaborate on this topic. I would be happy > to answer any questions. Wow. That looks pretty complete already ... > Configuration space provides a maximum amount of available virtual queues. The > nqueues value MUST be at least one. > > ``` > struct virtio_snd_config > { > le32 nqueues; > }; > ``` Including or excluding the control queue? > Each request begins with a 2-byte field that identifies a recipient function > followed by a 2-byte field that identifies a function-specific request type. > > Each response begins with a 4-byte field that contains a status code. The values > 0-31 are reserved for common status codes, a function can define function-specific > status codes starting from 32. I'd suggest to use a common scheme with a single le32 field for both requests and responses. #define VIRTIO_SND_BASE_OFFSET 0x10000 #define VIRTIO_SND_PCM_OFFSET 0x20000 enum virtio_sound_request { VIRTIO_SND_BASE_REQ1 = VIRTIO_SND_BASE_OFFSET, VIRTIO_SND_BASE_REQ2, [ ... ] VIRTIO_SND_PCM_REQ1 = VIRTIO_SND_PCM_OFFSET, VIRTIO_SND_PCM_REQ2, [ ... ] }; enum virtio_sound_response { VIRTIO_SND_E_SUCCESS, VIRTIO_SND_E_GENERAL = VIRTIO_SND_BASE_OFFSET, VIRTIO_SND_E_NOTSUPPORTED, [ ... ] VIRTIO_SND_PCM_E_NOT_READY = VIRTIO_SND_PCM_OFFSET, [ ... ] }; > struct virtio_snd_req > { enum virtio_sound_request; > struct virtio_snd_rsp > { enum virtio_sound_response; (maybe just drop the single-element structs and use the enums directly). > ### Device Configuration > > The device reports its configuration using descriptors. A descriptor is a data > structure with a defined format. Each descriptor begins with a byte-wide field > that contains the total number of bytes in the descriptor followed by a byte-wide > field that identifies the descriptor type. > > ``` > struct virtio_snd_generic_desc > { > u8 length; > u8 type; > u16 padding; I'd make length and type u16 and drop the padding. > With the exception of the base function, all implemented functions MUST define > its own descriptor(s) format (either presented in this specification or > vendor-specific) and MUST includes these in configuration only if a particular > function (or part of its functionality) is enabled in the device. I don't think it is a good idea to allow vendor-specific descriptors here. It should all be in the virtio spec. We might want reserve a sub-range of "type" for experimental/development purposes though. > ### Function Operation > > #### Get Device Configuration > > The driver sends the VIRTIO_SND_BASE_R_GET_CFG generic request, the device > answers with a response containing device configuration. Which is a list of descriptors I assume? > #### Suspend > > The driver sends the VIRTIO_SND_BASE_R_SUSPEND generic request, the device > answers with a generic response. For each initialized function, the device SHOULD > be able to preserve its runtime state and MUST put it into function-specific > suspended state. > > #### Resume > > The driver sends the VIRTIO_SND_BASE_R_RESUME generic request, the device > answers with a generic response. For each initialized function, the device SHOULD > be able to restore its runtime state and MUST put it into function-specific > non-suspended state. Why these two are needed? Also restoring state as optional device feature doesn't look useful to me. > - *Manual mode*: the driver assigns a dedicated virtual queue for a PCM substream > and use it to transmit data buffers to the device. The device writes/reads PCM > frames only upon receiving a buffer from the driver. That is how I expect a virtio-audio device work. > - *Automatic mode*: the driver allocates and shares with the device a pseudophysically > continuous memory area containing runtime control registers and data buffer itself. What is "pseudophysically continuous memory"? Why do you think this is needed? > Regardless of the mode of operation, the device MAY require to specify an > approximate data buffer update frequency. In such case, the driver MUST specify > an approximate update frequency (expressed in both microseconds and bytes units) > before starting a PCM substream. Why both microseconds and bytes? Isn't that redundant? > /* a PCM function descriptor */ > struct virtio_snd_pcm_desc > { > /* sizeof(struct virtio_snd_pcm_desc) */ > u8 length; > /* VIRTIO_SND_DESC_PCM */ > u8 type; > /* a PCM function ID (assigned by the device) */ > u8 pcm_id; > /* # of PCM stream descriptors in the configuration (one per supported PCM stream type) */ > u8 nstreams; > }; > /* supported PCM sample formats */ > #define VIRTIO_SND_PCM_FMT_MU_LAW 0 > #define VIRTIO_SND_PCM_FMT_A_LAW 1 > #define VIRTIO_SND_PCM_FMT_S8 2 > #define VIRTIO_SND_PCM_FMT_U8 3 > #define VIRTIO_SND_PCM_FMT_S16_LE 4 > #define VIRTIO_SND_PCM_FMT_S16_BE 5 > #define VIRTIO_SND_PCM_FMT_U16_LE 6 > #define VIRTIO_SND_PCM_FMT_U16_BE 7 > #define VIRTIO_SND_PCM_FMT_S24_LE 8 > #define VIRTIO_SND_PCM_FMT_S24_BE 9 > #define VIRTIO_SND_PCM_FMT_U24_LE 10 > #define VIRTIO_SND_PCM_FMT_U24_BE 11 > #define VIRTIO_SND_PCM_FMT_S32_LE 12 > #define VIRTIO_SND_PCM_FMT_S32_BE 13 > #define VIRTIO_SND_PCM_FMT_U32_LE 14 > #define VIRTIO_SND_PCM_FMT_U32_BE 15 > #define VIRTIO_SND_PCM_FMT_FLOAT_LE 16 > #define VIRTIO_SND_PCM_FMT_FLOAT_BE 17 > #define VIRTIO_SND_PCM_FMT_FLOAT64_LE 18 > #define VIRTIO_SND_PCM_FMT_FLOAT64_BE 19 > #define VIRTIO_SND_PCM_FMT_S20_LE 20 > #define VIRTIO_SND_PCM_FMT_S20_BE 21 > #define VIRTIO_SND_PCM_FMT_U20_LE 22 > #define VIRTIO_SND_PCM_FMT_U20_BE 23 > #define VIRTIO_SND_PCM_FMT_S24_3LE 24 > #define VIRTIO_SND_PCM_FMT_S24_3BE 25 > #define VIRTIO_SND_PCM_FMT_U24_3LE 26 > #define VIRTIO_SND_PCM_FMT_U24_3BE 27 > #define VIRTIO_SND_PCM_FMT_S20_3LE 28 > #define VIRTIO_SND_PCM_FMT_S20_3BE 29 > #define VIRTIO_SND_PCM_FMT_U20_3LE 30 > #define VIRTIO_SND_PCM_FMT_U20_3BE 31 > #define VIRTIO_SND_PCM_FMT_S18_3LE 32 > #define VIRTIO_SND_PCM_FMT_U18_3LE 33 > #define VIRTIO_SND_PCM_FMT_S18_3BE 34 > #define VIRTIO_SND_PCM_FMT_U18_3BE 35 That looks a bit over-engineered to me. First, virtio uses little endian. How about dropping all bigendian formats? Are 8-bit formats are still used in practice? What are VIRTIO_SND_PCM_FMT_{S,U}20_LE ? What are VIRTIO_SND_PCM_FMT_*_3BE ? Which of these formats are actually implemented in your prototype? > /* supported PCM frame rates */ > #define VIRTIO_SND_PCM_RATE_5512 0 > #define VIRTIO_SND_PCM_RATE_8000 1 > #define VIRTIO_SND_PCM_RATE_11025 2 > #define VIRTIO_SND_PCM_RATE_16000 3 > #define VIRTIO_SND_PCM_RATE_22050 4 > #define VIRTIO_SND_PCM_RATE_32000 5 > #define VIRTIO_SND_PCM_RATE_44100 6 > #define VIRTIO_SND_PCM_RATE_48000 7 > #define VIRTIO_SND_PCM_RATE_64000 8 > #define VIRTIO_SND_PCM_RATE_88200 9 > #define VIRTIO_SND_PCM_RATE_96000 10 > #define VIRTIO_SND_PCM_RATE_176400 11 > #define VIRTIO_SND_PCM_RATE_192000 12 Same question: Do we actually need all those? My impression is that these days 48000 is pretty much standard. 96000 + 192000 for higher quality. 44100 sometimes still because it happens to be the CD sample rate. Maybe 32000/16000/8000 for low bandwidth codecs. But 5512, 11025 & friends? > The driver gets the VIRTIO_SND_PCM_FEAT_CHANNEL_MAP feature value in order to obtain > a channel map with specified index, the device answers with the virtio_snd_pcm_chmap > PCM response. > > If channel map type allows to swap channels, the driver can set the VIRTIO_SND_PCM_FEAT_CHANNEL_MAP > feature value specifying selected channel map data as a request argument. The > device answers with a generic response. > > ``` > /* a PCM channel map definitions */ > > /* All channels have fixed channel positions */ > #define VIRTIO_SND_PCM_CHMAP_FIXED 0 > /* All channels are swappable (e.g. {FL/FR/RL/RR} -> {RR/RL/FR/FL}) */ > #define VIRTIO_SND_PCM_CHMAP_VARIABLE 1 > /* Only pair-wise channels are swappable (e.g. {FL/FR/RL/RR} -> {RL/RR/FL/FR}) */ > #define VIRTIO_SND_PCM_CHMAP_PAIRED 2 What this is good for? How would a driver ask the device to actually swap the channels? And isn't it easier to have the device provide a complete list of possible channel maps and let the driver simply pick one? > /* Standard channel position definition */ > #define VIRTIO_SND_PCM_CH_NONE 0 /* undefined */ > #define VIRTIO_SND_PCM_CH_NA 1 /* silent */ > #define VIRTIO_SND_PCM_CH_MONO 2 /* mono stream */ > #define VIRTIO_SND_PCM_CH_FL 3 /* front left */ > #define VIRTIO_SND_PCM_CH_FR 4 /* front right */ > #define VIRTIO_SND_PCM_CH_RL 5 /* rear left */ > #define VIRTIO_SND_PCM_CH_RR 6 /* rear right */ > #define VIRTIO_SND_PCM_CH_FC 7 /* front center */ > #define VIRTIO_SND_PCM_CH_LFE 8 /* low frequency (LFE) */ > #define VIRTIO_SND_PCM_CH_SL 9 /* side left */ > #define VIRTIO_SND_PCM_CH_SR 10 /* side right */ > #define VIRTIO_SND_PCM_CH_RC 11 /* rear center */ > #define VIRTIO_SND_PCM_CH_FLC 12 /* front left center */ > #define VIRTIO_SND_PCM_CH_FRC 13 /* front right center */ > #define VIRTIO_SND_PCM_CH_RLC 14 /* rear left center */ > #define VIRTIO_SND_PCM_CH_RRC 15 /* rear right center */ > #define VIRTIO_SND_PCM_CH_FLW 16 /* front left wide */ > #define VIRTIO_SND_PCM_CH_FRW 17 /* front right wide */ > #define VIRTIO_SND_PCM_CH_FLH 18 /* front left high */ > #define VIRTIO_SND_PCM_CH_FCH 19 /* front center high */ > #define VIRTIO_SND_PCM_CH_FRH 20 /* front right high */ > #define VIRTIO_SND_PCM_CH_TC 21 /* top center */ > #define VIRTIO_SND_PCM_CH_TFL 22 /* top front left */ > #define VIRTIO_SND_PCM_CH_TFR 23 /* top front right */ > #define VIRTIO_SND_PCM_CH_TFC 24 /* top front center */ > #define VIRTIO_SND_PCM_CH_TRL 25 /* top rear left */ > #define VIRTIO_SND_PCM_CH_TRR 26 /* top rear right */ > #define VIRTIO_SND_PCM_CH_TRC 27 /* top rear center */ > #define VIRTIO_SND_PCM_CH_TFLC 28 /* top front left center */ > #define VIRTIO_SND_PCM_CH_TFRC 29 /* top front right center */ > #define VIRTIO_SND_PCM_CH_TSL 30 /* top side left */ > #define VIRTIO_SND_PCM_CH_TSR 31 /* top side right */ > #define VIRTIO_SND_PCM_CH_LLFE 32 /* left LFE */ > #define VIRTIO_SND_PCM_CH_RLFE 33 /* right LFE */ > #define VIRTIO_SND_PCM_CH_BC 34 /* bottom center */ > #define VIRTIO_SND_PCM_CH_BLC 35 /* bottom left center */ > #define VIRTIO_SND_PCM_CH_BRC 36 /* bottom right center */ Wow. What is the use case for all those channels? cinema sound? > #### Prepare > > The driver MUST send the VIRTIO_SND_PCM_R_PREPARE generic PCM request to prepare > a substream for running, the device answers with a generic response. > > #### Start > > The driver sends the VIRTIO_SND_PCM_R_START generic PCM request, the device > answers with a generic response. So I guess the way to start a stream is (a) prepare, (b) queue some buffers, (c) start. Correct? 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: virtio-dev-return-5728-cohuck=redhat.com@lists.oasis-open.org Sender: List-Post: List-Help: List-Unsubscribe: List-Subscribe: Received: from lists.oasis-open.org (oasis.ws5.connectedcommunity.org [10.110.1.242]) by lists.oasis-open.org (Postfix) with ESMTP id 9C1D4985DFA for ; Fri, 10 May 2019 14:15:47 +0000 (UTC) From: Anton Yakovlev Date: Fri, 10 May 2019 14:15:00 +0000 Message-ID: <76D732A88286A1478FFA94B453B715C1EEA25DD4@MXS02.open-synergy.com> References: <20190429134754.GI7587@stefanha-x1.localdomain> <4fcd7456-de22-7f6d-d5ef-939cd3d7cf95@13byte.com> <20190501170525.GB22391@stefanha-x1.localdomain> <20190503164501.GB8373@stefanha-x1.localdomain> <863e1be1-11cc-816b-896d-3954427e98f3@13byte.com> <20190506052715.vkdopunuauyhl22m@sirius.home.kraxel.org> <7ac2ae97-bcb7-22cc-272a-723e7209910c@13byte.com> <20190509122710.rfhfnhqez2u7inju@sirius.home.kraxel.org> <5d316321-2c48-342b-f2ce-359e3596dae0@opensynergy.com>,<20190510121656.3ab7w5xef6io764o@sirius.home.kraxel.org> In-Reply-To: <20190510121656.3ab7w5xef6io764o@sirius.home.kraxel.org> Content-Language: en-US Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: RE: [virtio-dev] Request for a new device number for a virtio-audio device. To: Gerd Hoffmann , Mikhail Golubev Cc: Marco Martinelli - 13Byte srl , "virtio-dev@lists.oasis-open.org" , Stefan Hajnoczi , =?iso-8859-2?Q?K=F5v=E1g=F3_Zolt=E1n?= List-ID: Hi Gerd! My name is Anton and I'm the original author of this draft. Thanks= for comments! >> Configuration space provides a maximum amount of available virtual queue= s. The >> nqueues value MUST be at least one. >> >> ``` >> struct virtio_snd_config >> { >> le32 nqueues; >> }; >> ``` > Including or excluding the control queue? Including the control queue. >> Each request begins with a 2-byte field that identifies a recipient func= tion >> followed by a 2-byte field that identifies a function-specific request t= ype. >> >> Each response begins with a 4-byte field that contains a status code. Th= e values >> 0-31 are reserved for common status codes, a function can define functio= n-specific >> status codes starting from 32. > I'd suggest to use a common scheme with a single le32 field for both > requests and responses. > ... > (maybe just drop the single-element structs and use the enums directly). IMO, both options are quite fine. We decided to choose separate namespaces = because it's more flexible approach. >> ### Device Configuration >> ... >> struct virtio_snd_generic_desc >> { >> u8 length; >> u8 type; >> u16 padding; > > I'd make length and type u16 and drop the padding. Well, it's a possible option. We just didn't want to waste additional space= here. >> With the exception of the base function, all implemented functions MUST = define >> its own descriptor(s) format (either presented in this specification or >> vendor-specific) and MUST includes these in configuration only if a part= icular >> function (or part of its functionality) is enabled in the device. > > I don't think it is a good idea to allow vendor-specific descriptors > here. It should all be in the virtio spec. We might want reserve a > sub-range of "type" for experimental/development purposes though. Yeah, an ability to define some experimental extensions was one of the targ= ets here (like adding sound controls, non-PCM streams, MIDI and so on). Als= o, this spec targeted the widest possible range of cases. Like, some hardwa= re has very tricky features which can not be (or just has no point to be) d= efined in common specification. One example is to allow switching between s= peaker and bluetooth output. Ususally you don't need it, but if you want to= provide such feature to the guest, it's better to implement this as a cust= om extension. >> ### Function Operation >> >> #### Get Device Configuration >> >> The driver sends the VIRTIO_SND_BASE_R_GET_CFG generic request, the devi= ce >> answers with a response containing device configuration. > > Which is a list of descriptors I assume? You are right. >> #### Suspend >> >> ... >> >> #### Resume >> >> ... >> > > Why these two are needed? I would say, that some virtualization platforms either do not notify your b= ackend about guest suspend/resume or it's very tricky to distinguish such c= onditions from other shutdown/initialization types. According to my practic= e, it's always better to notify device side in explicit way, because the dr= iver always know what is going now. > Also restoring state as optional device feature doesn't look useful to > me. Well, restoring active playback or capturing is not impossible thing at all= . From other side, maybe some device implementors might not want/need such = functionality. So I'm not sure, what is better here. >> - *Manual mode*: the driver assigns a dedicated virtual queue for a PCM = substream >> and use it to transmit data buffers to the device. The device writes/rea= ds PCM >> frames only upon receiving a buffer from the driver. > > That is how I expect a virtio-audio device work. Yeah, I understand. But it's the very beginning of the road (see below). >> - *Automatic mode*: the driver allocates and shares with the device a ps= eudophysically >> continuous memory area containing runtime control registers and data buf= fer itself. > > What is "pseudophysically continuous memory"? This memory is physically continuous from the driver's point of view. > Why do you think this is needed? When you implement an audio device, you usually start with what we call "ma= nual mode". It works, but only for simple use cases. There're two major cha= llenges here. 1) An application can use audio device in many different ways. It may fill = the entire buffer with frames and let it draining. It may provides data in = form of relatively big chunks. But usually you will face with so called "lo= w latency" applications. These try to reduce result latency by providing sm= all chunks of data. In extreme cases, the driver may receive requests conta= ining only 5-10 frames. It means an amount of both system calls and request= s to the device will grow. At some point this rate may become quite noticab= le. But things may become even worse, if an application activates both stre= ams (playback and capture) at the same time. For example, voice chat applic= ations (trying to reduce latency as much as possible) may hang you VM becau= se of huge amount of small requests on both PCM streams. Thus, no requests/= traps/hypercalls to the device while a stream is running - no problems here= . 2) Everybody wants to reduce a latency as much as possible. One of the most= logical way is to allow to mmap data buffer into the user space memory. (A= ctually, in some cases you even have no choice here, like in case of the Wa= veRT interface in Windows.) But memory mapped buffer means, that you either= have a very little or have not at all an idea what is going on with buffer= content. Even if you have information about when and where an application = writes to or reads from the buffer (ALSA enforces an application to maintai= n its appl_ptr value), you will have a lot of headache with tracking the re= wind/forward cases. I can't say for everyone, but our experiments with usin= g "manual mode" here all failed. From other side, the isochronous nature of= PCM stream and the nature of sound card itself suggest you right solution.= You don't need to care about what and how an application does with a buffe= r. Since it's expected from the device to read/write data with constant rat= e. Thus, you can do the same in your virtual audio device. And it works lik= e a charm! We wanted to be ready for every possible use case, that's why we combined s= olutions for described issues into what we call "automatic mode". The funni= est thing is, according to our tests, in automatic mode you can have stable= and clean playback/capturing even under the very high CPU pressure. >> Regardless of the mode of operation, the device MAY require to specify a= n >> approximate data buffer update frequency. In such case, the driver MUST = specify >> an approximate update frequency (expressed in both microseconds and byte= s units) >> before starting a PCM substream. > > Why both microseconds and bytes? Isn't that redundant? Just to be sure that both ends have exactly the same ideas. > /* a PCM function descriptor */ > struct virtio_snd_pcm_desc > { > /* sizeof(struct virtio_snd_pcm_desc) */ > u8 length; > /* VIRTIO_SND_DESC_PCM */ > u8 type; > /* a PCM function ID (assigned by the device) */ > u8 pcm_id; > /* # of PCM stream descriptors in the configuration (one per supporte= d PCM stream type) */ > u8 nstreams; > }; > /* supported PCM sample formats */ > ... > > That looks a bit over-engineered to me. > > First, virtio uses little endian. How about dropping all bigendian > formats? > > Are 8-bit formats are still used in practice? Actually, yeah. I saw quite recent chipsets with the U8 format support. Any= way, is it a big issue? It costs zero to support additional formats, so why= not? > What are VIRTIO_SND_PCM_FMT_{S,U}20_LE ? > > What are VIRTIO_SND_PCM_FMT_*_3BE ? > > Which of these formats are actually implemented in your prototype? Some format's physical width is not multiple of 8. Such samples are kept in= "a storage" which width is multiple of 8 (like 20-bit samples are kept eit= her in 24-bit or in 32-bit storage). Both Linux (ALSA) and Windows (WaveXXX interfaces) just expect from you to = report support of these formats. You don't need to do anything special in o= rder to implemented them. So, yes, we can support them in the prototype. >> /* supported PCM frame rates */ >> ... > > Same question: Do we actually need all those? My impression is that > these days 48000 is pretty much standard. 96000 + 192000 for higher > quality. 44100 sometimes still because it happens to be the CD sample > rate. Maybe 32000/16000/8000 for low bandwidth codecs. > > But 5512, 11025 & friends? Same answer: why not? :) >> /* a PCM channel map definitions */ >> >> /* All channels have fixed channel positions */ >> #define VIRTIO_SND_PCM_CHMAP_FIXED 0 >> /* All channels are swappable (e.g. {FL/FR/RL/RR} -> {RR/RL/FR/FL}) */ >> #define VIRTIO_SND_PCM_CHMAP_VARIABLE 1 >> /* Only pair-wise channels are swappable (e.g. {FL/FR/RL/RR} -> {RL/RR/F= L/FR}) */ >> #define VIRTIO_SND_PCM_CHMAP_PAIRED 2 > > What this is good for? How would a driver ask the device to actually > swap the channels? And isn't it easier to have the device provide a > complete list of possible channel maps and let the driver simply pick > one? Basically, we were inspired how ALSA handles these and reused the same appr= oach here. How: a hardware can have internal router/mixer to allow flexible= configuration, there's nothing special. About how to provide a list of cha= nnel maps - it's a matter of responsibilities. I would like to stick to har= dware-like approach, when hardware just reports minimum amount of capabilit= ies, and it's up to the driver what to do with it. >> /* Standard channel position definition */ >> ... > > Wow. What is the use case for all those channels? cinema sound? Virtual cinema sound! >> #### Prepare >> ... >> #### Start >> ... > > So I guess the way to start a stream is (a) prepare, (b) queue some > buffers, (c) start. Correct? Yeap! 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 -- Anton Yakovlev Senior Software Engineer OpenSynergy GmbH Rotherstr. 20, 10245 Berlin www.opensynergy.com Please mind our privacy notice pursuant to Art. 13 GDPR. // Unsere= Hinweise zum Datenschutz gem. Art. 13 DSGVO finden Sie hier. COQOS Hypervisor certified by T=DCV S=DCD [COQOS Hypervisor certified by T=DCV S=DCD] --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: virtio-dev-return-5729-cohuck=redhat.com@lists.oasis-open.org Sender: List-Post: List-Help: List-Unsubscribe: List-Subscribe: Received: from lists.oasis-open.org (oasis.ws5.connectedcommunity.org [10.110.1.242]) by lists.oasis-open.org (Postfix) with ESMTP id B00FC985DFB for ; Fri, 10 May 2019 15:48:30 +0000 (UTC) Date: Fri, 10 May 2019 16:48:24 +0100 From: Stefan Hajnoczi Message-ID: <20190510154824.GJ22311@stefanha-x1.localdomain> References: <20190501170525.GB22391@stefanha-x1.localdomain> <20190503164501.GB8373@stefanha-x1.localdomain> <863e1be1-11cc-816b-896d-3954427e98f3@13byte.com> <20190506052715.vkdopunuauyhl22m@sirius.home.kraxel.org> <7ac2ae97-bcb7-22cc-272a-723e7209910c@13byte.com> <20190509122710.rfhfnhqez2u7inju@sirius.home.kraxel.org> <5d316321-2c48-342b-f2ce-359e3596dae0@opensynergy.com> <20190510121656.3ab7w5xef6io764o@sirius.home.kraxel.org> <76D732A88286A1478FFA94B453B715C1EEA25DD4@MXS02.open-synergy.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="LQAwcd5tHl0Qlnzi" Content-Disposition: inline In-Reply-To: <76D732A88286A1478FFA94B453B715C1EEA25DD4@MXS02.open-synergy.com> Subject: Re: [virtio-dev] Request for a new device number for a virtio-audio device. To: Anton Yakovlev Cc: Gerd Hoffmann , Mikhail Golubev , Marco Martinelli - 13Byte srl , "virtio-dev@lists.oasis-open.org" , =?utf-8?B?S8WRdsOhZ8OzIFpvbHTDoW4=?= List-ID: --LQAwcd5tHl0Qlnzi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, May 10, 2019 at 02:15:00PM +0000, Anton Yakovlev wrote: > > Why do you think this is needed? >=20 > When you implement an audio device, you usually start with what we call "= manual mode". It works, but only for simple use cases. There're two major c= hallenges here. >=20 > 1) An application can use audio device in many different ways. It may fil= l the entire buffer with frames and let it draining. It may provides data i= n form of relatively big chunks. But usually you will face with so called "= low latency" applications. These try to reduce result latency by providing = small chunks of data. In extreme cases, the driver may receive requests con= taining only 5-10 frames. It means an amount of both system calls and reque= sts to the device will grow. At some point this rate may become quite notic= able. But things may become even worse, if an application activates both st= reams (playback and capture) at the same time. For example, voice chat appl= ications (trying to reduce latency as much as possible) may hang you VM bec= ause of huge amount of small requests on both PCM streams. Thus, no request= s/traps/hypercalls to the device while a stream is running - no problems he= re. >=20 > 2) Everybody wants to reduce a latency as much as possible. One of the mo= st logical way is to allow to mmap data buffer into the user space memory. = (Actually, in some cases you even have no choice here, like in case of the = WaveRT interface in Windows.) But memory mapped buffer means, that you eith= er have a very little or have not at all an idea what is going on with buff= er content. Even if you have information about when and where an applicatio= n writes to or reads from the buffer (ALSA enforces an application to maint= ain its appl_ptr value), you will have a lot of headache with tracking the = rewind/forward cases. I can't say for everyone, but our experiments with us= ing "manual mode" here all failed. From other side, the isochronous nature = of PCM stream and the nature of sound card itself suggest you right solutio= n. You don't need to care about what and how an application does with a buf= fer. Since it's expected from the device to read/write data with constant r= ate. Thus, you can do the same in your virtual audio device. And it works l= ike a charm! >=20 > We wanted to be ready for every possible use case, that's why we combined= solutions for described issues into what we call "automatic mode". The fun= niest thing is, according to our tests, in automatic mode you can have stab= le and clean playback/capturing even under the very high CPU pressure. Thanks for contributing your virtio-snd spec to the discussion! Shared memory isn't a native concept to VIRTIO. The device and the driver don't assume shared memory access in the general case (i.e. virtqueue buffers could even be copied and virtio-blk, virtio-net, etc would still work!). There is currently a spec extension on the mailing list to add Shared Memory Resources to VIRTIO and new device types will use it. However, I don't think this is necessary for this use case. Two techniques can be used to minimize virtqueue notifications: 1. Polling has become a commonly used technique over the last several years. Both the driver and the device may disable notifications and simply peek at the ring indices to detect new buffers from the other side. 2. For synchronization and to reduce notifications the device could support bundling playback and capture into a single buffer so that only 1 virtqueue is used: /* A packet of PCM data associated with a stream */ struct virtio_audio_pcm_data { unsigned stream_id; uint8_t data[num_frames * num_channels * bytes_per_sample]; }; /* An exchange of playback and capture PCM data */ struct virtio_audio_pcm { /* Write (Driver -> Device) */ /* Note that all playback and capture streams must have the same * sample rate. */ unsigned num_playback; /* 0 or more */ unsigned num_capture; /* 0 or more */ /* All playback and capture streams transfer this number of * frames of PCM data. */ unsigned num_frames; struct virtio_audio_pcm_data playback[num_playback]; /* Read (Device -> Driver) */ struct virtio_audio_pcm_data capture[num_capture]; /* TODO status and error codes */ }; In other words, a single struct virtio_audio_pcm delivers playback samples to the device and returns capture samples to the driver. I used arrays so that multiple streams with the same sample rate can be bundled together. --LQAwcd5tHl0Qlnzi Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhpWov9P5fNqsNXdanKSrs4Grc8gFAlzVnUgACgkQnKSrs4Gr c8h+tQgAuzdwyKnnKnovzh+/wx2jiISpqhF1VGC1TJQ/4bYPA+kE2Oz4HNsjHQm3 r8O10mvbft2kaItiZobq9fF7CZ1E8dy3gTu9KqYmZT8VvNJuzvxjXAnD16H7O0Mm /NYGZd7H6v7wFR9Yrfy/Pc8rRxvqjqQm3254uBfW2DZJRAtUW1p5QK3B4FlH6iom JphTSZpNJnCIQTUAlkvPITNFJyK5Z69gEUA1eyZICTwmOhkFF4hh3YE0Dv+T5GCS HGgwumwX+gEd0Wbp48yYuRsO2D2paNT+dmKUo+xmdplQKVboc7SnelN3/YPeyQQp 5X+lt9SzSoa6L56bstFdDN7UFADWDQ== =8otW -----END PGP SIGNATURE----- --LQAwcd5tHl0Qlnzi-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: virtio-dev-return-5731-cohuck=redhat.com@lists.oasis-open.org Sender: List-Post: List-Help: List-Unsubscribe: List-Subscribe: Received: from lists.oasis-open.org (oasis.ws5.connectedcommunity.org [10.110.1.242]) by lists.oasis-open.org (Postfix) with ESMTP id EA165985DFB for ; Fri, 10 May 2019 17:13:37 +0000 (UTC) From: Anton Yakovlev Date: Fri, 10 May 2019 17:13:26 +0000 Message-ID: <76D732A88286A1478FFA94B453B715C1EEA25EB1@MXS02.open-synergy.com> References: <20190501170525.GB22391@stefanha-x1.localdomain> <20190503164501.GB8373@stefanha-x1.localdomain> <863e1be1-11cc-816b-896d-3954427e98f3@13byte.com> <20190506052715.vkdopunuauyhl22m@sirius.home.kraxel.org> <7ac2ae97-bcb7-22cc-272a-723e7209910c@13byte.com> <20190509122710.rfhfnhqez2u7inju@sirius.home.kraxel.org> <5d316321-2c48-342b-f2ce-359e3596dae0@opensynergy.com> <20190510121656.3ab7w5xef6io764o@sirius.home.kraxel.org> <76D732A88286A1478FFA94B453B715C1EEA25DD4@MXS02.open-synergy.com>,<20190510154824.GJ22311@stefanha-x1.localdomain> In-Reply-To: <20190510154824.GJ22311@stefanha-x1.localdomain> Content-Language: en-US Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: RE: [virtio-dev] Request for a new device number for a virtio-audio device. To: Stefan Hajnoczi Cc: Gerd Hoffmann , Mikhail Golubev , Marco Martinelli - 13Byte srl , "virtio-dev@lists.oasis-open.org" , =?iso-8859-2?Q?K=F5v=E1g=F3_Zolt=E1n?= List-ID: > Shared memory isn't a native concept to VIRTIO. The device and the > driver don't assume shared memory access in the general case (i.e. > virtqueue buffers could even be copied and virtio-blk, virtio-net, etc > would still work!). > > There is currently a spec extension on the mailing list to add Shared > Memory Resources to VIRTIO and new device types will use it. However, I > don't think this is necessary for this use case. Yes, we are awared about VIRTIO and shared memory relationships. Our origin= al propose was to support classic way of communications by default. And, th= anks to your comments, it can be further improved. But there's one issue. An audio device is a real-time device. It has explic= it hard deadline. And there're many factors helping an audio device to fail= to meet the deadline due to virtualization overhead. And in that sense a v= irtual audio device differs from each and every other virtual devices. If a= block device becomes slower - not a big deal, if a network device becomes = slower - not a big deal, if a GPU device starts to skip frames - not very n= ice, but also not a big deal. But if an audio device starts to skip frames = - it's a big problem, and device is nonfunctional as a matter of fact. Good= audio device implementation must met two criterias: 1. Low latency 2. No frame dropping at all All I want to say is that any queue-based approach can not guaranty correct= functionality to an audio device for all possible use cases. Because a que= ue has its natural limitations: either in terms of additional latency due t= o queue notifications, or due to queue limited size. And an audio device ev= entually will hit one of them for some application. It means, we can not su= pport some cases, which works pretty fine in native operating systems. But = such limitations are artificial ones due, again, using a queue for data tra= nsfers. In case of shared memory such limitations are just gone. 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 pos= sible or make sense. Like, all modern type-2 hypervisors usually have no pr= oblems with sharing memory between guest and host, so why not provide to us= er high quality virtual audio device? -- Anton Yakovlev Senior Software Engineer OpenSynergy GmbH Rotherstr. 20, 10245 Berlin www.opensynergy.com Please mind our privacy notice pursuant to Art. 13 GDPR. // Unsere= Hinweise zum Datenschutz gem. Art. 13 DSGVO finden Sie hier. COQOS Hypervisor certified by T=DCV S=DCD [COQOS Hypervisor certified by T=DCV S=DCD] --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: virtio-dev-return-5737-cohuck=redhat.com@lists.oasis-open.org Sender: List-Post: List-Help: List-Unsubscribe: List-Subscribe: Received: from lists.oasis-open.org (oasis.ws5.connectedcommunity.org [10.110.1.242]) by lists.oasis-open.org (Postfix) with ESMTP id 04253985E0A for ; Sat, 11 May 2019 20:49:08 +0000 (UTC) References: <20190501170525.GB22391@stefanha-x1.localdomain> <20190503164501.GB8373@stefanha-x1.localdomain> <863e1be1-11cc-816b-896d-3954427e98f3@13byte.com> <20190506052715.vkdopunuauyhl22m@sirius.home.kraxel.org> <7ac2ae97-bcb7-22cc-272a-723e7209910c@13byte.com> <20190509122710.rfhfnhqez2u7inju@sirius.home.kraxel.org> <5d316321-2c48-342b-f2ce-359e3596dae0@opensynergy.com> <20190510121656.3ab7w5xef6io764o@sirius.home.kraxel.org> <76D732A88286A1478FFA94B453B715C1EEA25DD4@MXS02.open-synergy.com> <20190510154824.GJ22311@stefanha-x1.localdomain> <76D732A88286A1478FFA94B453B715C1EEA25EB1@MXS02.open-synergy.com> From: Marco Martinelli - 13Byte srl Message-ID: <91bb7417-fc62-27e6-95a7-d5588699d5e1@13byte.com> Date: Sat, 11 May 2019 22:49:04 +0200 MIME-Version: 1.0 In-Reply-To: <76D732A88286A1478FFA94B453B715C1EEA25EB1@MXS02.open-synergy.com> Content-Type: text/plain; charset="iso-8859-2"; format="flowed" Content-Transfer-Encoding: quoted-printable Content-Language: en-US Subject: Re: [virtio-dev] Request for a new device number for a virtio-audio device. To: Anton Yakovlev , Stefan Hajnoczi , "virtio-dev@lists.oasis-open.org" Cc: Gerd Hoffmann , Mikhail Golubev , =?UTF-8?B?S8WRdsOhZ8OzIFpvbHTDoW4=?= List-ID: Wow, it seems like you guys from opensinergy beat me on time. Nice job,=20 congratulations! Your work is way ahead of mine, so much that I'm thinking of stepping=20 aside and letting you do the specifications, while experimenting on my=20 code privately just for the fun of it. Just a couple of questions. You mentioned that the PoC was tested on Linux and Windows 10. I presume=20 these are the guest OSs. On the host side are you working on qemu or another hypervisor? Besides contributing to the specifications, will you open source the=20 actual implementation? From your website I see you work in the automotive business. Will your=20 implementation be automotive oriented or general purpose? My idea was to support the general public and in particular the gamers=20 and the musicians with my project. I want to be sure that these=20 categories will be supported. The reason I'm asking these questions is to see if it makes sense for me=20 to keep working on this project, perhaps to implement the specifications=20 proposed by you, or if you're already taking care of everything I was=20 interested in implementing. Best regards, Marco Il 10/05/19 19:13, Anton Yakovlev ha scritto: >> Shared memory isn't a native concept to VIRTIO. The device and the >> driver don't assume shared memory access in the general case (i.e. >> virtqueue buffers could even be copied and virtio-blk, virtio-net, etc >> would still work!). >> >> There is currently a spec extension on the mailing list to add Shared >> Memory Resources to VIRTIO and new device types will use it. However, I >> don't think this is necessary for this use case. > Yes, we are awared about VIRTIO and shared memory relationships. Our orig= inal propose was to support classic way of communications by default. And, = thanks to your comments, it can be further improved. > > But there's one issue. An audio device is a real-time device. It has expl= icit hard deadline. And there're many factors helping an audio device to fa= il to meet the deadline due to virtualization overhead. And in that sense a= virtual audio device differs from each and every other virtual devices. If= a block device becomes slower - not a big deal, if a network device become= s slower - not a big deal, if a GPU device starts to skip frames - not very= nice, but also not a big deal. But if an audio device starts to skip frame= s - it's a big problem, and device is nonfunctional as a matter of fact. Go= od audio device implementation must met two criterias: > > 1. Low latency > 2. No frame dropping at all > > All I want to say is that any queue-based approach can not guaranty corre= ct functionality to an audio device for all possible use cases. Because a q= ueue has its natural limitations: either in terms of additional latency due= to queue notifications, or due to queue limited size. And an audio device = eventually will hit one of them for some application. It means, we can not = support some cases, which works pretty fine in native operating systems. Bu= t such limitations are artificial ones due, again, using a queue for data t= ransfers. In case of shared memory such limitations are just gone. > > So, our proposal is to support classic way of communications by default a= nd 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 p= ossible 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? > > -- > Anton Yakovlev > Senior Software Engineer > > OpenSynergy GmbH > Rotherstr. 20, 10245 Berlin > > www.opensynergy.com > > Please mind our privacy notice pursuant to Art. 13 GDPR. // Unse= re Hinweise zum Datenschutz gem. Art. 13 DSGVO finden Sie hier. > COQOS Hypervisor certified by T=DCV S=DCD > [COQOS Hypervisor certified by T=DCV S=DCD] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org > For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org > --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: virtio-dev-return-5740-cohuck=redhat.com@lists.oasis-open.org Sender: List-Post: List-Help: List-Unsubscribe: List-Subscribe: Received: from lists.oasis-open.org (oasis.ws5.connectedcommunity.org [10.110.1.242]) by lists.oasis-open.org (Postfix) with ESMTP id 76CD2984410 for ; Sun, 12 May 2019 20:02:50 +0000 (UTC) References: <20190501170525.GB22391@stefanha-x1.localdomain> <20190503164501.GB8373@stefanha-x1.localdomain> <863e1be1-11cc-816b-896d-3954427e98f3@13byte.com> <20190506052715.vkdopunuauyhl22m@sirius.home.kraxel.org> <7ac2ae97-bcb7-22cc-272a-723e7209910c@13byte.com> <20190509122710.rfhfnhqez2u7inju@sirius.home.kraxel.org> <5d316321-2c48-342b-f2ce-359e3596dae0@opensynergy.com> <20190510121656.3ab7w5xef6io764o@sirius.home.kraxel.org> <76D732A88286A1478FFA94B453B715C1EEA25DD4@MXS02.open-synergy.com> <20190510154824.GJ22311@stefanha-x1.localdomain> <76D732A88286A1478FFA94B453B715C1EEA25EB1@MXS02.open-synergy.com> <91bb7417-fc62-27e6-95a7-d5588699d5e1@13byte.com> From: Matti Moell Message-ID: <07e218fa-1496-721c-7651-59c492d021d8@opensynergy.com> Date: Sun, 12 May 2019 22:01:43 +0200 MIME-Version: 1.0 In-Reply-To: <91bb7417-fc62-27e6-95a7-d5588699d5e1@13byte.com> Content-Type: text/plain; charset="iso-8859-2" Content-Language: en-US Content-Transfer-Encoding: quoted-printable Subject: Re: [virtio-dev] Request for a new device number for a virtio-audio device. To: Marco Martinelli - 13Byte srl , Anton Yakovlev , Stefan Hajnoczi , "virtio-dev@lists.oasis-open.org" Cc: Gerd Hoffmann , Mikhail Golubev , =?UTF-8?B?S8WRdsOhZ8OzIFpvbHTDoW4=?= List-ID: Hi Marco, On 11.05.19 22:49, Marco Martinelli - 13Byte srl wrote: > Wow, it seems like you guys from opensinergy beat me on time. Nice job, > congratulations! Thanks a lot, I think out main problem was that we kept it under the covers for so long. > > Your work is way ahead of mine, so much that I'm thinking of stepping > aside and letting you do the specifications, while experimenting on my > code privately just for the fun of it. > Just a couple of questions. > You mentioned that the PoC was tested on Linux and Windows 10. I presume > these are the guest OSs. For us, Linux is the primary guest OS at the moment. > On the host side are you working on qemu or another hypervisor? > Besides contributing to the specifications, will you open source the > actual implementation? The host side is another hypervisor. > From your website I see you work in the automotive business. Will your > implementation be automotive oriented or general purpose? > My idea was to support the general public and in particular the gamers > and the musicians with my project. I want to be sure that these > categories will be supported. Well, virtio is general purpose and so should all devices, even if we use it in automotive contexts. TBH, automotive requirements aren't that different from gaming or music production. You will often have very strict latency requirements and need support for multiple channels (coherent and non-coherent). So I think the overlap is huge. But, as a matter of fact, I don't think Anton and I know exactly what the general public is interested in so, your help would be very appreciated here. > The reason I'm asking these questions is to see if it makes sense for me > to keep working on this project, perhaps to implement the specifications > proposed by you, or if you're already taking care of everything I was > interested in implementing. It definitely makes sense for you to keep working on this, I believe that we might not have the time at the moment to work on a full qemu implementation and having an independent implementation of the device side would be pretty awesome. We plan to send patches for the device driver in Linux in the near future and we might even be able to share the windows one (Anton should know). Cheers, Matti ---- Please mind our privacy notice pursuant to Art. 13 GDPR. // Unsere= Hinweise zum Datenschutz gem. Art. 13 DSGVO finden Sie hier. --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: virtio-dev-return-5742-cohuck=redhat.com@lists.oasis-open.org Sender: List-Post: List-Help: List-Unsubscribe: List-Subscribe: Received: from lists.oasis-open.org (oasis.ws5.connectedcommunity.org [10.110.1.242]) by lists.oasis-open.org (Postfix) with ESMTP id 770A8985E2A for ; Tue, 14 May 2019 13:45:01 +0000 (UTC) Date: Tue, 14 May 2019 14:44:48 +0100 From: Stefan Hajnoczi Message-ID: <20190514134448.GB6555@stefanha-x1.localdomain> References: <20190503164501.GB8373@stefanha-x1.localdomain> <863e1be1-11cc-816b-896d-3954427e98f3@13byte.com> <20190506052715.vkdopunuauyhl22m@sirius.home.kraxel.org> <7ac2ae97-bcb7-22cc-272a-723e7209910c@13byte.com> <20190509122710.rfhfnhqez2u7inju@sirius.home.kraxel.org> <5d316321-2c48-342b-f2ce-359e3596dae0@opensynergy.com> <20190510121656.3ab7w5xef6io764o@sirius.home.kraxel.org> <76D732A88286A1478FFA94B453B715C1EEA25DD4@MXS02.open-synergy.com> <20190510154824.GJ22311@stefanha-x1.localdomain> <76D732A88286A1478FFA94B453B715C1EEA25EB1@MXS02.open-synergy.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="zx4FCpZtqtKETZ7O" Content-Disposition: inline In-Reply-To: <76D732A88286A1478FFA94B453B715C1EEA25EB1@MXS02.open-synergy.com> Subject: Re: [virtio-dev] Request for a new device number for a virtio-audio device. To: Anton Yakovlev Cc: Gerd Hoffmann , Mikhail Golubev , Marco Martinelli - 13Byte srl , "virtio-dev@lists.oasis-open.org" , =?utf-8?B?S8WRdsOhZ8OzIFpvbHTDoW4=?= List-ID: --zx4FCpZtqtKETZ7O Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, May 10, 2019 at 05:13:26PM +0000, Anton Yakovlev wrote: > > Shared memory isn't a native concept to VIRTIO. The device and the > > driver don't assume shared memory access in the general case (i.e. > > virtqueue buffers could even be copied and virtio-blk, virtio-net, etc > > would still work!). > > > > There is currently a spec extension on the mailing list to add Shared > > Memory Resources to VIRTIO and new device types will use it. However, I > > don't think this is necessary for this use case. >=20 > Yes, we are awared about VIRTIO and shared memory relationships. Our orig= inal propose was to support classic way of communications by default. And, = thanks to your comments, it can be further improved. >=20 > But there's one issue. An audio device is a real-time device. It has expl= icit hard deadline. And there're many factors helping an audio device to fa= il to meet the deadline due to virtualization overhead. And in that sense a= virtual audio device differs from each and every other virtual devices. If= a block device becomes slower - not a big deal, if a network device become= s slower - not a big deal, if a GPU device starts to skip frames - not very= nice, but also not a big deal. But if an audio device starts to skip frame= s - it's a big problem, and device is nonfunctional as a matter of fact. Go= od audio device implementation must met two criterias: >=20 > 1. Low latency > 2. No frame dropping at all >=20 > All I want to say is that any queue-based approach can not guaranty corre= ct functionality to an audio device for all possible use cases. Because a q= ueue has its natural limitations: either in terms of additional latency due= to queue notifications, or due to queue limited size. And an audio device = eventually will hit one of them for some application. It means, we can not = support some cases, which works pretty fine in native operating systems. Bu= t such limitations are artificial ones due, again, using a queue for data t= ransfers. In case of shared memory such limitations are just gone. >=20 > So, our proposal is to support classic way of communications by default a= nd 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 p= ossible 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? If not, please explain the shared memory approach and how it is better. Stefan --zx4FCpZtqtKETZ7O Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhpWov9P5fNqsNXdanKSrs4Grc8gFAlzaxk8ACgkQnKSrs4Gr c8gPGAf9GufnVe83Q0SDeOMGCr6+IkUjjhirmMXB52x+3tWXntFW1PSas9T0h+Q2 i/E/eCSQBdcR1N6cepmgHfTXUYWN0wDZwbwIR9kkRS90asVOpYs+E+0srg90i6qY Uea6vf9/MMCYrQIP2YQNCTqC9VPTkkMLeZJFx+0lZ26hOd0CUCUJsyupFkbAcveQ ouna0y5uwZgW5tBrkuA0gPC5frgwVfDHA0HqUbhsUJTIJB+n6n/0O7NAM+Rot+ai vO/N+kr1fGzYywVKxkDXDCBEiQQgii/CP4RKoEUW7h5qbtbLsvIz17nTZyI0Kb3y zVRSxA0xfYwgk56xdUiEjrMyAF+R5g== =oxAN -----END PGP SIGNATURE----- --zx4FCpZtqtKETZ7O-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: virtio-dev-return-5747-cohuck=redhat.com@lists.oasis-open.org Sender: List-Post: List-Help: List-Unsubscribe: List-Subscribe: Received: from lists.oasis-open.org (oasis.ws5.connectedcommunity.org [10.110.1.242]) by lists.oasis-open.org (Postfix) with ESMTP id 6E78A985E56 for ; Wed, 15 May 2019 06:31:17 +0000 (UTC) From: Anton Yakovlev Date: Wed, 15 May 2019 06:30:45 +0000 Message-ID: <76D732A88286A1478FFA94B453B715C1EEA27A2B@MXS02.open-synergy.com> References: <20190503164501.GB8373@stefanha-x1.localdomain> <863e1be1-11cc-816b-896d-3954427e98f3@13byte.com> <20190506052715.vkdopunuauyhl22m@sirius.home.kraxel.org> <7ac2ae97-bcb7-22cc-272a-723e7209910c@13byte.com> <20190509122710.rfhfnhqez2u7inju@sirius.home.kraxel.org> <5d316321-2c48-342b-f2ce-359e3596dae0@opensynergy.com> <20190510121656.3ab7w5xef6io764o@sirius.home.kraxel.org> <76D732A88286A1478FFA94B453B715C1EEA25DD4@MXS02.open-synergy.com> <20190510154824.GJ22311@stefanha-x1.localdomain> <76D732A88286A1478FFA94B453B715C1EEA25EB1@MXS02.open-synergy.com>,<20190514134448.GB6555@stefanha-x1.localdomain> In-Reply-To: <20190514134448.GB6555@stefanha-x1.localdomain> Content-Language: en-US Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: RE: [virtio-dev] Request for a new device number for a virtio-audio device. To: Stefan Hajnoczi Cc: Gerd Hoffmann , Mikhail Golubev , Marco Martinelli - 13Byte srl , "virtio-dev@lists.oasis-open.org" , =?iso-8859-2?Q?K=F5v=E1g=F3_Zolt=E1n?= List-ID: >> 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 n= umber 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 pursuant to Art. 13 GDPR. // Unsere= Hinweise zum Datenschutz gem. Art. 13 DSGVO finden Sie hier. COQOS Hypervisor certified by T=DCV S=DCD [COQOS Hypervisor certified by T=DCV S=DCD] --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: virtio-dev-return-5748-cohuck=redhat.com@lists.oasis-open.org Sender: List-Post: List-Help: List-Unsubscribe: List-Subscribe: Received: from lists.oasis-open.org (oasis.ws5.connectedcommunity.org [10.110.1.242]) by lists.oasis-open.org (Postfix) with ESMTP id 14D97985E56 for ; Wed, 15 May 2019 08:32:19 +0000 (UTC) From: Anton Yakovlev Date: Wed, 15 May 2019 08:31:54 +0000 Message-ID: <76D732A88286A1478FFA94B453B715C1EEA27AB6@MXS02.open-synergy.com> References: <20190503164501.GB8373@stefanha-x1.localdomain> <863e1be1-11cc-816b-896d-3954427e98f3@13byte.com> <20190506052715.vkdopunuauyhl22m@sirius.home.kraxel.org> <7ac2ae97-bcb7-22cc-272a-723e7209910c@13byte.com> <20190509122710.rfhfnhqez2u7inju@sirius.home.kraxel.org> <5d316321-2c48-342b-f2ce-359e3596dae0@opensynergy.com> <20190510121656.3ab7w5xef6io764o@sirius.home.kraxel.org> <76D732A88286A1478FFA94B453B715C1EEA25DD4@MXS02.open-synergy.com> <20190510154824.GJ22311@stefanha-x1.localdomain> <76D732A88286A1478FFA94B453B715C1EEA25EB1@MXS02.open-synergy.com>,<20190514134448.GB6555@stefanha-x1.localdomain>,<76D732A88286A1478FFA94B453B715C1EEA27A2B@MXS02.open-synergy.com> In-Reply-To: <76D732A88286A1478FFA94B453B715C1EEA27A2B@MXS02.open-synergy.com> Content-Language: en-US Content-Type: multipart/mixed; boundary="_002_76D732A88286A1478FFA94B453B715C1EEA27AB6MXS02opensynerg_" MIME-Version: 1.0 Subject: RE: [virtio-dev] Request for a new device number for a virtio-audio device. To: Stefan Hajnoczi , Gerd Hoffmann , Mikhail Golubev , Marco Martinelli - 13Byte srl , "virtio-dev@lists.oasis-open.org" , =?iso-8859-2?Q?K=F5v=E1g=F3_Zolt=E1n?= List-ID: --_002_76D732A88286A1478FFA94B453B715C1EEA27AB6MXS02opensynerg_ Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Hi all, I updated the header file according to the comments and overall flow of the= discussion (see attachment). Also I replaced defines with enumerations and 1. Added new PCM request type for assigning particular virtual queue for pa= rticular substream. 2. Removed the rewind/forward request types, since these are actually not n= eeded. Looking forward for your comments. Anton Yakovlev Senior Software Engineer OpenSynergy GmbH Rotherstr. 20, 10245 Berlin www.opensynergy.com Please mind our privacy notice pursuant to Art. 13 GDPR. // Unsere= Hinweise zum Datenschutz gem. Art. 13 DSGVO finden Sie hier. COQOS Hypervisor certified by T=DCV S=DCD [COQOS Hypervisor certified by T=DCV S=DCD] --_002_76D732A88286A1478FFA94B453B715C1EEA27AB6MXS02opensynerg_ Content-Type: text/x-chdr; name="virtio_snd.h" Content-Description: virtio_snd.h Content-Disposition: attachment; filename="virtio_snd.h"; size=14175; creation-date="Wed, 15 May 2019 08:30:40 GMT"; modification-date="Wed, 15 May 2019 08:30:40 GMT" Content-Transfer-Encoding: base64 LyoKICogQ29weXJpZ2h0IChDKSAyMDE5ICBPcGVuU3luZXJneSBHbWJICiAqCiAqIFRoaXMgaGVh ZGVyIGlzIEJTRCBsaWNlbnNlZCBzbyBhbnlvbmUgY2FuIHVzZSB0aGUgZGVmaW5pdGlvbnMgdG8K ICogaW1wbGVtZW50IGNvbXBhdGlibGUgZHJpdmVycy9zZXJ2ZXJzLgogKgogKiBSZWRpc3RyaWJ1 dGlvbiBhbmQgdXNlIGluIHNvdXJjZSBhbmQgYmluYXJ5IGZvcm1zLCB3aXRoIG9yIHdpdGhvdXQK ICogbW9kaWZpY2F0aW9uLCBhcmUgcGVybWl0dGVkIHByb3ZpZGVkIHRoYXQgdGhlIGZvbGxvd2lu ZyBjb25kaXRpb25zCiAqIGFyZSBtZXQ6CiAqIDEuIFJlZGlzdHJpYnV0aW9ucyBvZiBzb3VyY2Ug Y29kZSBtdXN0IHJldGFpbiB0aGUgYWJvdmUgY29weXJpZ2h0CiAqICAgIG5vdGljZSwgdGhpcyBs aXN0IG9mIGNvbmRpdGlvbnMgYW5kIHRoZSBmb2xsb3dpbmcgZGlzY2xhaW1lci4KICogMi4gUmVk aXN0cmlidXRpb25zIGluIGJpbmFyeSBmb3JtIG11c3QgcmVwcm9kdWNlIHRoZSBhYm92ZSBjb3B5 cmlnaHQKICogICAgbm90aWNlLCB0aGlzIGxpc3Qgb2YgY29uZGl0aW9ucyBhbmQgdGhlIGZvbGxv d2luZyBkaXNjbGFpbWVyIGluIHRoZQogKiAgICBkb2N1bWVudGF0aW9uIGFuZC9vciBvdGhlciBt YXRlcmlhbHMgcHJvdmlkZWQgd2l0aCB0aGUgZGlzdHJpYnV0aW9uLgogKiAzLiBOZWl0aGVyIHRo ZSBuYW1lIG9mIE9wZW5TeW5lcmd5IEdtYkggbm9yIHRoZSBuYW1lcyBvZiBpdHMgY29udHJpYnV0 b3JzCiAqICAgIG1heSBiZSB1c2VkIHRvIGVuZG9yc2Ugb3IgcHJvbW90ZSBwcm9kdWN0cyBkZXJp dmVkIGZyb20gdGhpcyBzb2Z0d2FyZQogKiAgICB3aXRob3V0IHNwZWNpZmljIHByaW9yIHdyaXR0 ZW4gcGVybWlzc2lvbi4KICogVEhJUyBTT0ZUV0FSRSBJUyBQUk9WSURFRCBCWSBUSEUgQ09QWVJJ R0hUIEhPTERFUlMgQU5EIENPTlRSSUJVVE9SUwogKiBgYEFTIElTJycgQU5EIEFOWSBFWFBSRVNT IE9SIElNUExJRUQgV0FSUkFOVElFUywgSU5DTFVESU5HLCBCVVQgTk9UCiAqIExJTUlURUQgVE8s IFRIRSBJTVBMSUVEIFdBUlJBTlRJRVMgT0YgTUVSQ0hBTlRBQklMSVRZIEFORCBGSVRORVNTCiAq IEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRSBBUkUgRElTQ0xBSU1FRC4gIElOIE5PIEVWRU5UIFNI QUxMIElCTSBPUgogKiBDT05UUklCVVRPUlMgQkUgTElBQkxFIEZPUiBBTlkgRElSRUNULCBJTkRJ UkVDVCwgSU5DSURFTlRBTCwKICogU1BFQ0lBTCwgRVhFTVBMQVJZLCBPUiBDT05TRVFVRU5USUFM IERBTUFHRVMgKElOQ0xVRElORywgQlVUIE5PVAogKiBMSU1JVEVEIFRPLCBQUk9DVVJFTUVOVCBP RiBTVUJTVElUVVRFIEdPT0RTIE9SIFNFUlZJQ0VTOyBMT1NTIE9GCiAqIFVTRSwgREFUQSwgT1Ig UFJPRklUUzsgT1IgQlVTSU5FU1MgSU5URVJSVVBUSU9OKSBIT1dFVkVSIENBVVNFRCBBTkQKICog T04gQU5ZIFRIRU9SWSBPRiBMSUFCSUxJVFksIFdIRVRIRVIgSU4gQ09OVFJBQ1QsIFNUUklDVCBM SUFCSUxJVFksCiAqIE9SIFRPUlQgKElOQ0xVRElORyBORUdMSUdFTkNFIE9SIE9USEVSV0lTRSkg QVJJU0lORyBJTiBBTlkgV0FZIE9VVAogKiBPRiBUSEUgVVNFIE9GIFRISVMgU09GVFdBUkUsIEVW RU4gSUYgQURWSVNFRCBPRiBUSEUgUE9TU0lCSUxJVFkgT0YKICogU1VDSCBEQU1BR0UuICovCgoj aWZuZGVmIFZJUlRJT19TTkRfSUZfSAojZGVmaW5lIFZJUlRJT19TTkRfSUZfSAoKI2luY2x1ZGUg PGxpbnV4L3ZpcnRpb190eXBlcy5oPgoKLyoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioKICogQ09NTU9O IERFRklOSVRJT05TCiAqLwoKLyogYSBjb25maWd1cmF0aW9uIHNwYWNlICovCnN0cnVjdCB2aXJ0 aW9fc25kX2NvbmZpZwp7CiAgICAvKiBtYXhpbXVtICMgb2YgYXZhaWxhYmxlIHZpcnR1YWwgcXVl dWVzIChpbmNsdWRpbmcgdGhlIGNvbnRyb2wgcXVldWUpICovCiAgICBfX3ZpcnRpbzMyIG5xdWV1 ZXM7Cn07CgovKiBzdXBwb3J0ZWQgZnVuY3Rpb24gdHlwZXMgKi8KZW51bQp7CiAgICBWSVJUSU9f U05EX0ZOX0JBU0UsCiAgICBWSVJUSU9fU05EX0ZOX1BDTQp9OwoKLyogc3VwcG9ydGVkIGRlc2Ny aXB0b3IgdHlwZXMgKi8KZW51bQp7CiAgICBWSVJUSU9fU05EX0RFU0NfUENNLAogICAgVklSVElP X1NORF9ERVNDX1BDTV9TVFJFQU0KfTsKCi8qIHN1cHBvcnRlZCBjb250cm9sIHJlcXVlc3QgdHlw ZXMgKi8KZW51bQp7CiAgICAvKiAtLS0gYmFzZSByZXF1ZXN0IHR5cGVzIC0tLSAqLwogICAgVklS VElPX1NORF9CQVNFX1JfR0VUX0NGRywKICAgIC8qIC0tLSBwY20gcmVxdWVzdCB0eXBlcyAtLS0g Ki8KICAgIFZJUlRJT19TTkRfUENNX1JfR0VUX0ZFQVRVUkUgPSAweDEwMDAsCiAgICBWSVJUSU9f U05EX1BDTV9SX1NFVF9GRUFUVVJFLAogICAgVklSVElPX1NORF9QQ01fUl9TRVRfUVVFVUUsCiAg ICBWSVJUSU9fU05EX1BDTV9SX1NFVF9GT1JNQVQsCiAgICBWSVJUSU9fU05EX1BDTV9SX1BSRVBB UkUsCiAgICBWSVJUSU9fU05EX1BDTV9SX1NUQVJULAogICAgVklSVElPX1NORF9QQ01fUl9TVE9Q LAogICAgVklSVElPX1NORF9QQ01fUl9QQVVTRSwKICAgIFZJUlRJT19TTkRfUENNX1JfVU5QQVVT RQp9OwoKLyogc3VwcG9ydGVkIGVycm9yIGNvZGVzICovCmVudW0KewogICAgLyogLS0tIGdlbmVy aWMgZXJyb3IgY29kZXMgLS0tICovCiAgICAvKiBubyBlcnJvcnMgKi8KICAgIFZJUlRJT19TTkRf RV9TVUNDRVNTLAogICAgLyogYW4gdW5kZWZpbmVkIGVycm9yICovCiAgICBWSVJUSU9fU05EX0Vf R0VORVJBTCwKICAgIC8qIG5vdCBzdXBwb3J0ZWQgaW5wdXQgcGFyYW1ldGVyKHMpICovCiAgICBW SVJUSU9fU05EX0VfTk9UU1VQUE9SVEVELAogICAgLyogaW52YWxpZCBpbnB1dCBwYXJhbWV0ZXIo cykgKi8KICAgIFZJUlRJT19TTkRfRV9JTlZBTElELAogICAgLyogSS9PIGVycm9yICovCiAgICBW SVJUSU9fU05EX0VfSU8sCiAgICAvKiAtLS0gcGNtIGVycm9yIGNvZGVzIC0tLSAqLwogICAgVklS VElPX1NORF9QQ01fRV9OT1RfUkVBRFkgPSAweDEwMDAKfTsKCi8qIGEgZ2VuZXJpYyByZXF1ZXN0 IGhlYWRlciAqLwpzdHJ1Y3QgdmlydGlvX3NuZF9yZXEKewogICAgX192aXJ0aW8xNiBmdW5jdGlv bjsKICAgIF9fdmlydGlvMTYgcmVxdWVzdDsKfTsKCi8qIGEgZ2VuZXJpYyByZXNwb25zZSBoZWFk ZXIgKi8Kc3RydWN0IHZpcnRpb19zbmRfcnNwCnsKICAgIF9fdmlydGlvMzIgc3RhdHVzOyAvKiBW SVJUSU9fU05EX0VfWFhYICovCn07CgovKiBhIGdlbmVyaWMgZGVzY3JpcHRvciAqLwpzdHJ1Y3Qg dmlydGlvX3NuZF9nZW5lcmljX2Rlc2MKewogICAgX191OCBsZW5ndGg7CiAgICBfX3U4IHR5cGU7 CiAgICBfX3UxNiBwYWRkaW5nOwp9OwoKLyoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioKICogQkFTRSBG VU5DVElPTiBERUZJTklUSU9OUwogKi8KCi8qIGEgbWF4aW11bSBwb3NzaWJsZSBjb25maWd1cmF0 aW9uIGRhdGEgc2l6ZSAoaW4gYnl0ZXMpICovCiNkZWZpbmUgVklSVElPX1NORF9CQVNFX0NGR19N QVhfU0laRSAgICAxMDI0CgovKiBhIHJlc3BvbnNlIGNvbnRhaW5pbmcgZGV2aWNlIGNvbmZpZ3Vy YXRpb24gKi8Kc3RydWN0IHZpcnRpb19zbmRfYmFzZV9jb25maWd1cmF0aW9uCnsKICAgIHN0cnVj dCB2aXJ0aW9fc25kX3JzcCBoZHI7CiAgICAvKiBzaXplIGluIGJ5dGVzIG9mIGNvbmZpZ3VyYXRp b24gZGF0YSAqLwogICAgX192aXJ0aW8zMiBsZW5ndGg7CiAgICAvKiBjb25maWd1cmF0aW9uIGRh dGEgKi8KICAgIF9fdTggZGF0YVtWSVJUSU9fU05EX0JBU0VfQ0ZHX01BWF9TSVpFXTsKfTsKCi8q KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqCiAqIFBDTSBGVU5DVElPTiBERUZJTklUSU9OUwogKi8KCi8q IHN1cHBvcnRlZCBQQ00gc3RyZWFtIHR5cGVzICovCmVudW0KewogICAgVklSVElPX1NORF9QQ01f VF9QTEFZQkFDSywKICAgIFZJUlRJT19TTkRfUENNX1RfQ0FQVFVSRQp9OwoKLyogc3VwcG9ydGVk IFBDTSBzdHJlYW0gZmVhdHVyZXMgKi8KZW51bQp7CiAgICBWSVJUSU9fU05EX1BDTV9GRUFUX1VQ REFURV9GUkVRVUVOQ1ksCiAgICBWSVJUSU9fU05EX1BDTV9GRUFUX0NIQU5ORUxfTUFQCn07Cgoj ZGVmaW5lIFZJUlRJT19TTkRfUENNX0ZFQVRCSVQoYml0KSAgICAgKDFVIDw8IFZJUlRJT19TTkRf UENNX0ZFQVRfICMjIGJpdCkKCmVudW0KewogICAgVklSVElPX1NORF9QQ01fRkVBVEJJVF9VUERB VEVfRlJFUVVFTkNZID0KICAgICAgICBWSVJUSU9fU05EX1BDTV9GRUFUQklUKFVQREFURV9GUkVR VUVOQ1kpLAogICAgVklSVElPX1NORF9QQ01fRkVBVEJJVF9DSEFOTkVMX01BUCA9CiAgICAgICAg VklSVElPX1NORF9QQ01fRkVBVEJJVChDSEFOTkVMX01BUCkKfTsKCi8qIHN1cHBvcnRlZCBQQ00g c2FtcGxlIGZvcm1hdHMgKi8KZW51bQp7CiAgICBWSVJUSU9fU05EX1BDTV9GTVRfUzgsCiAgICBW SVJUSU9fU05EX1BDTV9GTVRfVTgsCiAgICBWSVJUSU9fU05EX1BDTV9GTVRfUzE2LAogICAgVklS VElPX1NORF9QQ01fRk1UX1UxNiwKICAgIFZJUlRJT19TTkRfUENNX0ZNVF9TMjQsCiAgICBWSVJU SU9fU05EX1BDTV9GTVRfVTI0LAogICAgVklSVElPX1NORF9QQ01fRk1UX1MzMiwKICAgIFZJUlRJ T19TTkRfUENNX0ZNVF9VMzIsCiAgICBWSVJUSU9fU05EX1BDTV9GTVRfRkxPQVQsCiAgICBWSVJU SU9fU05EX1BDTV9GTVRfRkxPQVQ2NCwKICAgIFZJUlRJT19TTkRfUENNX0ZNVF9TMjAsCiAgICBW SVJUSU9fU05EX1BDTV9GTVRfVTIwLAogICAgVklSVElPX1NORF9QQ01fRk1UX1MyNF8zLAogICAg VklSVElPX1NORF9QQ01fRk1UX1UyNF8zLAogICAgVklSVElPX1NORF9QQ01fRk1UX1MyMF8zLAog ICAgVklSVElPX1NORF9QQ01fRk1UX1UyMF8zLAogICAgVklSVElPX1NORF9QQ01fRk1UX1MxOF8z LAogICAgVklSVElPX1NORF9QQ01fRk1UX1UxOF8zCn07CgojZGVmaW5lIFZJUlRJT19TTkRfUENN X0ZNVEJJVChiaXQpICAgICAgKDFVTEwgPDwgVklSVElPX1NORF9QQ01fRk1UXyAjIyBiaXQpCgpl bnVtCnsKICAgIFZJUlRJT19TTkRfUENNX0ZNVEJJVF9TOCA9IFZJUlRJT19TTkRfUENNX0ZNVEJJ VChTOCksCiAgICBWSVJUSU9fU05EX1BDTV9GTVRCSVRfVTggPSBWSVJUSU9fU05EX1BDTV9GTVRC SVQoVTgpLAogICAgVklSVElPX1NORF9QQ01fRk1UQklUX1MxNiA9IFZJUlRJT19TTkRfUENNX0ZN VEJJVChTMTYpLAogICAgVklSVElPX1NORF9QQ01fRk1UQklUX1UxNiA9IFZJUlRJT19TTkRfUENN X0ZNVEJJVChVMTYpLAogICAgVklSVElPX1NORF9QQ01fRk1UQklUX1MyNCA9IFZJUlRJT19TTkRf UENNX0ZNVEJJVChTMjQpLAogICAgVklSVElPX1NORF9QQ01fRk1UQklUX1UyNCA9IFZJUlRJT19T TkRfUENNX0ZNVEJJVChVMjQpLAogICAgVklSVElPX1NORF9QQ01fRk1UQklUX1MzMiA9IFZJUlRJ T19TTkRfUENNX0ZNVEJJVChTMzIpLAogICAgVklSVElPX1NORF9QQ01fRk1UQklUX1UzMiA9IFZJ UlRJT19TTkRfUENNX0ZNVEJJVChVMzIpLAogICAgVklSVElPX1NORF9QQ01fRk1UQklUX0ZMT0FU ID0gVklSVElPX1NORF9QQ01fRk1UQklUKEZMT0FUKSwKICAgIFZJUlRJT19TTkRfUENNX0ZNVEJJ VF9GTE9BVDY0ID0gVklSVElPX1NORF9QQ01fRk1UQklUKEZMT0FUNjQpLAogICAgVklSVElPX1NO RF9QQ01fRk1UQklUX1MyMCA9IFZJUlRJT19TTkRfUENNX0ZNVEJJVChTMjApLAogICAgVklSVElP X1NORF9QQ01fRk1UQklUX1UyMCA9IFZJUlRJT19TTkRfUENNX0ZNVEJJVChVMjApLAogICAgVklS VElPX1NORF9QQ01fRk1UQklUX1MyNF8zID0gVklSVElPX1NORF9QQ01fRk1UQklUKFMyNF8zKSwK ICAgIFZJUlRJT19TTkRfUENNX0ZNVEJJVF9VMjRfMyA9IFZJUlRJT19TTkRfUENNX0ZNVEJJVChV MjRfMyksCiAgICBWSVJUSU9fU05EX1BDTV9GTVRCSVRfUzIwXzMgPSBWSVJUSU9fU05EX1BDTV9G TVRCSVQoUzIwXzMpLAogICAgVklSVElPX1NORF9QQ01fRk1UQklUX1UyMF8zID0gVklSVElPX1NO RF9QQ01fRk1UQklUKFUyMF8zKSwKICAgIFZJUlRJT19TTkRfUENNX0ZNVEJJVF9TMThfMyA9IFZJ UlRJT19TTkRfUENNX0ZNVEJJVChTMThfMyksCiAgICBWSVJUSU9fU05EX1BDTV9GTVRCSVRfVTE4 XzMgPSBWSVJUSU9fU05EX1BDTV9GTVRCSVQoVTE4XzMpCn07CgovKiBzdXBwb3J0ZWQgUENNIGZy YW1lIHJhdGVzICovCmVudW0KewogICAgVklSVElPX1NORF9QQ01fUkFURV84MDAwLAogICAgVklS VElPX1NORF9QQ01fUkFURV8xMTAyNSwKICAgIFZJUlRJT19TTkRfUENNX1JBVEVfMTYwMDAsCiAg ICBWSVJUSU9fU05EX1BDTV9SQVRFXzIyMDUwLAogICAgVklSVElPX1NORF9QQ01fUkFURV8zMjAw MCwKICAgIFZJUlRJT19TTkRfUENNX1JBVEVfNDQxMDAsCiAgICBWSVJUSU9fU05EX1BDTV9SQVRF XzQ4MDAwLAogICAgVklSVElPX1NORF9QQ01fUkFURV82NDAwMCwKICAgIFZJUlRJT19TTkRfUENN X1JBVEVfODgyMDAsCiAgICBWSVJUSU9fU05EX1BDTV9SQVRFXzk2MDAwLAogICAgVklSVElPX1NO RF9QQ01fUkFURV8xNzY0MDAsCiAgICBWSVJUSU9fU05EX1BDTV9SQVRFXzE5MjAwMAp9OwoKI2Rl ZmluZSBWSVJUSU9fU05EX1BDTV9SQVRFQklUKGJpdCkgICAgICgxVSA8PCBWSVJUSU9fU05EX1BD TV9SQVRFXyAjIyBiaXQpCgplbnVtCnsKICAgIFZJUlRJT19TTkRfUENNX1JBVEVCSVRfODAwMCA9 IFZJUlRJT19TTkRfUENNX1JBVEVCSVQoODAwMCksCiAgICBWSVJUSU9fU05EX1BDTV9SQVRFQklU XzExMDI1ID0gVklSVElPX1NORF9QQ01fUkFURUJJVCgxMTAyNSksCiAgICBWSVJUSU9fU05EX1BD TV9SQVRFQklUXzE2MDAwID0gVklSVElPX1NORF9QQ01fUkFURUJJVCgxNjAwMCksCiAgICBWSVJU SU9fU05EX1BDTV9SQVRFQklUXzIyMDUwID0gVklSVElPX1NORF9QQ01fUkFURUJJVCgyMjA1MCks CiAgICBWSVJUSU9fU05EX1BDTV9SQVRFQklUXzMyMDAwID0gVklSVElPX1NORF9QQ01fUkFURUJJ VCgzMjAwMCksCiAgICBWSVJUSU9fU05EX1BDTV9SQVRFQklUXzQ0MTAwID0gVklSVElPX1NORF9Q Q01fUkFURUJJVCg0NDEwMCksCiAgICBWSVJUSU9fU05EX1BDTV9SQVRFQklUXzQ4MDAwID0gVklS VElPX1NORF9QQ01fUkFURUJJVCg0ODAwMCksCiAgICBWSVJUSU9fU05EX1BDTV9SQVRFQklUXzY0 MDAwID0gVklSVElPX1NORF9QQ01fUkFURUJJVCg2NDAwMCksCiAgICBWSVJUSU9fU05EX1BDTV9S QVRFQklUXzg4MjAwID0gVklSVElPX1NORF9QQ01fUkFURUJJVCg4ODIwMCksCiAgICBWSVJUSU9f U05EX1BDTV9SQVRFQklUXzk2MDAwID0gVklSVElPX1NORF9QQ01fUkFURUJJVCg5NjAwMCksCiAg ICBWSVJUSU9fU05EX1BDTV9SQVRFQklUXzE3NjQwMCA9IFZJUlRJT19TTkRfUENNX1JBVEVCSVQo MTc2NDAwKSwKICAgIFZJUlRJT19TTkRfUENNX1JBVEVCSVRfMTkyMDAwID0gVklSVElPX1NORF9Q Q01fUkFURUJJVCgxOTIwMDApCn07CgovKiBQQ00gY2hhbm5lbCBtYXAgZGVmaW5pdGlvbnMgKi8K CmVudW0KewogICAgLyogQWxsIGNoYW5uZWxzIGhhdmUgZml4ZWQgY2hhbm5lbCBwb3NpdGlvbnMg Ki8KICAgIFZJUlRJT19TTkRfUENNX0NITUFQX0ZJWEVELAogICAgLyogQWxsIGNoYW5uZWxzIGFy ZSBzd2FwcGFibGUgKGUuZy4ge0ZML0ZSL1JML1JSfSAtPiB7UlIvUkwvRlIvRkx9KSAqLwogICAg VklSVElPX1NORF9QQ01fQ0hNQVBfVkFSSUFCTEUsCiAgICAvKiBPbmx5IHBhaXItd2lzZSBjaGFu bmVscyBhcmUgc3dhcHBhYmxlIChlLmcuIHtGTC9GUi9STC9SUn0gLT4ge1JML1JSL0ZML0ZSfSkg Ki8KICAgIFZJUlRJT19TTkRfUENNX0NITUFQX1BBSVJFRAp9OwoKLyogU3RhbmRhcmQgY2hhbm5l bCBwb3NpdGlvbiBkZWZpbml0aW9uICovCmVudW0KewogICAgVklSVElPX1NORF9QQ01fQ0hfTk9O RSwgICAgIC8qIHVuZGVmaW5lZCAqLwogICAgVklSVElPX1NORF9QQ01fQ0hfTkEsICAgICAgIC8q IHNpbGVudCAqLwogICAgVklSVElPX1NORF9QQ01fQ0hfTU9OTywgICAgIC8qIG1vbm8gc3RyZWFt ICovCiAgICBWSVJUSU9fU05EX1BDTV9DSF9GTCwgICAgICAgLyogZnJvbnQgbGVmdCAqLwogICAg VklSVElPX1NORF9QQ01fQ0hfRlIsICAgICAgIC8qIGZyb250IHJpZ2h0ICovCiAgICBWSVJUSU9f U05EX1BDTV9DSF9STCwgICAgICAgLyogcmVhciBsZWZ0ICovCiAgICBWSVJUSU9fU05EX1BDTV9D SF9SUiwgICAgICAgLyogcmVhciByaWdodCAqLwogICAgVklSVElPX1NORF9QQ01fQ0hfRkMsICAg ICAgIC8qIGZyb250IGNlbnRlciAqLwogICAgVklSVElPX1NORF9QQ01fQ0hfTEZFLCAgICAgIC8q IGxvdyBmcmVxdWVuY3kgKExGRSkgKi8KICAgIFZJUlRJT19TTkRfUENNX0NIX1NMLCAgICAgICAv KiBzaWRlIGxlZnQgKi8KICAgIFZJUlRJT19TTkRfUENNX0NIX1NSLCAgICAgICAvKiBzaWRlIHJp Z2h0ICovCiAgICBWSVJUSU9fU05EX1BDTV9DSF9SQywgICAgICAgLyogcmVhciBjZW50ZXIgKi8K ICAgIFZJUlRJT19TTkRfUENNX0NIX0ZMQywgICAgICAvKiBmcm9udCBsZWZ0IGNlbnRlciAqLwog ICAgVklSVElPX1NORF9QQ01fQ0hfRlJDLCAgICAgIC8qIGZyb250IHJpZ2h0IGNlbnRlciAqLwog ICAgVklSVElPX1NORF9QQ01fQ0hfUkxDLCAgICAgIC8qIHJlYXIgbGVmdCBjZW50ZXIgKi8KICAg IFZJUlRJT19TTkRfUENNX0NIX1JSQywgICAgICAvKiByZWFyIHJpZ2h0IGNlbnRlciAqLwogICAg VklSVElPX1NORF9QQ01fQ0hfRkxXLCAgICAgIC8qIGZyb250IGxlZnQgd2lkZSAqLwogICAgVklS VElPX1NORF9QQ01fQ0hfRlJXLCAgICAgIC8qIGZyb250IHJpZ2h0IHdpZGUgKi8KICAgIFZJUlRJ T19TTkRfUENNX0NIX0ZMSCwgICAgICAvKiBmcm9udCBsZWZ0IGhpZ2ggKi8KICAgIFZJUlRJT19T TkRfUENNX0NIX0ZDSCwgICAgICAvKiBmcm9udCBjZW50ZXIgaGlnaCAqLwogICAgVklSVElPX1NO RF9QQ01fQ0hfRlJILCAgICAgIC8qIGZyb250IHJpZ2h0IGhpZ2ggKi8KICAgIFZJUlRJT19TTkRf UENNX0NIX1RDLCAgICAgICAvKiB0b3AgY2VudGVyICovCiAgICBWSVJUSU9fU05EX1BDTV9DSF9U RkwsICAgICAgLyogdG9wIGZyb250IGxlZnQgKi8KICAgIFZJUlRJT19TTkRfUENNX0NIX1RGUiwg ICAgICAvKiB0b3AgZnJvbnQgcmlnaHQgKi8KICAgIFZJUlRJT19TTkRfUENNX0NIX1RGQywgICAg ICAvKiB0b3AgZnJvbnQgY2VudGVyICovCiAgICBWSVJUSU9fU05EX1BDTV9DSF9UUkwsICAgICAg LyogdG9wIHJlYXIgbGVmdCAqLwogICAgVklSVElPX1NORF9QQ01fQ0hfVFJSLCAgICAgIC8qIHRv cCByZWFyIHJpZ2h0ICovCiAgICBWSVJUSU9fU05EX1BDTV9DSF9UUkMsICAgICAgLyogdG9wIHJl YXIgY2VudGVyICovCiAgICBWSVJUSU9fU05EX1BDTV9DSF9URkxDLCAgICAgLyogdG9wIGZyb250 IGxlZnQgY2VudGVyICovCiAgICBWSVJUSU9fU05EX1BDTV9DSF9URlJDLCAgICAgLyogdG9wIGZy b250IHJpZ2h0IGNlbnRlciAqLwogICAgVklSVElPX1NORF9QQ01fQ0hfVFNMLCAgICAgIC8qIHRv cCBzaWRlIGxlZnQgKi8KICAgIFZJUlRJT19TTkRfUENNX0NIX1RTUiwgICAgICAvKiB0b3Agc2lk ZSByaWdodCAqLwogICAgVklSVElPX1NORF9QQ01fQ0hfTExGRSwgICAgIC8qIGxlZnQgTEZFICov CiAgICBWSVJUSU9fU05EX1BDTV9DSF9STEZFLCAgICAgLyogcmlnaHQgTEZFICovCiAgICBWSVJU SU9fU05EX1BDTV9DSF9CQywgICAgICAgLyogYm90dG9tIGNlbnRlciAqLwogICAgVklSVElPX1NO RF9QQ01fQ0hfQkxDLCAgICAgIC8qIGJvdHRvbSBsZWZ0IGNlbnRlciAqLwogICAgVklSVElPX1NO RF9QQ01fQ0hfQlJDICAgICAgIC8qIGJvdHRvbSByaWdodCBjZW50ZXIgKi8KfTsKCi8qCiAqIFRo ZSBjaGFubmVsIGlzIHBoYXNlIGludmVydGVkICh0aHVzIHN1bW1pbmcgbGVmdCBhbmQgcmlnaHQg Y2hhbm5lbHMgd291bGQKICogcmVzdWx0IGluIGFsbW9zdCBzaWxlbmNlKS4KICovCmVudW0Kewog ICAgVklSVElPX1NORF9QQ01fQ0hfRl9QSEFTRV9JTlZFUlNFID0gMHgwMQp9OwoKLyogUENNIGZ1 bmN0aW9uIGRlc2NyaXB0b3IgKi8Kc3RydWN0IHZpcnRpb19zbmRfcGNtX2Rlc2MKewogICAgLyog c2l6ZW9mKHN0cnVjdCB2aXJ0aW9fc25kX3BjbV9kZXNjKSAqLwogICAgX191OCBsZW5ndGg7CiAg ICAvKiBWSVJUSU9fU05EX0RFU0NfUENNICovCiAgICBfX3U4IHR5cGU7CiAgICAvKiBhIFBDTSBm dW5jdGlvbiBJRCAoYXNzaWduZWQgYnkgdGhlIGRldmljZSkgKi8KICAgIF9fdTggcGNtX2lkOwog ICAgLyogIyBvZiBQQ00gc3RyZWFtIGRlc2NyaXB0b3JzIGluIHRoZSBjb25maWd1cmF0aW9uIChv bmUgcGVyIHN1cHBvcnRlZCBQQ00gc3RyZWFtIHR5cGUpICovCiAgICBfX3U4IG5zdHJlYW1zOwp9 OwoKLyogUENNIHN0cmVhbSBkZXNjcmlwdG9yICovCnN0cnVjdCB2aXJ0aW9fc25kX3BjbV9zdHJl YW1fZGVzYwp7CiAgICAvKiBzaXplb2Yoc3RydWN0IHZpcnRpb19zbmRfcGNtX3N0cmVhbV9kZXNj KSAqLwogICAgX191OCBsZW5ndGg7CiAgICAvKiBWSVJUSU9fU05EX0RFU0NfUENNX1NUUkVBTSAq LwogICAgX191OCB0eXBlOwogICAgLyogYSBQQ00gc3RyZWFtIHR5cGUgKFZJUlRJT19TTkRfUENN X1RfWFhYKSAqLwogICAgX191OCBzdHJlYW1fdHlwZTsKICAgIC8qICMgb2Ygc3Vic3RyZWFtcyBm b3IgdGhlIHNwZWNpZmllZCBzdHJlYW0gdHlwZSAqLwogICAgX191OCBuc3Vic3RyZWFtczsKICAg IC8qIG1pbmltdW0gIyBvZiBzdXBwb3J0ZWQgY2hhbm5lbHMgKi8KICAgIF9fdTggY2hhbm5lbHNf bWluOwogICAgLyogbWF4aW11bSAjIG9mIHN1cHBvcnRlZCBjaGFubmVscyAqLwogICAgX191OCBj aGFubmVsc19tYXg7CiAgICAvKiBzdXBwb3J0ZWQgUENNIHN0cmVhbSBmZWF0dXJlcyAoVklSVElP X1NORF9QQ01fRkVBVEJJVF9YWFgsIGNhbiBiZSBPUmVkKSAqLwogICAgX191OCBmZWF0dXJlczsK ICAgIC8qICMgb2Ygc3VwcG9ydGVkIGNoYW5uZWwgbWFwcyAqLwogICAgX191OCBuY2htYXBzOwog ICAgLyogc3VwcG9ydGVkIHNhbXBsZSBmb3JtYXRzIChWSVJUSU9fU05EX1BDTV9GTVRCSVRfWFhY LCBjYW4gYmUgT1JlZCkgKi8KICAgIF9fdmlydGlvMzIgZm9ybWF0czsKICAgIC8qIHN1cHBvcnRl ZCBmcmFtZSByYXRlcyAoVklSVElPX1NORF9QQ01fUkFURUJJVF9YWFgsIGNhbiBiZSBPUmVkKSAq LwogICAgX192aXJ0aW8zMiByYXRlczsKfTsKCi8qIFBDTSBzdWJzdHJlYW0gcmVxdWVzdCBoZWFk ZXIgKi8Kc3RydWN0IHZpcnRpb19zbmRfcGNtX2hkcgp7CiAgICAvKiBWSVJUSU9fU05EX0ZOX1BD TSAqLwogICAgX192aXJ0aW8xNiBmdW5jdGlvbjsKICAgIC8qIGEgUENNIHJlcXVlc3QgdHlwZSAo VklSVElPX1NORF9QQ01fUl9YWFgpICovCiAgICBfX3ZpcnRpbzE2IHJlcXVlc3Q7CiAgICAvKiBh IFBDTSBpZGVudGlmaWVyIChhc3NpZ25lZCBpbiBjb25maWd1cmF0aW9uKSAqLwogICAgX191OCBw Y21faWQ7CiAgICAvKiBhIFBDTSBzdHJlYW0gdHlwZSAoVklSVElPX1NORF9QQ01fVF9YWFgpICov CiAgICBfX3U4IHN0cmVhbV90eXBlOwogICAgLyogYSBQQ00gc3Vic3RyZWFtIGlkZW50aWZpZXIg WzAgLi4gdmlydGlvX3NuZF9wY21fc3RyZWFtX2Rlc2M6Om5zdWJzdHJlYW1zIC0gMV0gKi8KICAg IF9fdTggc3Vic3RyZWFtX2lkOwogICAgX191OCBwYWRkaW5nOwp9OwoKLyogZ2V0L3NldCBQQ00g c3Vic3RyZWFtIGZlYXR1cmUgKi8Kc3RydWN0IHZpcnRpb19zbmRfcGNtX2ZlYXR1cmUKewogICAg LyogVklSVElPX1NORF9GTl9QQ00gKi8KICAgIF9fdmlydGlvMTYgZnVuY3Rpb247CiAgICAvKiBW SVJUSU9fU05EX1BDTV9SX0dFVF9GRUFUVVJFIC8gVklSVElPX1NORF9QQ01fUl9TRVRfRkVBVFVS RSAqLwogICAgX192aXJ0aW8xNiByZXF1ZXN0OwogICAgLyogYSBQQ00gaWRlbnRpZmllciAoYXNz aWduZWQgaW4gY29uZmlndXJhdGlvbikgKi8KICAgIF9fdTggcGNtX2lkOwogICAgLyogYSBQQ00g c3RyZWFtIHR5cGUgKFZJUlRJT19TTkRfUENNX1RfWFhYKSAqLwogICAgX191OCBzdHJlYW1fdHlw ZTsKICAgIC8qIGEgUENNIHN1YnN0cmVhbSBpZGVudGlmaWVyIFswIC4uIHZpcnRpb19zbmRfcGNt X3N0cmVhbV9kZXNjOjpuc3Vic3RyZWFtcyAtIDFdICovCiAgICBfX3U4IHN1YnN0cmVhbV9pZDsK ICAgIC8qIGEgc2VsZWN0ZWQgUENNIHN1YnN0cmVhbSBmZWF0dXJlIChWSVJUSU9fU05EX1BDTV9G RUFUX1hYWCkgKi8KICAgIF9fdTggZmVhdHVyZTsKICAgIC8qIGEgZmVhdHVyZS1zcGVjaWZpYyBy ZXF1ZXN0IGRhdGEgKi8KICAgIC8qCiAgICAgKiBWSVJUSU9fU05EX1BDTV9GRUFUX1VQREFURV9G UkVRVUVOQ1kgW1NFVC1vbmx5XQogICAgICogICAuZGF0YSA9IGFuIGFwcHJveGltYXRlIHVwZGF0 ZSBmcmVxdWVuY3kgaW4gYnl0ZXMKICAgICAqIFZJUlRJT19TTkRfUENNX0ZFQVRfQ0hBTk5FTF9N QVAgW0dFVC9TRVRdCiAgICAgKiAgIEdFVDoKICAgICAqICAgICAuZGF0YSA9IGEgY2hhbm5lbCBt YXAgaW5kZXggWzAgLi4gdmlydGlvX3NuZF9wY21fc3RyZWFtX2Rlc2M6Om5jaG1hcHMgLSAxXQog ICAgICogICBTRVQ6CiAgICAgKiAgICAgLmRhdGEgPSBhIHBzZXVkb3BoeXNpY2FsIHN0YXJ0IGFk ZHJlc3Mgb2YgdGhlIHZpcnRpb19zbmRfcGNtX2NobWFwX2RhdGEgc3RydWN0dXJlCiAgICAgKi8K ICAgIF9fdmlydGlvNjQgZGF0YTsKfTsKCiNkZWZpbmUgVklSVElPX1NORF9QQ01fQ0hfTUFYICAg ICAgICAgICAyNTYKCi8qIFBDTSBjaGFubmVsIGluZm9ybWF0aW9uICovCnN0cnVjdCB2aXJ0aW9f c25kX3BjbV9jaGluZm8KewogICAgLyogYSBQQ00gY2hhbm5lbCBwb3NpdGlvbiAoVklSVElPX1NO RF9QQ01fQ0hfWFhYKSAqLwogICAgX191OCBwb3NpdGlvbjsKICAgIC8qIGEgUENNIGNoYW5uZWwg ZmxhZ3MgKFZJUlRJT19TTkRfUENNX0NIX0ZfWFhYLCBjYW4gYmUgT1JlZCkgKi8KICAgIF9fdTgg ZmxhZ3M7Cn07CgovKiBQQ00gY2hhbm5lbCBtYXAgZGF0YSAqLwpzdHJ1Y3QgdmlydGlvX3NuZF9w Y21fY2htYXBfZGF0YQp7CiAgICAvKiAjIG9mIHZhbGlkIGVudHJpZXMgaW4gdGhlIFBDTSBjaGFu bmVsIG1hcCAqLwogICAgX192aXJ0aW8zMiBuY2hhbm5lbHM7CiAgICAvKiBhIFBDTSBjaGFubmVs IG1hcCAqLwogICAgc3RydWN0IHZpcnRpb19zbmRfcGNtX2NoaW5mbyBjaGFubmVsX21hcFtWSVJU SU9fU05EX1BDTV9DSF9NQVhdOwp9OwoKLyogYSByZXNwb25zZSBjb250YWluaW5nIFBDTSBjaGFu bmVsIG1hcCAqLwpzdHJ1Y3QgdmlydGlvX3NuZF9wY21fY2htYXAKewogICAgc3RydWN0IHZpcnRp b19zbmRfcnNwIGhkcjsKICAgIC8qIGEgY2hhbm5lbCBtYXAgdHlwZSAoVklSVElPX1NORF9QQ01f Q0hNQVBfWFhYKSAqLwogICAgX191OCB0eXBlOwogICAgLyogcmVzZXJ2ZWQsIG11c3QgYmUgemVy byAqLwogICAgX191OCByZXNlcnZlZFszXTsKICAgIC8qIGEgY2hhbm5lbCBtYXAgZGF0YSAqLwog ICAgc3RydWN0IHZpcnRpb19zbmRfcGNtX2NobWFwX2RhdGEgZGF0YTsKfTsKCi8qIGFzc2lnbiBk YXRhIHF1ZXVlIGZvciBQQ00gc3Vic3RyZWFtICovCnN0cnVjdCB2aXJ0aW9fc25kX3BjbV9zZXRf cXVldWUKewogICAgLyogLnJlcXVlc3QgPSBWSVJUSU9fU05EX1BDTV9SX1NFVF9RVUVVRSAqLwog ICAgc3RydWN0IHZpcnRpb19zbmRfcGNtX2hkciBoZHI7CiAgICAvKiBhIHZpcnR1YWwgcXVldWUg aW5kZXggKi8KICAgIF9fdmlydGlvMzIgcXVldWU7Cn07CgovKiBzZXQgUENNIHN1YnN0cmVhbSBm b3JtYXQgKi8Kc3RydWN0IHZpcnRpb19zbmRfcGNtX3NldF9mb3JtYXQKewogICAgLyogLnJlcXVl c3QgPSBWSVJUSU9fU05EX1BDTV9SX1NFVF9GT1JNQVQgKi8KICAgIHN0cnVjdCB2aXJ0aW9fc25k X3BjbV9oZHIgaGRyOwogICAgLyogIyBvZiBjaGFubmVscyAqLwogICAgX192aXJ0aW8xNiBjaGFu bmVsczsKICAgIC8qIGEgUENNIHNhbXBsZSBmb3JtYXQgKFZJUlRJT19TTkRfUENNX0ZNVF9YWFgp ICovCiAgICBfX3ZpcnRpbzE2IGZvcm1hdDsKICAgIC8qIGEgUENNIGZyYW1lIHJhdGUgKFZJUlRJ T19TTkRfUENNX1JBVEVfWFhYKSAqLwogICAgX192aXJ0aW8xNiByYXRlOwogICAgX191MTYgcGFk ZGluZzsKfTsKCiNlbmRpZiAvKiBWSVJUSU9fU05EX0lGX0ggKi8K --_002_76D732A88286A1478FFA94B453B715C1EEA27AB6MXS02opensynerg_ Content-Type: text/plain; charset=us-ascii --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org --_002_76D732A88286A1478FFA94B453B715C1EEA27AB6MXS02opensynerg_-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: virtio-dev-return-5749-cohuck=redhat.com@lists.oasis-open.org Sender: List-Post: List-Help: List-Unsubscribe: List-Subscribe: Received: from lists.oasis-open.org (oasis.ws5.connectedcommunity.org [10.110.1.242]) by lists.oasis-open.org (Postfix) with ESMTP id 949CE985E88 for ; Wed, 15 May 2019 16:03:45 +0000 (UTC) Date: Wed, 15 May 2019 17:03:39 +0100 From: Stefan Hajnoczi Message-ID: <20190515160339.GN29507@stefanha-x1.localdomain> References: <20190506052715.vkdopunuauyhl22m@sirius.home.kraxel.org> <7ac2ae97-bcb7-22cc-272a-723e7209910c@13byte.com> <20190509122710.rfhfnhqez2u7inju@sirius.home.kraxel.org> <5d316321-2c48-342b-f2ce-359e3596dae0@opensynergy.com> <20190510121656.3ab7w5xef6io764o@sirius.home.kraxel.org> <76D732A88286A1478FFA94B453B715C1EEA25DD4@MXS02.open-synergy.com> <20190510154824.GJ22311@stefanha-x1.localdomain> <76D732A88286A1478FFA94B453B715C1EEA25EB1@MXS02.open-synergy.com> <20190514134448.GB6555@stefanha-x1.localdomain> <76D732A88286A1478FFA94B453B715C1EEA27A2B@MXS02.open-synergy.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="e8/wErwm0bqugfcz" Content-Disposition: inline In-Reply-To: <76D732A88286A1478FFA94B453B715C1EEA27A2B@MXS02.open-synergy.com> Subject: Re: [virtio-dev] Request for a new device number for a virtio-audio device. To: Anton Yakovlev Cc: Gerd Hoffmann , Mikhail Golubev , Marco Martinelli - 13Byte srl , "virtio-dev@lists.oasis-open.org" , =?utf-8?B?S8WRdsOhZ8OzIFpvbHTDoW4=?= List-ID: --e8/wErwm0bqugfcz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, May 15, 2019 at 06:30:45AM +0000, Anton Yakovlev wrote: > >> So, our proposal is to support classic way of communications by defaul= t and introduce shared memory based approach as either non-standard extensi= on 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? >=20 > After careful consideration, I think polling mode should make it possible= =2E Like, using dedicated "data" queue per stream in polling mode (multiple= xing is not an option, since it reduces queue throughput in proportion to t= he number of multiplexed streams). How to describe it in specification? Polling is an implementation detail for both drivers and devices. Therefore it's not described explicitly in the specification. By the way, virtqueue buffers can be completed out-of-order by the device. This means sharing a virtqueue between multiple streams does not necessarily introduce any kind of waiting. The only issue is the virtqueue size (e.g. 128 buffers) determines how many buffers can be made available from the driver to the device at any given time. Some device implementations uses virtqueue sizes like 1024 so that this does not become a practical concern. Does this change your view on multiplexing streams? Stefan --e8/wErwm0bqugfcz Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhpWov9P5fNqsNXdanKSrs4Grc8gFAlzcOFsACgkQnKSrs4Gr c8gIDQgAvCNixe3ls9LdQmt7kEg2B6LbMpKQCtI5feGIxmvI82/48tQIXwvPDgcs SDOdIgJfUlUcdDBl76G2uLi8hdpiCzslGDI/9JORLUUKLzgtm+cdt6M7xxFHVt6T AblaPy0nzQODCZVz1rFVy0ojby7W0f4Ahe/nsZtpR/WVJCabACZnxQnCHjaT5fy4 qLciavsF46vn+Sd0GrafYjF0YRGCC1PZtEzi78UgvLqq1+Av4qw7apt14i5zPhKg IqDSbj792LzIYpHV2vs3gdz6gFxtZBZ5RmLL+8X2rjSW49g6+QchQM0BUWIz3y44 BLvboraJqFbvuqXj1FmMVtsj6ulquQ== =z4QM -----END PGP SIGNATURE----- --e8/wErwm0bqugfcz-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: virtio-dev-return-5750-cohuck=redhat.com@lists.oasis-open.org Sender: List-Post: List-Help: List-Unsubscribe: List-Subscribe: Received: from lists.oasis-open.org (oasis.ws5.connectedcommunity.org [10.110.1.242]) by lists.oasis-open.org (Postfix) with ESMTP id 6ADC7985E88 for ; Wed, 15 May 2019 16:33:32 +0000 (UTC) From: Anton Yakovlev Date: Wed, 15 May 2019 16:33:23 +0000 Message-ID: <76D732A88286A1478FFA94B453B715C1EEA27CD5@MXS02.open-synergy.com> References: <20190506052715.vkdopunuauyhl22m@sirius.home.kraxel.org> <7ac2ae97-bcb7-22cc-272a-723e7209910c@13byte.com> <20190509122710.rfhfnhqez2u7inju@sirius.home.kraxel.org> <5d316321-2c48-342b-f2ce-359e3596dae0@opensynergy.com> <20190510121656.3ab7w5xef6io764o@sirius.home.kraxel.org> <76D732A88286A1478FFA94B453B715C1EEA25DD4@MXS02.open-synergy.com> <20190510154824.GJ22311@stefanha-x1.localdomain> <76D732A88286A1478FFA94B453B715C1EEA25EB1@MXS02.open-synergy.com> <20190514134448.GB6555@stefanha-x1.localdomain> <76D732A88286A1478FFA94B453B715C1EEA27A2B@MXS02.open-synergy.com>,<20190515160339.GN29507@stefanha-x1.localdomain> In-Reply-To: <20190515160339.GN29507@stefanha-x1.localdomain> Content-Language: en-US Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: RE: [virtio-dev] Request for a new device number for a virtio-audio device. To: Stefan Hajnoczi Cc: Gerd Hoffmann , Mikhail Golubev , Marco Martinelli - 13Byte srl , "virtio-dev@lists.oasis-open.org" , =?iso-8859-2?Q?K=F5v=E1g=F3_Zolt=E1n?= List-ID: >> After careful consideration, I think polling mode should make it possibl= e. Like, using dedicated "data" queue per stream in polling mode (multiplex= ing is not an option, since it reduces queue throughput in proportion to th= e number of multiplexed streams). How to describe it in specification? > > Polling is an implementation detail for both drivers and devices. > Therefore it's not described explicitly in the specification. And the only source of information in such case is to take a look into alre= ady existed implementations? > By the way, virtqueue buffers can be completed out-of-order by the > device. This means sharing a virtqueue between multiple streams does > not necessarily introduce any kind of waiting. > > The only issue is the virtqueue size (e.g. 128 buffers) determines how > many buffers can be made available from the driver to the device at any > given time. Some device implementations uses virtqueue sizes like 1024 > so that this does not become a practical concern. Does this change your > view on multiplexing streams? Personally, I'm not a big fan of, because: 1. It makes overall logic more complex: you need to serialize access to the= queue on driver side and dispatch messages (find out recepient, serialize = access etc) on device side. With separated queues you have only one produce= r and consumer, and they both knows ahead how to handle buffers. 2. It requires to define message header for buffer transfers. With separate= d queues you just put into descriptors a pointer to the buffer and its leng= th. The simpler the better. And with multiplexing basically you have no pros ex= cept having one queue. Why separated queues are undesirable? -- Anton Yakovlev Senior Software Engineer OpenSynergy GmbH Rotherstr. 20, 10245 Berlin www.opensynergy.com Please mind our privacy notice pursuant to Art. 13 GDPR. // Unsere= Hinweise zum Datenschutz gem. Art. 13 DSGVO finden Sie hier. COQOS Hypervisor certified by T=DCV S=DCD [COQOS Hypervisor certified by T=DCV S=DCD] --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: virtio-dev-return-5751-cohuck=redhat.com@lists.oasis-open.org Sender: List-Post: List-Help: List-Unsubscribe: List-Subscribe: Received: from lists.oasis-open.org (oasis.ws5.connectedcommunity.org [10.110.1.242]) by lists.oasis-open.org (Postfix) with ESMTP id B3B20985E94 for ; Thu, 16 May 2019 10:24:52 +0000 (UTC) Date: Thu, 16 May 2019 11:24:46 +0100 From: Stefan Hajnoczi Message-ID: <20190516102446.GU29507@stefanha-x1.localdomain> References: <20190509122710.rfhfnhqez2u7inju@sirius.home.kraxel.org> <5d316321-2c48-342b-f2ce-359e3596dae0@opensynergy.com> <20190510121656.3ab7w5xef6io764o@sirius.home.kraxel.org> <76D732A88286A1478FFA94B453B715C1EEA25DD4@MXS02.open-synergy.com> <20190510154824.GJ22311@stefanha-x1.localdomain> <76D732A88286A1478FFA94B453B715C1EEA25EB1@MXS02.open-synergy.com> <20190514134448.GB6555@stefanha-x1.localdomain> <76D732A88286A1478FFA94B453B715C1EEA27A2B@MXS02.open-synergy.com> <20190515160339.GN29507@stefanha-x1.localdomain> <76D732A88286A1478FFA94B453B715C1EEA27CD5@MXS02.open-synergy.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="uUozbLrG2OP+gMtx" Content-Disposition: inline In-Reply-To: <76D732A88286A1478FFA94B453B715C1EEA27CD5@MXS02.open-synergy.com> Subject: Re: [virtio-dev] Request for a new device number for a virtio-audio device. To: Anton Yakovlev Cc: Gerd Hoffmann , Mikhail Golubev , Marco Martinelli - 13Byte srl , "virtio-dev@lists.oasis-open.org" , =?utf-8?B?S8WRdsOhZ8OzIFpvbHTDoW4=?= List-ID: --uUozbLrG2OP+gMtx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, May 15, 2019 at 04:33:23PM +0000, Anton Yakovlev wrote: >=20 > >> After careful consideration, I think polling mode should make it possi= ble. Like, using dedicated "data" queue per stream in polling mode (multipl= exing is not an option, since it reduces queue throughput in proportion to = the number of multiplexed streams). How to describe it in specification? > > > > Polling is an implementation detail for both drivers and devices. > > Therefore it's not described explicitly in the specification. >=20 > And the only source of information in such case is to take a look into al= ready existed implementations? Yes. The spec focusses on the hardware interface and the semantics but not on how to implement it. > > By the way, virtqueue buffers can be completed out-of-order by the > > device. This means sharing a virtqueue between multiple streams does > > not necessarily introduce any kind of waiting. > > > > The only issue is the virtqueue size (e.g. 128 buffers) determines how > > many buffers can be made available from the driver to the device at any > > given time. Some device implementations uses virtqueue sizes like 1024 > > so that this does not become a practical concern. Does this change your > > view on multiplexing streams? >=20 > Personally, I'm not a big fan of, because: >=20 > 1. It makes overall logic more complex: you need to serialize access to t= he queue on driver side and dispatch messages (find out recepient, serializ= e access etc) on device side. With separated queues you have only one produ= cer and consumer, and they both knows ahead how to handle buffers. > 2. It requires to define message header for buffer transfers. With separa= ted queues you just put into descriptors a pointer to the buffer and its le= ngth. >=20 > The simpler the better. And with multiplexing basically you have no pros = except having one queue. Why separated queues are undesirable? I'm not sure which approach is best either. In the real-time audio programming I've done there was a function like this: process(const float **in_frames, int in_channels, float **out_frames, int out_channels, int nframes); This function processes audio frames periodically and is a callback from the real-time audio API. If the device multiplexes streams on a single virtqueue and uses the batched request layout that I previously described, then the driver implementation is very simple. There is no need to bring together audio data supplied through multiple virtqueues because it all comes in a single buffer on a single virtqueue. You mentioned that separate queues avoid synchronization but in this case it seems to actually introduce a synchronization requirement. Having a single virtqueue where all audio data flows between the process() function and the device is simple and minimizes per-virtqueue overhead. In an interrupt-driven implementation there are per-virtqueue virtio-pci Queue Notify register writes and per-virtqueue interrupt handlers, so this can generate a lot of vmexits and interrupts compared to the multiplexed batched approach. If your application processes audio streams in different threads and without inter-stream synchronization, then I agree that multiple virtqueues is the way to go. I don't have a strong opinion on the optimal approach, just wanted to explain why I had this idea. Please choose as you wish. Stefan --uUozbLrG2OP+gMtx Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhpWov9P5fNqsNXdanKSrs4Grc8gFAlzdOm4ACgkQnKSrs4Gr c8h5lQf/S9kugJ04h9lKj1qoUb0F9Xa3v7De4F17bqEuWNwBs+aHZw3Gsc7Dr/wn LmVaJiNvN1uummkq4Mfk/8tcrR7wGUDgPrInpkbzlpSF8FVPDbp7IOFzSXbB+JUc Zvr6nDQf5kOxjDnMxsKeSaVfQ+9wO+NpHsJsROK3kCu/n0YkeQ2O7fVUsyTDZABj +9Hl9tMI5mRRukQMa8djrHcWFjbaDcX2H4knlzxaFM6sgW5CsO/JpZuHKbIbemWR P5QViRsRuQAFkoo49afSnnbifoiTFwCb4eiTAZm6iS6YAhO0p7WR6A1bCFreSUf4 IM5rvakIvCebOoNz7wqaMJ4K8VW07w== =3S2n -----END PGP SIGNATURE----- --uUozbLrG2OP+gMtx-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: virtio-dev-return-5741-cohuck=redhat.com@lists.oasis-open.org Sender: List-Post: List-Help: List-Unsubscribe: List-Subscribe: Received: from lists.oasis-open.org (oasis.ws5.connectedcommunity.org [10.110.1.242]) by lists.oasis-open.org (Postfix) with ESMTP id 69F90984AB0 for ; Mon, 13 May 2019 09:32:24 +0000 (UTC) Date: Mon, 13 May 2019 11:32:17 +0200 From: Gerd Hoffmann Message-ID: <20190513093217.dpcixnntqev5r5lz@sirius.home.kraxel.org> References: <20190501170525.GB22391@stefanha-x1.localdomain> <20190503164501.GB8373@stefanha-x1.localdomain> <863e1be1-11cc-816b-896d-3954427e98f3@13byte.com> <20190506052715.vkdopunuauyhl22m@sirius.home.kraxel.org> <7ac2ae97-bcb7-22cc-272a-723e7209910c@13byte.com> <20190509122710.rfhfnhqez2u7inju@sirius.home.kraxel.org> <5d316321-2c48-342b-f2ce-359e3596dae0@opensynergy.com> <20190510121656.3ab7w5xef6io764o@sirius.home.kraxel.org> <76D732A88286A1478FFA94B453B715C1EEA25DD4@MXS02.open-synergy.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <76D732A88286A1478FFA94B453B715C1EEA25DD4@MXS02.open-synergy.com> Subject: Re: [virtio-dev] Request for a new device number for a virtio-audio device. To: Anton Yakovlev Cc: Mikhail Golubev , Marco Martinelli - 13Byte srl , "virtio-dev@lists.oasis-open.org" , Stefan Hajnoczi , =?utf-8?B?S8WRdsOhZ8OzIFpvbHTDoW4=?= List-ID: On Fri, May 10, 2019 at 02:15:00PM +0000, Anton Yakovlev wrote: > Hi Gerd! My name is Anton and I'm the original author of this draft. Thanks for comments! > > >> Configuration space provides a maximum amount of available virtual queues. The > >> nqueues value MUST be at least one. > >> > >> ``` > >> struct virtio_snd_config > >> { > >> le32 nqueues; > >> }; > >> ``` > > > Including or excluding the control queue? > > Including the control queue. Ok. Please say so explicitly in the specs. > >> Each request begins with a 2-byte field that identifies a recipient function > >> followed by a 2-byte field that identifies a function-specific request type. > >> > >> Each response begins with a 4-byte field that contains a status code. The values > >> 0-31 are reserved for common status codes, a function can define function-specific > >> status codes starting from 32. > > > I'd suggest to use a common scheme with a single le32 field for both > > requests and responses. > > ... > > (maybe just drop the single-element structs and use the enums directly). > > IMO, both options are quite fine. We decided to choose separate > namespaces because it's more flexible approach. I fail to see why it is more flexible. If you want go with the separate function/request fields I'd suggest to do the same for responses. > >> ### Device Configuration > >> ... > >> struct virtio_snd_generic_desc > >> { > >> u8 length; > >> u8 type; > >> u16 padding; > > > > I'd make length and type u16 and drop the padding. > > Well, it's a possible option. We just didn't want to waste additional space here. Ok, saw later in the patch that other descriptors _replace_ padding instead of _appending_ to the struct. So padding isn't there to align fields appended, but round up the descriptor size for descriptor alignment, correct? I think it's fine then. > >> With the exception of the base function, all implemented functions MUST define > >> its own descriptor(s) format (either presented in this specification or > >> vendor-specific) and MUST includes these in configuration only if a particular > >> function (or part of its functionality) is enabled in the device. > > > > I don't think it is a good idea to allow vendor-specific descriptors > > here. It should all be in the virtio spec. We might want reserve a > > sub-range of "type" for experimental/development purposes though. > > Yeah, an ability to define some experimental extensions was one of the > targets here (like adding sound controls, non-PCM streams, MIDI and so > on). Also, this spec targeted the widest possible range of cases. > Like, some hardware has very tricky features which can not be (or just > has no point to be) defined in common specification. One example is to > allow switching between speaker and bluetooth output. Ususally you > don't need it, but if you want to provide such feature to the guest, > it's better to implement this as a custom extension. Why? I think it makes perfect sense to have a standard function for stream routing. Even when allowing vendor specific descriptors/functions a sub-range of "type" must be reserved for that and a way to identify the vendor is needed. > >> ### Function Operation > >> > >> #### Get Device Configuration > >> > >> The driver sends the VIRTIO_SND_BASE_R_GET_CFG generic request, the device > >> answers with a response containing device configuration. > > > > Which is a list of descriptors I assume? > > You are right. Good. Please clarify the specs. > >> #### Suspend > >> #### Resume > > > > Why these two are needed? > > I would say, that some virtualization platforms either do not notify > your backend about guest suspend/resume or it's very tricky to > distinguish such conditions from other shutdown/initialization types. > According to my practice, it's always better to notify device side in > explicit way, because the driver always know what is going now. So the idea is the driver doesn't stop streams on suspend, but sends a suspend notification to the device and expects the device stop the streams? > > Also restoring state as optional device feature doesn't look useful to > > me. > > Well, restoring active playback or capturing is not impossible thing > at all. From other side, maybe some device implementors might not > want/need such functionality. So I'm not sure, what is better here. I think we should have *one* way to handle suspend/resume. So either make suspend/resume commands mandatory, or expect the driver to stop/restart streams on suspend/resume. I think the latter is the better way. If you want know on the device side why a stream was stopped (why do you need to know btw?) you can add a "reason" field to the stop command. > >> - *Automatic mode*: the driver allocates and shares with the device a pseudophysically > >> continuous memory area containing runtime control registers and data buffer itself. > > > > What is "pseudophysically continuous memory"? > > This memory is physically continuous from the driver's point of view. So continuous in guest physical memory. > > Why do you think this is needed? > > When you implement an audio device, you usually start with what we > call "manual mode". It works, but only for simple use cases. There're > two major challenges here. > > Thus, no requests/traps/hypercalls to the device while a stream is > running - no problems here. As already mentioned by Stefan you can run the virtqueue in polling mode to avoid trapping into the hypervisor. > 2) Everybody wants to reduce a latency as much as possible. One of the > most logical way is to allow to mmap data buffer into the user space > memory. mmap() doesn't conflict with virtqueues. Userspace must notify the kernel driver about buffer updates though. > (Actually, in some cases you even have no choice here, like in > case of the WaveRT interface in Windows.) But memory mapped buffer > means, that you either have a very little or have not at all an idea > what is going on with buffer content. So how do you maintain virtio_snd_pcm_hw_regs.dma_position? Do you allow userspace mmap the whole virtio_snd_pcm_shmem struct and update it directly, without calling into the kernel driver? > > Why both microseconds and bytes? Isn't that redundant? > > Just to be sure that both ends have exactly the same ideas. I don't think this is needed. If one end gets the microseconds <=> bytes transformation wrong you'll have bigger problems anyway ... > > Are 8-bit formats are still used in practice? > > Actually, yeah. I saw quite recent chipsets with the U8 format > support. Anyway, is it a big issue? It costs zero to support > additional formats, so why not? Well, the cost is not zero. Some more code (not that much indeed). More testing (more significant cost). So I would try to avoid carrying forward old stuff which is not used in practice any more just because you can. > > What are VIRTIO_SND_PCM_FMT_{S,U}20_LE ? > > > > What are VIRTIO_SND_PCM_FMT_*_3BE ? > > > > Which of these formats are actually implemented in your prototype? > > Some format's physical width is not multiple of 8. Such samples are > kept in "a storage" which width is multiple of 8 (like 20-bit samples > are kept either in 24-bit or in 32-bit storage). So VIRTIO_SND_PCM_FMT_U20_LE == VIRTIO_SND_PCM_FMT_U32_LE, except that with U20 the sound hardware doesn't use the 12 least significant bits? > Both Linux (ALSA) and Windows (WaveXXX interfaces) just expect from > you to report support of these formats. You don't need to do anything > special in order to implemented them. So, yes, we can support them in > the prototype. I guess I would have used the storage format and the number of significant bits instead, but if sound APIs use different format constants for these being consistent makes sense to me. > > Same question: Do we actually need all those? My impression is that > > these days 48000 is pretty much standard. 96000 + 192000 for higher > > quality. 44100 sometimes still because it happens to be the CD sample > > rate. Maybe 32000/16000/8000 for low bandwidth codecs. > > > > But 5512, 11025 & friends? > > Same answer: why not? :) Same reply as above ;) > >> /* a PCM channel map definitions */ > >> > >> /* All channels have fixed channel positions */ > >> #define VIRTIO_SND_PCM_CHMAP_FIXED 0 > >> /* All channels are swappable (e.g. {FL/FR/RL/RR} -> {RR/RL/FR/FL}) */ > >> #define VIRTIO_SND_PCM_CHMAP_VARIABLE 1 > >> /* Only pair-wise channels are swappable (e.g. {FL/FR/RL/RR} -> {RL/RR/FL/FR}) */ > >> #define VIRTIO_SND_PCM_CHMAP_PAIRED 2 > > > > What this is good for? How would a driver ask the device to actually > > swap the channels? And isn't it easier to have the device provide a > > complete list of possible channel maps and let the driver simply pick > > one? > > Basically, we were inspired how ALSA handles these and reused the same > approach here. How: a hardware can have internal router/mixer to allow > flexible configuration, there's nothing special. I mean in the virtio api. Devices can report the mapping capability but the driver can't pick one. Or did I miss something (if so then this is an indication that the spec should be more clear on how channel mapping is supposed to work ...) ? > >> #### Prepare ... #### Start ... > > > > So I guess the way to start a stream is (a) prepare, (b) queue some > > buffers, (c) start. Correct? > > Yeap! Doesn't hurt to explicitly say so in the specs ;) 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: virtio-dev-return-5744-cohuck=redhat.com@lists.oasis-open.org Sender: List-Post: List-Help: List-Unsubscribe: List-Subscribe: Received: from lists.oasis-open.org (oasis.ws5.connectedcommunity.org [10.110.1.242]) by lists.oasis-open.org (Postfix) with ESMTP id CEE10985E3D for ; Tue, 14 May 2019 19:14:37 +0000 (UTC) From: Anton Yakovlev Date: Tue, 14 May 2019 19:14:25 +0000 Message-ID: <76D732A88286A1478FFA94B453B715C1EEA277CA@MXS02.open-synergy.com> References: <20190501170525.GB22391@stefanha-x1.localdomain> <20190503164501.GB8373@stefanha-x1.localdomain> <863e1be1-11cc-816b-896d-3954427e98f3@13byte.com> <20190506052715.vkdopunuauyhl22m@sirius.home.kraxel.org> <7ac2ae97-bcb7-22cc-272a-723e7209910c@13byte.com> <20190509122710.rfhfnhqez2u7inju@sirius.home.kraxel.org> <5d316321-2c48-342b-f2ce-359e3596dae0@opensynergy.com> <20190510121656.3ab7w5xef6io764o@sirius.home.kraxel.org> <76D732A88286A1478FFA94B453B715C1EEA25DD4@MXS02.open-synergy.com>,<20190513093217.dpcixnntqev5r5lz@sirius.home.kraxel.org> In-Reply-To: <20190513093217.dpcixnntqev5r5lz@sirius.home.kraxel.org> Content-Language: en-US Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: RE: [virtio-dev] Request for a new device number for a virtio-audio device. To: Gerd Hoffmann Cc: Mikhail Golubev , Marco Martinelli - 13Byte srl , "virtio-dev@lists.oasis-open.org" , Stefan Hajnoczi , =?iso-8859-2?Q?K=F5v=E1g=F3_Zolt=E1n?= List-ID: >>>> Each request begins with a 2-byte field that identifies a recipient fu= nction >>>> followed by a 2-byte field that identifies a function-specific request= type. >>>> >>>> Each response begins with a 4-byte field that contains a status code. = The values >>>> 0-31 are reserved for common status codes, a function can define funct= ion-specific >>>> status codes starting from 32. >> >>> I'd suggest to use a common scheme with a single le32 field for both >>> requests and responses. >>> ... >>> (maybe just drop the single-element structs and use the enums directly)= . >> >> IMO, both options are quite fine. We decided to choose separate >> namespaces because it's more flexible approach. > > I fail to see why it is more flexible. If you want go with the separate > function/request fields I'd suggest to do the same for responses. It's not like we definitely want to, it just was a design choice at the mom= ent. As I mentioned, the both options look fine. If it's more reasonable to= have single enum, let it be. >> >> ### Device Configuration >> >> ... >> >> struct virtio_snd_generic_desc >> >> { >> >> u8 length; >> >> u8 type; >> >> u16 padding; >> > >> > I'd make length and type u16 and drop the padding. >> >> Well, it's a possible option. We just didn't want to waste additional sp= ace here. > > Ok, saw later in the patch that other descriptors _replace_ padding > instead of _appending_ to the struct. So padding isn't there to align > fields appended, but round up the descriptor size for descriptor > alignment, correct? > I think it's fine then. Yes, this definition was done just for convenience. >> >> With the exception of the base function, all implemented functions MU= ST define >> >> its own descriptor(s) format (either presented in this specification = or >> >> vendor-specific) and MUST includes these in configuration only if a p= articular >> >> function (or part of its functionality) is enabled in the device. >> > >> > I don't think it is a good idea to allow vendor-specific descriptors >> > here. It should all be in the virtio spec. We might want reserve a >> > sub-range of "type" for experimental/development purposes though. >> >> Yeah, an ability to define some experimental extensions was one of the >> targets here (like adding sound controls, non-PCM streams, MIDI and so >> on). Also, this spec targeted the widest possible range of cases. >> Like, some hardware has very tricky features which can not be (or just >> has no point to be) defined in common specification. One example is to >> allow switching between speaker and bluetooth output. Ususally you >> don't need it, but if you want to provide such feature to the guest, >> it's better to implement this as a custom extension. > > Why? I think it makes perfect sense to have a standard function for > stream routing. > > Even when allowing vendor specific descriptors/functions a sub-range of > "type" must be reserved for that and a way to identify the vendor is > needed. Okey, what is your proposal? Should specification define driver behavior fo= r configuration parsing? >> >> #### Suspend >> >> #### Resume >> > >> > Why these two are needed? >> >> I would say, that some virtualization platforms either do not notify >> your backend about guest suspend/resume or it's very tricky to >> distinguish such conditions from other shutdown/initialization types. >> According to my practice, it's always better to notify device side in >> explicit way, because the driver always know what is going now. > > So the idea is the driver doesn't stop streams on suspend, but sends a > suspend notification to the device and expects the device stop the > streams? Yes, that was the original idea. >> > Also restoring state as optional device feature doesn't look useful to >> > me. >> >> Well, restoring active playback or capturing is not impossible thing >> at all. From other side, maybe some device implementors might not >> want/need such functionality. So I'm not sure, what is better here. > > I think we should have *one* way to handle suspend/resume. So either > make suspend/resume commands mandatory, or expect the driver to > stop/restart streams on suspend/resume. > > I think the latter is the better way. If you want know on the device > side why a stream was stopped (why do you need to know btw?) you can add > a "reason" field to the stop command. We want to know the reason for supporting running stream suspend/resume. If= the driver was shutdown, the device does not need to do anything special. = If it was suspended while running stream, the device must be ready to resta= rt stream on resume (since from the driver's point of view nothing happened= in between suspend/resume). But I rethought this part and realized that it would not help. There're two= types of suspends: when a guest enters low power state (like s3/s4) and wh= en, for example, QEmu was suspended. In second case the driver will send no= thing. Thus, there's no point having these special request types in specifi= cation. >> 2) Everybody wants to reduce a latency as much as possible. One of the >> most logical way is to allow to mmap data buffer into the user space >> memory. > > mmap() doesn't conflict with virtqueues. Userspace must notify the > kernel driver about buffer updates though. Userspace must notify the kernel, not the kernel driver itself. There's a h= uge difference. On Linux, ALSA design allows device driver to have informat= ion about buffer updates. But it's just a special case. In general, this in= formation is required only by upper layer, not by the driver. And, for exam= ple, recent Windows versions do not notify the driver at all. >> (Actually, in some cases you even have no choice here, like in >> case of the WaveRT interface in Windows.) But memory mapped buffer >> means, that you either have a very little or have not at all an idea >> what is going on with buffer content. > > So how do you maintain virtio_snd_pcm_hw_regs.dma_position? Do you > allow userspace mmap the whole virtio_snd_pcm_shmem struct and update > it directly, without calling into the kernel driver? It's supposed to mmap only buffer part (without control registers). >> > Why both microseconds and bytes? Isn't that redundant? >> >> Just to be sure that both ends have exactly the same ideas. > > I don't think this is needed. If one end gets the microseconds <=3D> > bytes transformation wrong you'll have bigger problems anyway ... I think we could do without these at all. I want to discuss it in my reply = to Stefan. >> > Are 8-bit formats are still used in practice? >> >> Actually, yeah. I saw quite recent chipsets with the U8 format >> support. Anyway, is it a big issue? It costs zero to support >> additional formats, so why not? > > Well, the cost is not zero. Some more code (not that much indeed). > More testing (more significant cost). So I would try to avoid carrying > forward old stuff which is not used in practice any more just because > you can. It seems reasonable to remove A_LAW/MU_LAW formats and endianness. But regarding other formats you are not quite right. They are still being u= sed, even S8/U8. Let's take a broader look. There's the Android and it has = hardware compatibility requirements. According to PCM playback/capture requ= irements, Android wants to have 8-bit and 16-bit sample formats. I saw rece= nt boards support for both types, and these boards were supposed to run the= Android. If your goal is to run virtualized Android there, you definetly w= ant to provide the same audio capabilities to the guest. The same regarding sample rates. Android requires sample rate from 8 kHz to= 48 kHz, and Android-compatible hardware does provide it. I want to say these formats and rates are still alive in modern hardware. >> > What are VIRTIO_SND_PCM_FMT_{S,U}20_LE ? >> > >> > What are VIRTIO_SND_PCM_FMT_*_3BE ? >> > >> > Which of these formats are actually implemented in your prototype? >> >> Some format's physical width is not multiple of 8. Such samples are >> kept in "a storage" which width is multiple of 8 (like 20-bit samples >> are kept either in 24-bit or in 32-bit storage). > > So VIRTIO_SND_PCM_FMT_U20_LE =3D=3D VIRTIO_SND_PCM_FMT_U32_LE, except tha= t > with U20 the sound hardware doesn't use the 12 least significant bits? Yes, correct. >> Both Linux (ALSA) and Windows (WaveXXX interfaces) just expect from >> you to report support of these formats. You don't need to do anything >> special in order to implemented them. So, yes, we can support them in >> the prototype. > > I guess I would have used the storage format and the number of > significant bits instead, but if sound APIs use different format > constants for these being consistent makes sense to me. Yes, it's much easier to derive such information from defined format types = than vice versa. Also, when you have defined types for supported formats, y= ou automatically cut out all unsupported/invalid [storage bits, significant= bits] combinations. >> >> /* a PCM channel map definitions */ >> >> >> >> /* All channels have fixed channel positions */ >> >> #define VIRTIO_SND_PCM_CHMAP_FIXED 0 >> >> /* All channels are swappable (e.g. {FL/FR/RL/RR} -> {RR/RL/FR/FL}) *= / >> >> #define VIRTIO_SND_PCM_CHMAP_VARIABLE 1 >> >> /* Only pair-wise channels are swappable (e.g. {FL/FR/RL/RR} -> {RL/R= R/FL/FR}) */ >> >> #define VIRTIO_SND_PCM_CHMAP_PAIRED 2 >> > >> > What this is good for? How would a driver ask the device to actually >> > swap the channels? And isn't it easier to have the device provide a >> > complete list of possible channel maps and let the driver simply pick >> > one? >> >> Basically, we were inspired how ALSA handles these and reused the same >> approach here. How: a hardware can have internal router/mixer to allow >> flexible configuration, there's nothing special. > > I mean in the virtio api. Devices can report the mapping capability but > the driver can't pick one. Or did I miss something (if so then this is > an indication that the spec should be more clear on how channel mapping > is supposed to work ...) ? 1. If the device can provide information about channel map(s), it sets the = CHANNEL_MAP feature bit and # of supported channel maps in a PCM stream con= figuration descriptor. 2. The driver can enumerate channel maps using the GET_FEATURE(CHANNEL_MAP)= request containing a channel map index (from 0 to desc::nchmaps - 1). 3. If a channel map type allows to swap channel positions, the driver can s= end the SET_FEATURE(CHANNEL_MAP) request containing updated channel positio= ns. That's the idea. >> >> #### Prepare ... #### Start ... >> > >> > So I guess the way to start a stream is (a) prepare, (b) queue some >> > buffers, (c) start. Correct? >> >> Yeap! > > Doesn't hurt to explicitly say so in the specs ;) Will be done! -- Anton Yakovlev Senior Software Engineer OpenSynergy GmbH Rotherstr. 20, 10245 Berlin www.opensynergy.com --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org Please mind our privacy notice pursuant to Art. 13 GDPR. // Unsere= Hinweise zum Datenschutz gem. Art. 13 DSGVO finden Sie hier. COQOS Hypervisor certified by T=DCV S=DCD [COQOS Hypervisor certified by T=DCV S=DCD] --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: virtio-dev-return-5724-cohuck=redhat.com@lists.oasis-open.org Sender: List-Post: List-Help: List-Unsubscribe: List-Subscribe: Received: from lists.oasis-open.org (oasis.ws5.connectedcommunity.org [10.110.1.242]) by lists.oasis-open.org (Postfix) with ESMTP id D17BB985DFA for ; Fri, 10 May 2019 10:34:57 +0000 (UTC) Date: Fri, 10 May 2019 11:34:52 +0100 From: Stefan Hajnoczi Message-ID: <20190510103452.GD22311@stefanha-x1.localdomain> References: <20190429134754.GI7587@stefanha-x1.localdomain> <4fcd7456-de22-7f6d-d5ef-939cd3d7cf95@13byte.com> <20190501170525.GB22391@stefanha-x1.localdomain> <20190503164501.GB8373@stefanha-x1.localdomain> <863e1be1-11cc-816b-896d-3954427e98f3@13byte.com> <20190506052715.vkdopunuauyhl22m@sirius.home.kraxel.org> <7ac2ae97-bcb7-22cc-272a-723e7209910c@13byte.com> <20190509122710.rfhfnhqez2u7inju@sirius.home.kraxel.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="RYJh/3oyKhIjGcML" Content-Disposition: inline In-Reply-To: <20190509122710.rfhfnhqez2u7inju@sirius.home.kraxel.org> Subject: Re: [virtio-dev] Request for a new device number for a virtio-audio device. To: Gerd Hoffmann Cc: Marco Martinelli - 13Byte srl , virtio-dev@lists.oasis-open.org, =?utf-8?B?S8WRdsOhZ8OzIFpvbHTDoW4=?= List-ID: --RYJh/3oyKhIjGcML Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, May 09, 2019 at 02:27:10PM +0200, Gerd Hoffmann wrote: > > For the sake of the specification I think we need to focus on is how to > > transport these streams and how to share a configuration for each one. >=20 > I think we need at least three virt queues. One control queue for > commands (query capabilities, set configuration, start/stop streams, > volume control, ...). One queue for input streams. One queue for > output streams. >=20 > If we want allow for multiple inputs/outputs we have basically two > options: (a) one queue per stream, or (b) use a small header for each > data packet, telling what stream it belongs to. >=20 > Maybe a small header is a good idea anyway, for timestamps. I agree with the 3 virtqueue layout. Multiplexing streams over a single input/output virtqueue pair has pros and cons. Overall I think it's a good fit though: + Number of streams can change at runtime (virtqueues are static!) + Easy to handle multiple inputs/outputs + Ability to synchronize streams, including transferring buffers for multiple streams in a single message with a single timestamp - Virtqueue must be sized to handle maximum simultaneous streams without running out of descriptors - Extra latency (jitter) and locking requirements due to sharing virtqueues between streams even if they are processed on different vCPUs Stefan --RYJh/3oyKhIjGcML Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhpWov9P5fNqsNXdanKSrs4Grc8gFAlzVU8wACgkQnKSrs4Gr c8gVygf/UXrY3DhXM14FCxmWJyAOI/9FafrPobGbFbfhQfyMcShoP8ysM8tJw9EJ jMFie4hlvfwF2gX9knyCTlZxM3TBeta7wwIe2Y5pgEwlyPhtfx2Xw4qovCtgIQE3 c6f7/gZglc7ps86QogG7+RcEtwpSSpK4k6rAprPMlwXc3C3GgPmt+ZnPNSJ+wyDR PqScBxfv0UTVLammOLWyQAo+iOHM9rjR4U1P9O7yl16gGO2ZX+RKSKMF0iyypI4G z+qpLrFpSE5sHkO1NeInZxbzpqrxKDu/xbJRfEfRTgUVTtjUKu96YCByEpohm7OP V3xciW6HKGgcSIv0L+veROCxe+BuJg== =0Dgq -----END PGP SIGNATURE----- --RYJh/3oyKhIjGcML--