On Mon, Oct 26, 2015 at 2:11 AM, Liam Girdwood liam.r.girdwood@linux.intel.com wrote:
On Fri, 2015-10-23 at 10:54 -0700, Caleb Crome wrote:
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?
Yes, that should be fine as long as we keep consistency with the switch names.
There will be one extra switch to specify which test needs to be performed.
This will probably be useful for the stand alone module (for IoT) that Han is doing too. This module will not do any analysis (test execution only) and wont have dependencies on fftw3 so will be very small and easily installable on IoT/Android style devices.
Is the only reason for a separate program for IoT that fftw is needed? At least 2 of my tests will be very light on DSP: the ramp test and the phasor-based adaptive sine-wave test. These will be pretty good system tests, without having to resort to FFTs, so they will run just fine on just about any cpu that can keep up with audio sampling and linux/android.
-Caleb