Re: BAT: restructuring code

Re: BAT: restructuring code

[Caleb Crome]

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

Re: BAT: restructuring code

[Liam Girdwood]

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.

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. 

> 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?

No, I think you are probably on the right track here if you need to pass
cmd line args to other modules.

Liam

> 
> -Caleb

Re: BAT: restructuring code

[Caleb Crome]

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