Re: alsalib and snd_pcm_hw_params_set_rate_minmax

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



+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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel



[Index of Archives]     [ALSA User]     [Linux Audio Users]     [Kernel Archive]     [Asterisk PBX]     [Photo Sharing]     [Linux Sound]     [Video 4 Linux]     [Gimp]     [Yosemite News]

  Powered by Linux