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

# virtio-dev message

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

Subject: Re: [virtio-dev] [PATCH] snd: Add virtio sound device specification

• From: Anton Yakovlev <anton.yakovlev@opensynergy.com>
• To: Mark Brown <broonie@kernel.org>
• Date: Tue, 29 Oct 2019 14:16:04 +0100



On 29.10.2019 13:18, Mark Brown wrote:

On Tue, Oct 29, 2019 at 11:14:52AM +0100, Anton Yakovlev wrote:

On 28.10.2019 17:05, Liam Girdwood wrote:

On Tue, 2019-09-24 at 15:43 +0100, Mikhail Golubev wrote:



+    VIRTIO_SND_PCM_RATE_8000 = 0,
+    VIRTIO_SND_PCM_RATE_11025,
+    VIRTIO_SND_PCM_RATE_16000,
+    VIRTIO_SND_PCM_RATE_22050,
+    VIRTIO_SND_PCM_RATE_32000,
+    VIRTIO_SND_PCM_RATE_44100,
+    VIRTIO_SND_PCM_RATE_48000,
+    VIRTIO_SND_PCM_RATE_64000,
+    VIRTIO_SND_PCM_RATE_88200,
+    VIRTIO_SND_PCM_RATE_96000,
+    VIRTIO_SND_PCM_RATE_176400,
+    VIRTIO_SND_PCM_RATE_192000



It may be best to use the same rates and format from the ALSA spec,
this covers any holes (like rates that are not in the above list).



These rates are from ALSA definitions. And what formats should be added?


There was one rate at the lower end which I'm not super convinced is
useful but would be handy for making the numbers in the enum line up and
a couple of higher rates up to 384kHz.  Those probably *are* useful for
ultrasonic applications, you may also find some regular audio files
encoded at that rate but most of the oversampled hifi stuff tops out at
192kHz.



I think, you talk about 5512Hz. If it's reasonable, two more values in enum is not a problem.



What about buffer and period size capabilities ?



In this specification we assume that buffer size is up to guest decision.
Also, period size is ALSA-only conception and should not be mentioned here
at all (we are not stick only to ALSA).


Period size isn't just an ALSA thing - it's a widely supported and used
hardware feature.  When using a ring buffer (or just sending large
amounts of data at once, but mainly ring buffers) it is useful to know
how the hardware is progressing through the data without having to use
CPU timers (which may not be well synced with the audio clock), the
period interrupts do that.



Periods here are kind of notification frequency, right? It's supposed to be used for sending notifications to driver?



+\begin{lstlisting}
+struct virtio_snd_pcm_xfer {
+    le32 stream;
+    u8 data[];
+    le32 status;
+    le32 actual_length;



Not following this, is actual_length the size of data[]. If so, it must
preceed data[].



No, the actual_length field is supposed to be used by device side to report
actual amount of bytes read from/written to a buffer. In real world
scenario, if an I/O request contains N bytes, a device can play/capture *up
to* N bytes. Thus, it's required to report this length back to a driver.


So really there's two structs here, a header struct with just stream in
it and then a tail struct with the length and status information which
the consumer locates by looking at the end of the buffer and working
backwards?



Yes, it is. Since both these structures are coupled together and must be sent at the same time, in spec they are represented as one "structure".



1) Underruns and overruns. i.e. how do we recover and resync audio
between guests.



Since xrun conditions are higher level conceptions, we decided to delegate
such issues to guest application itself. It helps to make overall design
simpler. And it seems there's not so much we can do if xrun condition is
happened on the device side.


I'm not so sure about that - in a message based system I would expect
the device side to be able to at least say "I am throwing away data" for
cases where it's arriving too fast to be consumed and the device ran out
of buffer space, and ideally also say if it underflows.  It's more of a
high level concept with free running ring buffers where the device can
just happily keep reading to or writing from the buffer regardless of if
the host is paying attention to it.



That's the point. The spec describes a device. Device is supposed just to read from/write to hardware buffer regardless of its content.


Also, the main problems with xrun is what to do with this information? Let's assume that device can report something like "I'm going to run out of frames for playback soon" or "I have no more frames for playback", then what? In low latency scenario, user space application will provide small chunks of data. It means, hardware buffer will be empty in like 95% of cases. And the only thing driver can do is somehow indicate xrun to upper layer (which will be not true from application point's of view, if hardware pointer has not crossed application pointer yet in ALSA). I.e. exactly the same result, where there's no notification from the device side.


--
Anton Yakovlev
Senior Software Engineer

OpenSynergy GmbH
Rotherstr. 20, 10245 Berlin

Phone: +49 30 60 98 54 0
E-Mail: anton.yakovlev@opensynergy.com

www.opensynergy.com

Handelsregister/Commercial Registry: Amtsgericht Charlottenburg, HRB 108616B