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

On 16 November 2016 at 15:31, David Vrabel <david.vrabel@xxxxxxxxxx> wrote:
> 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@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.
>
> 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).
Oops. Yes, you are right. Have no idea where dBm came from.


>>> 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?
In general case yes, there are no way to know something about real
hardware. But we tried to make protocol more generic. Imagine embedded
system, where guests can know about hardware and can exploit this
knowledge to improve performance. But I think you are right. Better to
remove SPECIAL format and then extend protocol locally if there will
arise need for this.
> Perhaps you could give an example of what one of these "special" formats
> looks like?
It can be anything. If we have an audio decoding accelerator, we can
dump mp3 or ac3 data right into sound card for example.

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

Oleksadr, what is your opinion on this?


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