Re: [Xen-devel][PATCH 0/2] sndif: add explicit back and front synchronization

[Oleksandr Andrushchenko <andr2000@gmail.com>]

On 03/06/2018 05:06 PM, Takashi Iwai wrote:
> On Tue, 06 Mar 2018 15:48:53 +0100,
> Oleksandr Andrushchenko wrote:
>>>>>>> And, now an open question for XEN comes: what kind of restriction
>>>>>>> should be applied to the frontend.  Obviously it depends on the
>>>>>>> backend, so there must be some communication, and the restriction must
>>>>>>> be propagated at open, i.e. *before* actually hw_params is performed.
>>>>>> Could you please give me a hint of what those restrictions
>>>>>> could look like? E.g. map of supported buffer/period sizes, what else?
>>>>> Heh, that very much depends on the hardware -- and in this case, on
>>>>> the implementation of the backend.
>>>> That is correct, but we try to be backend agnostic, though
>>>>> Practically seen, the buffer and the period size setups are mandatory,
>>>>> yes.  Here is the question whether you want to limit them by list
>>>>> (e.g. read via some XENSND_* protocol), or negotiate the size at each
>>>>> hw_params setup (e.g. getting only min/max at open, and at each
>>>>> hw_params call, negotiate with the backend for period and buffer size
>>>>> changes).
>>>> The problem I see here is that at .open real HW driver
>>>> already knows its constraints and can properly setup.
>>>> So, in our case at open we should already have all the
>>>> constraints available to the frontend as well.
>>>> That will lead to lots of text in domain configuration file
>>>> if propagated via XenStore (e.g. you have to put all possible
>>>> combinations of buffers/periods depending on number of
>>>> channels, sample rates etc., you cannot use logic here as you can
>>>> in a real HW driver, only values). So, such configuration doesn't
>>>> seem to be an option here.
>>> It depends.  If we do limit the configuration intentionally to only
>>> some subsets that should suffice for most use cases, then the list
>>> would be relatively short.
>> Ok, if we go with a limited set of supported buffer/period
>> sizes (and number of channels?), what could a constraint entry
>> look like? E.g. [buffer, period, num_channels, xxx]
>> What is that xxx in question? Sample rate, sample format,
>> anything else? Or [buffer, period, num_channels, rate, format]
>> is enough?
> The buffer, period, channels, rate and format are the basic
> parameters, and that should be enough for 99.9% cases.
Excellent, will use this set as the constraint entry.
Just to clarify for the upcoming Xen sound protocol change:
the values in this constraint are not ALSA specific and
could be used in implementation/OS agnostic Xen protocol.
>> I am still thinking on having the above sent at run-time with
>> a new protocol command, which I will call on .open, so I can
>> apply the constraints where most of the drivers do.
>> This way backend can also determine its capabilities at run-time
>> and report those to the frontend, as a bonus eliminating the
>> need for huge domain configuration file/XenStore entries.
> You don't have to list up all combinations of the parameters above at
> open time.  For example, declaring min/max of each of them at open
> would suffice at first.  (But this min/max might be even unnecessary
> if we implement the proper hw constraints.  See below)
>
> The rest fine-tuning is done via the hw constraints...
>
>>>> If we decide to negotiate the parameters, then it can't be done
>>>> at .open stage as well, as at this moment we don't know stream
>>>> parameters yet, e.g. we don't know the number of channels, PCM
>>>> format etc., so we cannot explain to the backend what we want.
>>>> Thus, it seems that we need to move the negotiation to .hw_params
>>>> callback where stream properties are known. But this leaves the
>>>> only option to ask the backend if it can handle the requested
>>>> buffer/period and other parameters or not... This is what I do now :(
>>> The additional parameter setup can be done via hw_constraints.  The hw
>>> constraint is basically a function call for each parameter change to
>>> narrow down the range of the given parameter.
>>>
>>> snd_pcm_hw_constraint_integer() in the above is just an example.
>>> The actual function to adjust values can be freely written.
>> Yes, this is clear, the question here mostly was not
>> *how* to set the constraints, but *where* to get those
> ... and here comes the hw constraint into the play.
>
> For each parameter change, for example, the frontend just passes the
> inquiry to the backend.  The basis of the hw constraint is nothing but
> to reduce the range of the given parameter.  It's either interval
> (range, used for period/buffer size or sample rate) or the list (for
> the format).  When any parameter is changed, ALSA PCM core invokes the
> corresponding hw constraint function, and the function reduces the
> range.  It's repeated until all parameters are set and settled down.
>
> So, for your driver, the frontend just passes the hw constraint for
> each of basic 5 parameters to the backend.  For example, at beginning,
> the hw constraint for the buffer size will pass the range (1,INTMAX).
> Then the backend returns the range like (1024,65536).   This already
> gives users the min/max buffer size information.  The similar
> procedure will be done for all other parameters.
>
> In addition, you can put the implicit rule like the integer periods,
> which makes things easier.
>
Thank you very much for such a detailed explanation.
Could you please give me an example of ALSA driver which
code I can read in order to understand how it is supposed
to be used, e.g. which meets the expectations we have for
Xen PV sound driver?
>>>> Am I missing something here?
>>>>> The format, the channels and the sample rate are already included in
>>>>> snd_pcm_hardware setup, so this should be OK, unless they have
>>>>> implicit limitations with each other (e.g. some format is available
>>>>> only under some rate).
>>>> Thank you, this should be up to the one who sets up the
>>>> domain configuration. Taking into account embedded nature of
>>>> our use-cases this is almost always doable, as these are
>>>> defined at system design time, e.g. we define number of channels
>>>> and their properties depending on domain functionality and needs.
>>>>> Maybe the channels need to be revisited, though; usually you can't
>>>>> handle all number of channels between min and max but only even
>>>>> numbers or such.
>>>> But if backend can implement some fancy stuff with software
>>>> mixing etc... This is why I didn't limit on that
>>> But if the backend doesn't support fancy numbers like 3 channels?
>>> That's the same situation as buffer / periods.  The frontend needs to
>>> know exactly what configuration the backend would allow.
>> Ok, did I understand you correctly that you see it as
>> described above, e.g. backend communicates (limited)
>> set of constraints to the frontend, so frontend sets
>> these constraints at .open?
> Well, what set at the open time is only the constraint "rule".
> And the rule is a function call, not necessarily static.
> The actual parameters are determined at hw_params call time, and this
> is called even repeatedly.
I need some time to think about all the above ;)
>> The way these are communicated could be either XenStore/
>> domain configuration or extension to the protocol, no preference
>> from your side?
> Again, the parameter setup pretty depends on the hardware, and in this
> case, the backend (and its communication).
>
>
> Takashi
Thank you!
Oleksandr