On Fri, Oct 23, 2015 at 3:47 AM, Liam Girdwood
<liam.r.girdwood@xxxxxxxxxxxxxxx> 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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
