Re: [PATCH] [updated] pcm: rate: Add capability to pass configuration node to plugins

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

 



On 14/02/17 07:08, Takashi Iwai wrote:
On Mon, 13 Feb 2017 18:20:01 +0100,
Alan Young wrote:
Here is a revised patch.

It is useful for the converter used by a rate plugin to be capable of
receiving configuration. This patch enables the "converter" node of
the configuration of a "type rate" plugin to be specified as a
compound and passed to open func of the converter plugin.

The SND_PCM_RATE_PLUGIN_CONF_ENTRY macro is used to define a rate
converter plugin entry point that takes the additional snd_config_t
*conf parameter. If a rate converter plugin also supports the existing
SND_PCM_RATE_PLUGIN_ENTRY entry point, or if passed conf parameter is
NULL then it is up to the plugin to determine whether or not this is a
fatal condition.

Alan.
The changes look almost good, but one uncertain change:

  	else if (snd_config_get_type(converter) == SND_CONFIG_TYPE_COMPOUND) {
  		snd_config_iterator_t i, next;
  		snd_config_for_each(i, next, converter) {
  			snd_config_t *n = snd_config_iterator_entry(i);
+			const char *id;
  			if (snd_config_get_string(n, &type) < 0)
  				break;
-			err = rate_open_func(rate, type, 0);
+			err = rate_open_func(rate, type, converter, 0);
  			if (!err)
  				break;
+			if (snd_config_get_id(n, &id) >= 0 && id && strcmp(id, "0") != 0)
+				break; /* not a simple array of types */
What does this check exactly...?


In the case that snd_config_get_type(converter) == SND_CONFIG_TYPE_COMPOUND, this could be for one of two reasons:

1. Where the configuration contains something like converter {name xxx,
   other stuff ...}, or
2. where configuration contains something like [first second third].

In the later case, the id fields will be digit strings, with the first entry having the id "0". The test simply stops going around the loop looking for further alternatives if the first did not have id "0".

However, looking at that again now, I see that the test is flawed because it has no marker to check that it is only applied on the first iteration, so the loop would always stop after testing the second alternative. I could fix that or remove the test altogether - what do you think?

Alan.

_______________________________________________
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