[alsa-devel] BAT: restructuring code

[Caleb Crome]

On Mon, Oct 26, 2015 at 2:11 AM, Liam Girdwood
<liam.r.girdwood at 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 at 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