On Fri, Oct 23, 2015 at 3:47 AM, Liam Girdwood liam.r.girdwood@linux.intel.com wrote:
Hi Caleb,
I have no problem as long as we can still support Android (via tinyalsa) and Chrome (via alsa-lib) and also tinycompress. You will need to justify any changes you make in your commit message.
Btw, probably best to also CC alsa-devel mailing list for these sort of questions too as other folks doing BAT patches may also be interested.
Fwiw, a structure like your proposing could also be used for SIMD based optimisations too (if we ever need them).
Liam
On Thu, 2015-10-22 at 17:23 -0700, Caleb Crome wrote:
Hi guys, since i've got several different tests to write, I'm basically rewriting a meaningful section of the code to make the init/generate/playout/analyze modular.
To that end, I'm creating a struct like this:
struct bat_ops { (void *)(*init)(int channels, int format, float sample_rate, float *frequencies) // generate_playout_data is called every period to, well, generate the data to be played. int (*generate_playout_data)(void *priv, int frames, void *buffer); // process_capture_data is called every period to do something with the data. int (*process_input_data)(void *priv, int frames, const void *buffer); // analyze is called at the end of the whole capture time. Can be used to analyze and report results. int (*analyze)(void *priv); void (*free)(**priv); };
Then, we can create a separate ops struct for each type of test, i.e. a generated sine wave, reading from a file, ramp test, etc.
The alsa code is fantastically complex, so I'm not touching any of that. :-/ Just splitting out the generate, capture, and analysis to be modular.
Let me know if you think this is going to be a problem.
-Caleb
In order to support the molecularity, I need the ability for each module (i.e. test type) to accept its own arguments. In order to accomplish this, I think it would be better to use argp instead of getopt_long. Is it okay if I switch it over? Will that break android?
Basically, I need the general options like sample rate, channels and format to be in the first set of arguments, but then be able to call a second parser to manage the module's options, like sine frequency (for the sine based test), or impulse response length (for an impulse response test).
Perhaps there's a way to do it with getopt_long, but it doesn't look too simple because getopt_long requires all the options to be already defined before parsing starts, whereas argp can bring in new parsers (from the ops struct previously described).
Any thoughts?
-Caleb