[alsa-devel] 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