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

[David Vrabel <david.vrabel@citrix.com>]

On 16/11/16 13:12, Volodymyr Babchuk wrote:
> 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@citrix.com> 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.

Specifying a fixed ordering of channels is fine.

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

This all sounds fine to me except you've got the units wrong and you
really mean dB (not dBm where 0 dBm == 1 mW of output power which
doesn't make a whole lot of sense in this context).

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

The frontend doesn't know what the underlying hardware is so how can it
know what format SPECIAL means?

Perhaps you could give an example of what one of these "special" formats
looks like?

I think it would be better to define a format number/name for each
special format.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel