Re: [Embedded-pv-devel] [Xen-devel] [PATCH v8] This is ABI for the two halves of a Para-virtual sound driver to communicate with each to other.

[Volodymyr Babchuk <vlad.babchuk@xxxxxxxxx>]

Hello David,

I helped Oleksandr with parts of this protocol, so I want to address
some questions you asked.

On 16 November 2016 at 12:38, David Vrabel <david.vrabel@xxxxxxxxxx> wrote:
>
> Sound is not my area of expertise but I have a few points that you may
> like to consider.
>
> 1. You can only say how many channels a stream has, not what the
> channels correspond to (e.g., "left", "right" for a 2 channel stereo
> stream; or "left-front", "rear-right", etc. for a 6 channel 5.1 surround
> sound stream).
>
Yes, we can specify mapping. But problem that is no one expects this
information.
There are predefined orders like left-right or FR-FL-RR-RL-FC-LFE on
chosen platform and all audio software just know and use them.

But now I'm thinking that it is a good idea to add predefined orders
to the protocol.
If target platform have a different order (e.g. backend running on
Windows), than backend should reorder data.

> 2. Volume control uses absolute power levels (dBm). How is this supposed
> to map to the standard 0-100% volume controls that are most commonly
> presented to a user?
Aaaah, volumes. They are problematic. Different hardware use different
scales. They can be linear, logarithmic, they can have different
ranges, there can be integrated amplifiers, etc, etc. But good news
that audio subsystem always know how to remap those scales into dBm
scale. On this scale 0dBm is 100% and -inf dBm is 0%. If actual sound
hardware have internal gain, it will support volume above 0dBm (or
above 100%) and also will add distortion to sound, btw. There are
special formula that maps dBms to percens. This formula is non-linear.
Also, different sound systems can use different formulas. So it is
better not to stick to percents, because percents on Linux and on
Windows running on the same hardware will be different percents. Even
percents reported by ALSA and reported by PulseAudio are different.
We can't represent -inf as integer, but this is not needed, thanks to
logarithmic nature of dBm. Any sufficiently small value like -120dBm
will do the job and smallest possible value of -2147483,648dBm will be
indistinguishable from silence on any present or future hardware.

> 3. For the PCM formats you need to precisely specify the format or
> reference external specifications that do so.  For example, "mpeg" is a
> bit vague as I'm sure this standard body has produced many different
> audio formats.  The specifications don't need to be freely available,
> just correctly referenced.
>
> 4. 8 bits for stream index, operation and (particularly) pcm format feel
> a little limiting.
>
> 5. For the read/write operations is the stream buffer considered to be
> circular?  I think it probably should be.
>
> 6. PCM_FORMAT_SPECIAL doesn't seem useful to me.  New formats should be
> added via an update to this spec.
You can consider PCM_FORMAT_SPECIAL as raw format. I.e. "I know how to
prepare data for my device and my device expects audio in that
format". You don't need this on generic x86 system,
but it can be absolutely crucial on embedded system with hardware
accelerated audio/video playback for example.

-- 
WBR Volodymyr Babchuk aka lorc [+380976646013]
mailto: vlad.babchuk@xxxxxxxxx

_______________________________________________
Embedded-pv-devel mailing list
Embedded-pv-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/cgi-bin/mailman/listinfo/embedded-pv-devel