[opus] opus Digest, Vol 72, Issue 17

[Phil Wang]

Hi all,

I have already added support for scaled forward non-power-of-2 floating-point FFT:
https://github.com/projectNe10/Ne10/commit/79c3d787302f8d74b9bcfe6545d487cdf1b101d9

Two flags are added to cfg structure: is_forward_scaled and is_backward_scaled.
By setting is_forward_scaled to anything but zero, ne10_fft_c2c_1d_float32_neon will
scale the output. So we can remove need for one buffer on stack mentioned below.

As for the _t API style, it may confuse existing users if we provide two API for the same functionality or if we modify the existing API. How about we keep the typedefs in Opus? For example:
typedef ne10_int32_t ne10_int32;
typedef ne10_fft_cpx_float32_t ne10_fft_cpx_float32;

It would not be too ugly if we put them together somewhere and document them well enough. It is a tiny cost to integrate a 3rd party library.

What's more, we have provided a wrapper for NE10_FREE, so that we can make sure memory allocated by Ne10 will be freed by Ne10:
https://github.com/projectNe10/Ne10/commit/24cecb105d238e5629cecff60968b31d74e54c2a


Best Regards,
Phil Wang

> Date: Fri, 30 Jan 2015 17:41:22 -0600
> From: Viswanath Puttagunta <viswanath.puttagunta at linaro.org>
> Subject: Re: [opus] [RFC PATCH v1 2/2] armv7(float): Optimize encode
>       usecase using NE10 library
> To: "Timothy B. Terriberry" <tterribe at xiph.org>
> Cc: "opus at xiph.org" <opus at xiph.org>
> Message-ID:
>       <CAE+8thixRitZx8XBpQJZSHTOHDA-F4tQ7kR-
> uANHghGdRHhUCQ at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On 30 January 2015 at 02:38, Timothy B. Terriberry <tterribe at xiph.org>
> wrote:
> >
> > Viswanath Puttagunta wrote:
> >>
> >> Is the peak stack usage a complete blocker in current form?
> >
> >
> > Since this only affects people who enable NE10, I don't think this is a blocker.
> I discussed this and comment about _t with Phil at NE10_ARM. He committed
> to two changes:
> 1. Change API to address usage of _t from NE10 api for following types:
>    ne10_int32_t              ------> will become ----> ne10_int32
>    ne10_fft_cpx_float32_t ------> will become ----> ne10_fft_cpx_float32
>    ne10_fft_state_float32_t ------> will become ---> ne10_fft_state_float32
>    ne10_fft_cfg_float32_t   -----> will become ----> ne10_fft_cfg_float32
>
> 2. Provide scaling as argument to ne10_fft_c2c_1d_float32_neon() and
> remove need for one buffer on stack (ALLOC(tempin, st->nfft,
> ne10_fft_cpx_float32_t);). We will still need cfg->buffer. So, peak stack usage
> goes up by ~3.8K instead of ~7.5K.
>
> Hope to get the RFCv2 by end of next week.

-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium.  Thank you.

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No:  2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No:  2548782