alsalib and snd_pcm_hw_params_set_rate_minmax

alsalib and snd_pcm_hw_params_set_rate_minmax

[Oleksandr Andrushchenko]

Hi,

Is it possible for user-space to reduce configuration space
with snd_pcm_hw_params_set_rate_minmax and then change it
with another snd_pcm_hw_params_set_rate_minmax with values
out of the reduced config?

For example, the initial min/max is 44100/48000 and I set 44100
first, e.g.

snd_pcm_hw_params_set_rate_minmax(handle, hw_params, 44100, 0, 44100, 0)

and then want

snd_pcm_hw_params_set_rate_minmax(handle, hw_params, 48000, 0, 48000, 0)

Obviously, the last call fails as we have already a reduced
space of [44100; 44100].

Is there a way I can still set the range to [48000; 48000]?

Thank you,
Oleksandr

P.S. This is in context of work done for [1]

[1] https://www.spinics.net/lists/alsa-devel/msg75382.html

Re: alsalib and snd_pcm_hw_params_set_rate_minmax

[Takashi Sakamoto]

Hi,

On Mar 15 2018 19:45, Oleksandr Andrushchenko wrote:
> Is it possible for user-space to reduce configuration space
> with snd_pcm_hw_params_set_rate_minmax and then change it
> with another snd_pcm_hw_params_set_rate_minmax with values
> out of the reduced config?
> 
> For example, the initial min/max is 44100/48000 and I set 44100
> first, e.g.
> 
> snd_pcm_hw_params_set_rate_minmax(handle, hw_params, 44100, 0, 44100, 0)
> 
> and then want
> 
> snd_pcm_hw_params_set_rate_minmax(handle, hw_params, 48000, 0, 48000, 0)
> 
> Obviously, the last call fails as we have already a reduced
> space of [44100; 44100].
> 
> Is there a way I can still set the range to [48000; 48000]?
> 
> Thank you,
> Oleksandr
> 
> P.S. This is in context of work done for [1]
> 
> [1] https://www.spinics.net/lists/alsa-devel/msg75382.html

We can't. Once shrinking available interval of a parameter, we cannot
expand it again without initializing the parameter on memory object for
'struct snd_pcm_hw_params_t', in which actual layout is never disclosed
to user applications.

If you can initialize whole the parameters, snd_pcm_hw_params_any() is
available for your purpose, then set min/max rate again. But just for
one of the parameters, in my opinion, we need to open an internal API; 
snd_pcm_hw_param_any()[1].

[1] 
http://git.alsa-project.org/?p=alsa-lib.git;a=blob;f=src/pcm/pcm_params.c;h=608a2324cb268f84d91f67c53d979521678f4edb;hb=HEAD#l107


Regards

Takashi Sakamoto

Re: alsalib and snd_pcm_hw_params_set_rate_minmax

[Oleksandr Andrushchenko]

On 03/15/2018 01:59 PM, Takashi Sakamoto wrote:
> Hi,
>
> On Mar 15 2018 19:45, Oleksandr Andrushchenko wrote:
>> Is it possible for user-space to reduce configuration space
>> with snd_pcm_hw_params_set_rate_minmax and then change it
>> with another snd_pcm_hw_params_set_rate_minmax with values
>> out of the reduced config?
>>
>> For example, the initial min/max is 44100/48000 and I set 44100
>> first, e.g.
>>
>> snd_pcm_hw_params_set_rate_minmax(handle, hw_params, 44100, 0, 44100, 0)
>>
>> and then want
>>
>> snd_pcm_hw_params_set_rate_minmax(handle, hw_params, 48000, 0, 48000, 0)
>>
>> Obviously, the last call fails as we have already a reduced
>> space of [44100; 44100].
>>
>> Is there a way I can still set the range to [48000; 48000]?
>>
>> Thank you,
>> Oleksandr
>>
>> P.S. This is in context of work done for [1]
>>
>> [1] https://www.spinics.net/lists/alsa-devel/msg75382.html
>
> We can't. Once shrinking available interval of a parameter, we cannot
> expand it again without initializing the parameter on memory object for
> 'struct snd_pcm_hw_params_t', in which actual layout is never disclosed
> to user applications.
So, this effectively means that this is a one way road, if you need to 
change
some parameter you'll need to start all over, so the whole configuration
space remains consistent :(
>
> If you can initialize whole the parameters, snd_pcm_hw_params_any() is
> available for your purpose, then set min/max rate again. 
This is what I do now but...
> But just for
> one of the parameters, in my opinion, we need to open an internal API; 
> snd_pcm_hw_param_any()[1].
IMO, this will lead to the false assumption that configuration is possible.
For example, I set 4 channels and 44100, but then, after 
snd_pcm_hw_params_any,
set 48000 and might assume that the configuration is still possible. But 
this may not
be true: it is true for the configuration returned by snd_pcm_hw_param_any
as we don't know about 4 channels yet. But might not be allowed if we 
want 4 channels
and 48000 at the same time.
>
> [1] 
> http://git.alsa-project.org/?p=alsa-lib.git;a=blob;f=src/pcm/pcm_params.c;h=608a2324cb268f84d91f67c53d979521678f4edb;hb=HEAD#l107
>
>
> Regards
>
> Takashi Sakamoto
Thank you very much for explanation,
Oleksandr

Re: alsalib and snd_pcm_hw_params_set_rate_minmax

[Takashi Sakamoto]

On Mar 15 2018 21:20, Oleksandr Andrushchenko wrote:
> On 03/15/2018 01:59 PM, Takashi Sakamoto wrote:
>> Hi,
>>
>> On Mar 15 2018 19:45, Oleksandr Andrushchenko wrote:
>>> Is it possible for user-space to reduce configuration space
>>> with snd_pcm_hw_params_set_rate_minmax and then change it
>>> with another snd_pcm_hw_params_set_rate_minmax with values
>>> out of the reduced config?
>>>
>>> For example, the initial min/max is 44100/48000 and I set 44100
>>> first, e.g.
>>>
>>> snd_pcm_hw_params_set_rate_minmax(handle, hw_params, 44100, 0, 44100, 0)
>>>
>>> and then want
>>>
>>> snd_pcm_hw_params_set_rate_minmax(handle, hw_params, 48000, 0, 48000, 0)
>>>
>>> Obviously, the last call fails as we have already a reduced
>>> space of [44100; 44100].
>>>
>>> Is there a way I can still set the range to [48000; 48000]?
>>>
>>> Thank you,
>>> Oleksandr
>>>
>>> P.S. This is in context of work done for [1]
>>>
>>> [1] https://www.spinics.net/lists/alsa-devel/msg75382.html
>>
>> We can't. Once shrinking available interval of a parameter, we cannot
>> expand it again without initializing the parameter on memory object for
>> 'struct snd_pcm_hw_params_t', in which actual layout is never disclosed
>> to user applications.
> So, this effectively means that this is a one way road, if you need to 
> change
> some parameter you'll need to start all over, so the whole configuration
> space remains consistent :(

You miss whole a design of ALSA PCM interface and protocol.

The protocol consists of interactions between applications, ALSA PCM
core and drivers:
1.Userspace applications are expected to allocate 'struct
   snd_pcm_hw_params' in its VMA, then fill it with maximum range and
   set of parameters.
2.The applications are expected to execute ioctl(2) with
    SNDRV_PCM_IOCTL_HW_REFINE, to inquire available set of parameters.
3.In kernel land, ALSA PCM core handles the ioctl request, then shrink
   range and set of parameters on the applications' VMA according to
   runtime information registered by used drivers.
4.In this time, in userspace, memory object for the
   'struct snd_pcm_hw_params' represents available range and set
   parameters. The applications are expected to decide actual value of
   the parameters. If no interests, leave them as is.
5.The applications are expected to execute ioctl(2) with
   SNDRV_PCM_IOCTL_HW_PARAMS finally.
6.In kernel land, ALSA PCM core handles the request, then choose final
   range and set of parameters.

In this protocol, one way is better because expanding range and set of
parameters brings ambiguity of available range and set.

>> If you can initialize whole the parameters, snd_pcm_hw_params_any() is
>> available for your purpose, then set min/max rate again. 
> This is what I do now but...
>> But just for
>> one of the parameters, in my opinion, we need to open an internal API; 
>> snd_pcm_hw_param_any()[1].
> IMO, this will lead to the false assumption that configuration is possible.
> For example, I set 4 channels and 44100, but then, after 
> snd_pcm_hw_params_any,
> set 48000 and might assume that the configuration is still possible. But 
> this may not
> be true: it is true for the configuration returned by snd_pcm_hw_param_any
> as we don't know about 4 channels yet. But might not be allowed if we 
> want 4 channels
> and 48000 at the same time.

Exactly. In short, it's not better idea to expand range and set of
parameters during the above steps.

For your information, in runtime of PCM substream, several parameters
can have dependency. Actually, to handle the dependency,
SNDRV_PCM_IOCTL_HW_REFINE should be called several times to inquire
available range and set of parameters to drivers which satisfies
hardware specification.


Regards

Takashi Sakamoto

Re: alsalib and snd_pcm_hw_params_set_rate_minmax

[Oleksandr Andrushchenko]

On 03/15/2018 02:45 PM, Takashi Sakamoto wrote:
> On Mar 15 2018 21:20, Oleksandr Andrushchenko wrote:
>> On 03/15/2018 01:59 PM, Takashi Sakamoto wrote:
>>> Hi,
>>>
>>> On Mar 15 2018 19:45, Oleksandr Andrushchenko wrote:
>>>> Is it possible for user-space to reduce configuration space
>>>> with snd_pcm_hw_params_set_rate_minmax and then change it
>>>> with another snd_pcm_hw_params_set_rate_minmax with values
>>>> out of the reduced config?
>>>>
>>>> For example, the initial min/max is 44100/48000 and I set 44100
>>>> first, e.g.
>>>>
>>>> snd_pcm_hw_params_set_rate_minmax(handle, hw_params, 44100, 0, 
>>>> 44100, 0)
>>>>
>>>> and then want
>>>>
>>>> snd_pcm_hw_params_set_rate_minmax(handle, hw_params, 48000, 0, 
>>>> 48000, 0)
>>>>
>>>> Obviously, the last call fails as we have already a reduced
>>>> space of [44100; 44100].
>>>>
>>>> Is there a way I can still set the range to [48000; 48000]?
>>>>
>>>> Thank you,
>>>> Oleksandr
>>>>
>>>> P.S. This is in context of work done for [1]
>>>>
>>>> [1] https://www.spinics.net/lists/alsa-devel/msg75382.html
>>>
>>> We can't. Once shrinking available interval of a parameter, we cannot
>>> expand it again without initializing the parameter on memory object for
>>> 'struct snd_pcm_hw_params_t', in which actual layout is never disclosed
>>> to user applications.
>> So, this effectively means that this is a one way road, if you need 
>> to change
>> some parameter you'll need to start all over, so the whole configuration
>> space remains consistent :(
>
> You miss whole a design of ALSA PCM interface and protocol.
>
Probably I was not clear: by one way road I meant that if I reduce 
configuration
space from [44100; 48000] to [44100; 44100] then there is no way to 
reconfigure
to [48000; 48000]
> The protocol consists of interactions between applications, ALSA PCM
> core and drivers:
> 1.Userspace applications are expected to allocate 'struct
>   snd_pcm_hw_params' in its VMA, then fill it with maximum range and
>   set of parameters.
> 2.The applications are expected to execute ioctl(2) with
>    SNDRV_PCM_IOCTL_HW_REFINE, to inquire available set of parameters.
> 3.In kernel land, ALSA PCM core handles the ioctl request, then shrink
>   range and set of parameters on the applications' VMA according to
>   runtime information registered by used drivers.
> 4.In this time, in userspace, memory object for the
>   'struct snd_pcm_hw_params' represents available range and set
>   parameters. The applications are expected to decide actual value of
>   the parameters. If no interests, leave them as is.
> 5.The applications are expected to execute ioctl(2) with
>   SNDRV_PCM_IOCTL_HW_PARAMS finally.
> 6.In kernel land, ALSA PCM core handles the request, then choose final
>   range and set of parameters.
>
> In this protocol, one way is better because expanding range and set of
> parameters brings ambiguity of available range and set.
No doubt here, as I am implementing a sound device driver I already know 
that,
but thank you anyways for great description
>
>>> If you can initialize whole the parameters, snd_pcm_hw_params_any() is
>>> available for your purpose, then set min/max rate again. 
>> This is what I do now but...
>>> But just for
>>> one of the parameters, in my opinion, we need to open an internal 
>>> API; snd_pcm_hw_param_any()[1].
>> IMO, this will lead to the false assumption that configuration is 
>> possible.
>> For example, I set 4 channels and 44100, but then, after 
>> snd_pcm_hw_params_any,
>> set 48000 and might assume that the configuration is still possible. 
>> But this may not
>> be true: it is true for the configuration returned by 
>> snd_pcm_hw_param_any
>> as we don't know about 4 channels yet. But might not be allowed if we 
>> want 4 channels
>> and 48000 at the same time.
>
> Exactly. In short, it's not better idea to expand range and set of
> parameters during the above steps.
>
> For your information, in runtime of PCM substream, several parameters
> can have dependency. Actually, to handle the dependency,
> SNDRV_PCM_IOCTL_HW_REFINE should be called several times to inquire
> available range and set of parameters to drivers which satisfies
> hardware specification.
>
Let me elaborate more on the reason of the question, so probably
bigger picture allows better understanding of my problem.

Recently I pushed a patch series for Xen hypervisor para-virtualized 
sound [1]
which aims to add a possibility for the frontend driver to negotiate HW PCM
parameters with the backend, so frontend can tell the user-space that
configuration is possible. Please see this discussion [2] where Takashi Iwai
has provided me with great explanation on how to implement that with the use
of rules in the frontend driver. This does work as expected, so I can 
intersect
all those calls when user-space refines HW parameters.
The problem is that the backend is a user-space application and whenever I
pass a parameter interval from kernel driver (frontend) to the backend I 
only
have alsalib API to refine the range. So, on backend side I see 
something like:

# aplay --dump-hw-params alsa/sample.wav
[ frontend] --------------------- alsa_open
[ backend ] snd_pcm_hw_params_any(mHwQueryHandle, mHwQueryParams))
Playing WAVE 'alsa/sample.wav' : Signed 16 bit Little Endian, Rate 44100 
Hz, Stereo
...
[ frontend] rule->var 11 ret 1 min 44100 max 48000
[ backend ] snd_pcm_hw_params_set_rate_minmax(..., 44100, 0, 48000, 0) -> Ok
...
[ frontend] rule->var 11 ret 0 *min 44100 max 44100*
[ backend ] snd_pcm_hw_params_set_rate_minmax(..., 44100, 0, 44100, 0) -> Ok
...
[ frontend] rule->var 11 ret 0 *min 48000 max 48000*
[ backend ] snd_pcm_hw_params_set_rate_minmax(..., 48000, 0, 48000, 0) 
-> Fail

So, the last one obviously fails on backend side but still valid for the 
frontend.
This is from where the original question came from.

Hope this clarifies my use-case.
>
> Regards
>
> Takashi Sakamoto
Thank you,
Oleksandr Andrushchenko

[2] https://www.spinics.net/lists/alsa-devel/msg75005.html
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: alsalib and snd_pcm_hw_params_set_rate_minmax

[Takashi Iwai]

On Thu, 15 Mar 2018 13:20:14 +0100,
Oleksandr Andrushchenko wrote:
> 
> On 03/15/2018 01:59 PM, Takashi Sakamoto wrote:
> > Hi,
> >
> > On Mar 15 2018 19:45, Oleksandr Andrushchenko wrote:
> >> Is it possible for user-space to reduce configuration space
> >> with snd_pcm_hw_params_set_rate_minmax and then change it
> >> with another snd_pcm_hw_params_set_rate_minmax with values
> >> out of the reduced config?
> >>
> >> For example, the initial min/max is 44100/48000 and I set 44100
> >> first, e.g.
> >>
> >> snd_pcm_hw_params_set_rate_minmax(handle, hw_params, 44100, 0, 44100, 0)
> >>
> >> and then want
> >>
> >> snd_pcm_hw_params_set_rate_minmax(handle, hw_params, 48000, 0, 48000, 0)
> >>
> >> Obviously, the last call fails as we have already a reduced
> >> space of [44100; 44100].
> >>
> >> Is there a way I can still set the range to [48000; 48000]?
> >>
> >> Thank you,
> >> Oleksandr
> >>
> >> P.S. This is in context of work done for [1]
> >>
> >> [1] https://www.spinics.net/lists/alsa-devel/msg75382.html
> >
> > We can't. Once shrinking available interval of a parameter, we cannot
> > expand it again without initializing the parameter on memory object for
> > 'struct snd_pcm_hw_params_t', in which actual layout is never disclosed
> > to user applications.
> So, this effectively means that this is a one way road, if you need to
> change
> some parameter you'll need to start all over, so the whole configuration
> space remains consistent :(

Yes, that's the design.  The only way to expand is to reset the whole,
space and reduce again to the given size.


> > If you can initialize whole the parameters, snd_pcm_hw_params_any() is
> > available for your purpose, then set min/max rate again. 
> This is what I do now but...
> > But just for
> > one of the parameters, in my opinion, we need to open an internal
> > API; snd_pcm_hw_param_any()[1].
> IMO, this will lead to the false assumption that configuration is possible.
> For example, I set 4 channels and 44100, but then, after
> snd_pcm_hw_params_any,
> set 48000 and might assume that the configuration is still
> possible. But this may not
> be true: it is true for the configuration returned by snd_pcm_hw_param_any
> as we don't know about 4 channels yet. But might not be allowed if we
> want 4 channels
> and 48000 at the same time.

Right.  At the point where snd_pcm_hw_params_any() is called, the
whole configuration gets reset.  That's the reason I thought we may
need to pass all 5 parameters in the query protocol.

IOW, the query stuff won't be modal, it just tries to reduce the given
configuration space to the acceptable ranges.


Takashi

Re: alsalib and snd_pcm_hw_params_set_rate_minmax

[Oleksandr Andrushchenko]

On 03/15/2018 03:23 PM, Takashi Iwai wrote:
> On Thu, 15 Mar 2018 13:20:14 +0100,
> Oleksandr Andrushchenko wrote:
>> On 03/15/2018 01:59 PM, Takashi Sakamoto wrote:
>>> Hi,
>>>
>>> On Mar 15 2018 19:45, Oleksandr Andrushchenko wrote:
>>>> Is it possible for user-space to reduce configuration space
>>>> with snd_pcm_hw_params_set_rate_minmax and then change it
>>>> with another snd_pcm_hw_params_set_rate_minmax with values
>>>> out of the reduced config?
>>>>
>>>> For example, the initial min/max is 44100/48000 and I set 44100
>>>> first, e.g.
>>>>
>>>> snd_pcm_hw_params_set_rate_minmax(handle, hw_params, 44100, 0, 44100, 0)
>>>>
>>>> and then want
>>>>
>>>> snd_pcm_hw_params_set_rate_minmax(handle, hw_params, 48000, 0, 48000, 0)
>>>>
>>>> Obviously, the last call fails as we have already a reduced
>>>> space of [44100; 44100].
>>>>
>>>> Is there a way I can still set the range to [48000; 48000]?
>>>>
>>>> Thank you,
>>>> Oleksandr
>>>>
>>>> P.S. This is in context of work done for [1]
>>>>
>>>> [1] https://www.spinics.net/lists/alsa-devel/msg75382.html
>>> We can't. Once shrinking available interval of a parameter, we cannot
>>> expand it again without initializing the parameter on memory object for
>>> 'struct snd_pcm_hw_params_t', in which actual layout is never disclosed
>>> to user applications.
>> So, this effectively means that this is a one way road, if you need to
>> change
>> some parameter you'll need to start all over, so the whole configuration
>> space remains consistent :(
> Yes, that's the design.  The only way to expand is to reset the whole,
> space and reduce again to the given size.
>
Clear, thank you
>>> If you can initialize whole the parameters, snd_pcm_hw_params_any() is
>>> available for your purpose, then set min/max rate again.
>> This is what I do now but...
>>> But just for
>>> one of the parameters, in my opinion, we need to open an internal
>>> API; snd_pcm_hw_param_any()[1].
>> IMO, this will lead to the false assumption that configuration is possible.
>> For example, I set 4 channels and 44100, but then, after
>> snd_pcm_hw_params_any,
>> set 48000 and might assume that the configuration is still
>> possible. But this may not
>> be true: it is true for the configuration returned by snd_pcm_hw_param_any
>> as we don't know about 4 channels yet. But might not be allowed if we
>> want 4 channels
>> and 48000 at the same time.
> Right.  At the point where snd_pcm_hw_params_any() is called, the
> whole configuration gets reset.  That's the reason I thought we may
> need to pass all 5 parameters in the query protocol.
Yes, I now start thinking of the same, e.g. if we pass
all 5 parameters (mask for formats and intervals for rate, channels,
buffer and period), then on backend side I can do something like:

1. snd_pcm_hw_params_any
2. snd_pcm_hw_params_set_format_mask
3. snd_pcm_hw_params_set_rate_minmax
4. snd_pcm_hw_params_set_channels_minmax
5. snd_pcm_hw_params_set_buffer_size_minmax
6. snd_pcm_hw_params_set_period_size_minmax

So, when finished the above confirms that configuration is possible.
The only concern here is that so many calls on backend side
might introduce start-up latency on frontend side though

> IOW, the query stuff won't be modal, it just tries to reduce the given
> configuration space to the acceptable ranges.
Do you think the above solution with 5 parameters and the
corresponding snd_pcm_hw_params_set_xxx calls will do?

>
> Takashi
Thank you,
Oleksandr

Re: alsalib and snd_pcm_hw_params_set_rate_minmax

[Takashi Iwai]

On Thu, 15 Mar 2018 14:39:33 +0100,
Oleksandr Andrushchenko wrote:
> 
> On 03/15/2018 03:23 PM, Takashi Iwai wrote:
> > On Thu, 15 Mar 2018 13:20:14 +0100,
> > Oleksandr Andrushchenko wrote:
> >> On 03/15/2018 01:59 PM, Takashi Sakamoto wrote:
> >>> Hi,
> >>>
> >>> On Mar 15 2018 19:45, Oleksandr Andrushchenko wrote:
> >>>> Is it possible for user-space to reduce configuration space
> >>>> with snd_pcm_hw_params_set_rate_minmax and then change it
> >>>> with another snd_pcm_hw_params_set_rate_minmax with values
> >>>> out of the reduced config?
> >>>>
> >>>> For example, the initial min/max is 44100/48000 and I set 44100
> >>>> first, e.g.
> >>>>
> >>>> snd_pcm_hw_params_set_rate_minmax(handle, hw_params, 44100, 0, 44100, 0)
> >>>>
> >>>> and then want
> >>>>
> >>>> snd_pcm_hw_params_set_rate_minmax(handle, hw_params, 48000, 0, 48000, 0)
> >>>>
> >>>> Obviously, the last call fails as we have already a reduced
> >>>> space of [44100; 44100].
> >>>>
> >>>> Is there a way I can still set the range to [48000; 48000]?
> >>>>
> >>>> Thank you,
> >>>> Oleksandr
> >>>>
> >>>> P.S. This is in context of work done for [1]
> >>>>
> >>>> [1] https://www.spinics.net/lists/alsa-devel/msg75382.html
> >>> We can't. Once shrinking available interval of a parameter, we cannot
> >>> expand it again without initializing the parameter on memory object for
> >>> 'struct snd_pcm_hw_params_t', in which actual layout is never disclosed
> >>> to user applications.
> >> So, this effectively means that this is a one way road, if you need to
> >> change
> >> some parameter you'll need to start all over, so the whole configuration
> >> space remains consistent :(
> > Yes, that's the design.  The only way to expand is to reset the whole,
> > space and reduce again to the given size.
> >
> Clear, thank you
> >>> If you can initialize whole the parameters, snd_pcm_hw_params_any() is
> >>> available for your purpose, then set min/max rate again.
> >> This is what I do now but...
> >>> But just for
> >>> one of the parameters, in my opinion, we need to open an internal
> >>> API; snd_pcm_hw_param_any()[1].
> >> IMO, this will lead to the false assumption that configuration is possible.
> >> For example, I set 4 channels and 44100, but then, after
> >> snd_pcm_hw_params_any,
> >> set 48000 and might assume that the configuration is still
> >> possible. But this may not
> >> be true: it is true for the configuration returned by snd_pcm_hw_param_any
> >> as we don't know about 4 channels yet. But might not be allowed if we
> >> want 4 channels
> >> and 48000 at the same time.
> > Right.  At the point where snd_pcm_hw_params_any() is called, the
> > whole configuration gets reset.  That's the reason I thought we may
> > need to pass all 5 parameters in the query protocol.
> Yes, I now start thinking of the same, e.g. if we pass
> all 5 parameters (mask for formats and intervals for rate, channels,
> buffer and period), then on backend side I can do something like:
> 
> 1. snd_pcm_hw_params_any
> 2. snd_pcm_hw_params_set_format_mask
> 3. snd_pcm_hw_params_set_rate_minmax
> 4. snd_pcm_hw_params_set_channels_minmax
> 5. snd_pcm_hw_params_set_buffer_size_minmax
> 6. snd_pcm_hw_params_set_period_size_minmax
> 
> So, when finished the above confirms that configuration is possible.
> The only concern here is that so many calls on backend side
> might introduce start-up latency on frontend side though
> 
> > IOW, the query stuff won't be modal, it just tries to reduce the given
> > configuration space to the acceptable ranges.
> Do you think the above solution with 5 parameters and the
> corresponding snd_pcm_hw_params_set_xxx calls will do?

I guess so, but let's model & test :)


thanks,

Takashi

Re: alsalib and snd_pcm_hw_params_set_rate_minmax

[Oleksandr Andrushchenko]

+Konrad

On 03/15/2018 10:29 PM, Takashi Iwai wrote:
> On Thu, 15 Mar 2018 14:39:33 +0100,
> Oleksandr Andrushchenko wrote:
>> On 03/15/2018 03:23 PM, Takashi Iwai wrote:
>>> On Thu, 15 Mar 2018 13:20:14 +0100,
>>> Oleksandr Andrushchenko wrote:
>>>> On 03/15/2018 01:59 PM, Takashi Sakamoto wrote:
>>>>> Hi,
>>>>>
>>>>> On Mar 15 2018 19:45, Oleksandr Andrushchenko wrote:
>>>>>> Is it possible for user-space to reduce configuration space
>>>>>> with snd_pcm_hw_params_set_rate_minmax and then change it
>>>>>> with another snd_pcm_hw_params_set_rate_minmax with values
>>>>>> out of the reduced config?
>>>>>>
>>>>>> For example, the initial min/max is 44100/48000 and I set 44100
>>>>>> first, e.g.
>>>>>>
>>>>>> snd_pcm_hw_params_set_rate_minmax(handle, hw_params, 44100, 0, 44100, 0)
>>>>>>
>>>>>> and then want
>>>>>>
>>>>>> snd_pcm_hw_params_set_rate_minmax(handle, hw_params, 48000, 0, 48000, 0)
>>>>>>
>>>>>> Obviously, the last call fails as we have already a reduced
>>>>>> space of [44100; 44100].
>>>>>>
>>>>>> Is there a way I can still set the range to [48000; 48000]?
>>>>>>
>>>>>> Thank you,
>>>>>> Oleksandr
>>>>>>
>>>>>> P.S. This is in context of work done for [1]
>>>>>>
>>>>>> [1] https://www.spinics.net/lists/alsa-devel/msg75382.html
>>>>> We can't. Once shrinking available interval of a parameter, we cannot
>>>>> expand it again without initializing the parameter on memory object for
>>>>> 'struct snd_pcm_hw_params_t', in which actual layout is never disclosed
>>>>> to user applications.
>>>> So, this effectively means that this is a one way road, if you need to
>>>> change
>>>> some parameter you'll need to start all over, so the whole configuration
>>>> space remains consistent :(
>>> Yes, that's the design.  The only way to expand is to reset the whole,
>>> space and reduce again to the given size.
>>>
>> Clear, thank you
>>>>> If you can initialize whole the parameters, snd_pcm_hw_params_any() is
>>>>> available for your purpose, then set min/max rate again.
>>>> This is what I do now but...
>>>>> But just for
>>>>> one of the parameters, in my opinion, we need to open an internal
>>>>> API; snd_pcm_hw_param_any()[1].
>>>> IMO, this will lead to the false assumption that configuration is possible.
>>>> For example, I set 4 channels and 44100, but then, after
>>>> snd_pcm_hw_params_any,
>>>> set 48000 and might assume that the configuration is still
>>>> possible. But this may not
>>>> be true: it is true for the configuration returned by snd_pcm_hw_param_any
>>>> as we don't know about 4 channels yet. But might not be allowed if we
>>>> want 4 channels
>>>> and 48000 at the same time.
>>> Right.  At the point where snd_pcm_hw_params_any() is called, the
>>> whole configuration gets reset.  That's the reason I thought we may
>>> need to pass all 5 parameters in the query protocol.
>> Yes, I now start thinking of the same, e.g. if we pass
>> all 5 parameters (mask for formats and intervals for rate, channels,
>> buffer and period), then on backend side I can do something like:
>>
>> 1. snd_pcm_hw_params_any
>> 2. snd_pcm_hw_params_set_format_mask
>> 3. snd_pcm_hw_params_set_rate_minmax
>> 4. snd_pcm_hw_params_set_channels_minmax
>> 5. snd_pcm_hw_params_set_buffer_size_minmax
>> 6. snd_pcm_hw_params_set_period_size_minmax
>>
>> So, when finished the above confirms that configuration is possible.
>> The only concern here is that so many calls on backend side
>> might introduce start-up latency on frontend side though
>>
>>> IOW, the query stuff won't be modal, it just tries to reduce the given
>>> configuration space to the acceptable ranges.
>> Do you think the above solution with 5 parameters and the
>> corresponding snd_pcm_hw_params_set_xxx calls will do?
> I guess so, but let's model & test :)
I did some testing:
- frontend driver [1]
- sndif protocol [2]
- backend changes [3]

All seem to work now when I pass all 5 parameters while querying.
The only scary thing is that I had to change the size of
requests/responses in the sndif protocol from 32 to 64 bytes :(

Takashi, could you please have a quick look and tell me if
this is what you expect?
>
> thanks,
>
> Takashi
Thank you,
Oleksandr

[1] 
https://github.com/andr2000/linux/commits/tiwai_sound_for_next_pv_snd_upstream_v2
[2] https://github.com/andr2000/xen/commits/pr_sndif_v3
[3] https://github.com/andr2000/snd_be/commits/pr_hw_param

Re: alsalib and snd_pcm_hw_params_set_rate_minmax

[Konrad Rzeszutek Wilk]

.snip..
> All seem to work now when I pass all 5 parameters while querying.
> The only scary thing is that I had to change the size of
> requests/responses in the sndif protocol from 32 to 64 bytes :(

Oh boy. Well, are there any other users beside your code? In which case we could
just sweep it under the rug and pretend we never had it at 32 bytes.

> 
> Takashi, could you please have a quick look and tell me if
> this is what you expect?
> > 
> > thanks,
> > 
> > Takashi
> Thank you,
> Oleksandr
> 
> [1] https://github.com/andr2000/linux/commits/tiwai_sound_for_next_pv_snd_upstream_v2
> [2] https://github.com/andr2000/xen/commits/pr_sndif_v3
> [3] https://github.com/andr2000/snd_be/commits/pr_hw_param

Re: alsalib and snd_pcm_hw_params_set_rate_minmax

[Oleksandr Andrushchenko]

On 03/16/2018 02:50 PM, Konrad Rzeszutek Wilk wrote:
> .snip..
>> All seem to work now when I pass all 5 parameters while querying.
>> The only scary thing is that I had to change the size of
>> requests/responses in the sndif protocol from 32 to 64 bytes :(
> Oh boy. Well, are there any other users beside your code? In which case we could
> just sweep it under the rug and pretend we never had it at 32 bytes.
As far as I know - no other users, so this seems to be the
right time for the change.

At least I heard of nobody using the protocol
and trying to upstream frontend/backend implementations
>> Takashi, could you please have a quick look and tell me if
>> this is what you expect?
>>> thanks,
>>>
>>> Takashi
>> Thank you,
>> Oleksandr
>>
>> [1] https://github.com/andr2000/linux/commits/tiwai_sound_for_next_pv_snd_upstream_v2
>> [2] https://github.com/andr2000/xen/commits/pr_sndif_v3
>> [3] https://github.com/andr2000/snd_be/commits/pr_hw_param

Re: alsalib and snd_pcm_hw_params_set_rate_minmax

[Takashi Iwai]

On Fri, 16 Mar 2018 11:17:19 +0100,
Oleksandr Andrushchenko wrote:
> 
> +Konrad
> 
> On 03/15/2018 10:29 PM, Takashi Iwai wrote:
> > On Thu, 15 Mar 2018 14:39:33 +0100,
> > Oleksandr Andrushchenko wrote:
> >> On 03/15/2018 03:23 PM, Takashi Iwai wrote:
> >>> On Thu, 15 Mar 2018 13:20:14 +0100,
> >>> Oleksandr Andrushchenko wrote:
> >>>> On 03/15/2018 01:59 PM, Takashi Sakamoto wrote:
> >>>>> Hi,
> >>>>>
> >>>>> On Mar 15 2018 19:45, Oleksandr Andrushchenko wrote:
> >>>>>> Is it possible for user-space to reduce configuration space
> >>>>>> with snd_pcm_hw_params_set_rate_minmax and then change it
> >>>>>> with another snd_pcm_hw_params_set_rate_minmax with values
> >>>>>> out of the reduced config?
> >>>>>>
> >>>>>> For example, the initial min/max is 44100/48000 and I set 44100
> >>>>>> first, e.g.
> >>>>>>
> >>>>>> snd_pcm_hw_params_set_rate_minmax(handle, hw_params, 44100, 0, 44100, 0)
> >>>>>>
> >>>>>> and then want
> >>>>>>
> >>>>>> snd_pcm_hw_params_set_rate_minmax(handle, hw_params, 48000, 0, 48000, 0)
> >>>>>>
> >>>>>> Obviously, the last call fails as we have already a reduced
> >>>>>> space of [44100; 44100].
> >>>>>>
> >>>>>> Is there a way I can still set the range to [48000; 48000]?
> >>>>>>
> >>>>>> Thank you,
> >>>>>> Oleksandr
> >>>>>>
> >>>>>> P.S. This is in context of work done for [1]
> >>>>>>
> >>>>>> [1] https://www.spinics.net/lists/alsa-devel/msg75382.html
> >>>>> We can't. Once shrinking available interval of a parameter, we cannot
> >>>>> expand it again without initializing the parameter on memory object for
> >>>>> 'struct snd_pcm_hw_params_t', in which actual layout is never disclosed
> >>>>> to user applications.
> >>>> So, this effectively means that this is a one way road, if you need to
> >>>> change
> >>>> some parameter you'll need to start all over, so the whole configuration
> >>>> space remains consistent :(
> >>> Yes, that's the design.  The only way to expand is to reset the whole,
> >>> space and reduce again to the given size.
> >>>
> >> Clear, thank you
> >>>>> If you can initialize whole the parameters, snd_pcm_hw_params_any() is
> >>>>> available for your purpose, then set min/max rate again.
> >>>> This is what I do now but...
> >>>>> But just for
> >>>>> one of the parameters, in my opinion, we need to open an internal
> >>>>> API; snd_pcm_hw_param_any()[1].
> >>>> IMO, this will lead to the false assumption that configuration is possible.
> >>>> For example, I set 4 channels and 44100, but then, after
> >>>> snd_pcm_hw_params_any,
> >>>> set 48000 and might assume that the configuration is still
> >>>> possible. But this may not
> >>>> be true: it is true for the configuration returned by snd_pcm_hw_param_any
> >>>> as we don't know about 4 channels yet. But might not be allowed if we
> >>>> want 4 channels
> >>>> and 48000 at the same time.
> >>> Right.  At the point where snd_pcm_hw_params_any() is called, the
> >>> whole configuration gets reset.  That's the reason I thought we may
> >>> need to pass all 5 parameters in the query protocol.
> >> Yes, I now start thinking of the same, e.g. if we pass
> >> all 5 parameters (mask for formats and intervals for rate, channels,
> >> buffer and period), then on backend side I can do something like:
> >>
> >> 1. snd_pcm_hw_params_any
> >> 2. snd_pcm_hw_params_set_format_mask
> >> 3. snd_pcm_hw_params_set_rate_minmax
> >> 4. snd_pcm_hw_params_set_channels_minmax
> >> 5. snd_pcm_hw_params_set_buffer_size_minmax
> >> 6. snd_pcm_hw_params_set_period_size_minmax
> >>
> >> So, when finished the above confirms that configuration is possible.
> >> The only concern here is that so many calls on backend side
> >> might introduce start-up latency on frontend side though
> >>
> >>> IOW, the query stuff won't be modal, it just tries to reduce the given
> >>> configuration space to the acceptable ranges.
> >> Do you think the above solution with 5 parameters and the
> >> corresponding snd_pcm_hw_params_set_xxx calls will do?
> > I guess so, but let's model & test :)
> I did some testing:
> - frontend driver [1]
> - sndif protocol [2]
> - backend changes [3]
> 
> All seem to work now when I pass all 5 parameters while querying.
> The only scary thing is that I had to change the size of
> requests/responses in the sndif protocol from 32 to 64 bytes :(

You may split the protocol from a single shot to a sequence, too, if
the size really matters :)

> Takashi, could you please have a quick look and tell me if
> this is what you expect?

Through a quick glance, it looks good to me.
If it works, even better.


thanks,

Takashi

Re: alsalib and snd_pcm_hw_params_set_rate_minmax

[Oleksandr Andrushchenko]

On 03/16/2018 05:05 PM, Takashi Iwai wrote:
> On Fri, 16 Mar 2018 11:17:19 +0100,
> Oleksandr Andrushchenko wrote:
>> +Konrad
>>
>> On 03/15/2018 10:29 PM, Takashi Iwai wrote:
>>> On Thu, 15 Mar 2018 14:39:33 +0100,
>>> Oleksandr Andrushchenko wrote:
>>>> On 03/15/2018 03:23 PM, Takashi Iwai wrote:
>>>>> On Thu, 15 Mar 2018 13:20:14 +0100,
>>>>> Oleksandr Andrushchenko wrote:
>>>>>> On 03/15/2018 01:59 PM, Takashi Sakamoto wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> On Mar 15 2018 19:45, Oleksandr Andrushchenko wrote:
>>>>>>>> Is it possible for user-space to reduce configuration space
>>>>>>>> with snd_pcm_hw_params_set_rate_minmax and then change it
>>>>>>>> with another snd_pcm_hw_params_set_rate_minmax with values
>>>>>>>> out of the reduced config?
>>>>>>>>
>>>>>>>> For example, the initial min/max is 44100/48000 and I set 44100
>>>>>>>> first, e.g.
>>>>>>>>
>>>>>>>> snd_pcm_hw_params_set_rate_minmax(handle, hw_params, 44100, 0, 44100, 0)
>>>>>>>>
>>>>>>>> and then want
>>>>>>>>
>>>>>>>> snd_pcm_hw_params_set_rate_minmax(handle, hw_params, 48000, 0, 48000, 0)
>>>>>>>>
>>>>>>>> Obviously, the last call fails as we have already a reduced
>>>>>>>> space of [44100; 44100].
>>>>>>>>
>>>>>>>> Is there a way I can still set the range to [48000; 48000]?
>>>>>>>>
>>>>>>>> Thank you,
>>>>>>>> Oleksandr
>>>>>>>>
>>>>>>>> P.S. This is in context of work done for [1]
>>>>>>>>
>>>>>>>> [1] https://www.spinics.net/lists/alsa-devel/msg75382.html
>>>>>>> We can't. Once shrinking available interval of a parameter, we cannot
>>>>>>> expand it again without initializing the parameter on memory object for
>>>>>>> 'struct snd_pcm_hw_params_t', in which actual layout is never disclosed
>>>>>>> to user applications.
>>>>>> So, this effectively means that this is a one way road, if you need to
>>>>>> change
>>>>>> some parameter you'll need to start all over, so the whole configuration
>>>>>> space remains consistent :(
>>>>> Yes, that's the design.  The only way to expand is to reset the whole,
>>>>> space and reduce again to the given size.
>>>>>
>>>> Clear, thank you
>>>>>>> If you can initialize whole the parameters, snd_pcm_hw_params_any() is
>>>>>>> available for your purpose, then set min/max rate again.
>>>>>> This is what I do now but...
>>>>>>> But just for
>>>>>>> one of the parameters, in my opinion, we need to open an internal
>>>>>>> API; snd_pcm_hw_param_any()[1].
>>>>>> IMO, this will lead to the false assumption that configuration is possible.
>>>>>> For example, I set 4 channels and 44100, but then, after
>>>>>> snd_pcm_hw_params_any,
>>>>>> set 48000 and might assume that the configuration is still
>>>>>> possible. But this may not
>>>>>> be true: it is true for the configuration returned by snd_pcm_hw_param_any
>>>>>> as we don't know about 4 channels yet. But might not be allowed if we
>>>>>> want 4 channels
>>>>>> and 48000 at the same time.
>>>>> Right.  At the point where snd_pcm_hw_params_any() is called, the
>>>>> whole configuration gets reset.  That's the reason I thought we may
>>>>> need to pass all 5 parameters in the query protocol.
>>>> Yes, I now start thinking of the same, e.g. if we pass
>>>> all 5 parameters (mask for formats and intervals for rate, channels,
>>>> buffer and period), then on backend side I can do something like:
>>>>
>>>> 1. snd_pcm_hw_params_any
>>>> 2. snd_pcm_hw_params_set_format_mask
>>>> 3. snd_pcm_hw_params_set_rate_minmax
>>>> 4. snd_pcm_hw_params_set_channels_minmax
>>>> 5. snd_pcm_hw_params_set_buffer_size_minmax
>>>> 6. snd_pcm_hw_params_set_period_size_minmax
>>>>
>>>> So, when finished the above confirms that configuration is possible.
>>>> The only concern here is that so many calls on backend side
>>>> might introduce start-up latency on frontend side though
>>>>
>>>>> IOW, the query stuff won't be modal, it just tries to reduce the given
>>>>> configuration space to the acceptable ranges.
>>>> Do you think the above solution with 5 parameters and the
>>>> corresponding snd_pcm_hw_params_set_xxx calls will do?
>>> I guess so, but let's model & test :)
>> I did some testing:
>> - frontend driver [1]
>> - sndif protocol [2]
>> - backend changes [3]
>>
>> All seem to work now when I pass all 5 parameters while querying.
>> The only scary thing is that I had to change the size of
>> requests/responses in the sndif protocol from 32 to 64 bytes :(
> You may split the protocol from a single shot to a sequence, too, if
> the size really matters :)
But this will complicate things, e.g. I'll have to collect
the whole thing from pieces before I can try applying the
configuration. What is more it will increase number of IO
operations between front and back by 5, thus increasing start up
latency
>> Takashi, could you please have a quick look and tell me if
>> this is what you expect?
> Through a quick glance, it looks good to me.
> If it works, even better.
Ok, thank you
>
> thanks,
>
> Takashi

Thank you,
Oleksandr