Displaying 5 results from an estimated 5 matches for "ne10_fft_cpx_float32".
Did you mean:
ne10_fft_cpx_float32_t
2015 Feb 03
2
opus Digest, Vol 72, Issue 17
...ut. 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:...
2015 Jan 29
0
[RFC PATCH v1 2/2] armv7(float): Optimize encode usecase using NE10 library
.../maintainers of opus. Please correct me if
any of information below is inaccurate from a libNE10 change request
perspective.
Phil,
Below are 2 main things we need to change from NE10 Library side. Can
you please make these changes on NE10 side?
1. Remove usage of _t in ne10_fft_cfg_float32_t and ne10_fft_cpx_float32_t
-------from comment----
ne10_fft_cfg_float32_t cfg = (ne10_fft_cfg_float32_t)st->priv;
+ VARDECL(ne10_fft_cpx_float32_t, temp);
+ VARDECL(ne10_fft_cpx_float32_t, tempin);
Just another note on API design... the _t suffix is reserved by POSIX,
and should never be used by user code. It's...
2015 Feb 04
0
opus Digest, Vol 72, Issue 17
...if nfft is power of 2 in opus_fft_float_neon.
>
> 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.
Timothy/All,
Can we please get some guidance/consensus on this so we can move forward?
>
> What's more, we have...
2015 Jan 29
2
[RFC PATCH v1 2/2] armv7(float): Optimize encode usecase using NE10 library
...gt; +
> +void opus_fft_float_neon(const kiss_fft_state *st,
> + const kiss_fft_cpx *fin,
> + kiss_fft_cpx *fout)
Again, these are mis-aligned.
> +{
> + ne10_fft_cfg_float32_t cfg = (ne10_fft_cfg_float32_t)st->priv;
> + VARDECL(ne10_fft_cpx_float32_t, temp);
> + VARDECL(ne10_fft_cpx_float32_t, tempin);
Just another note on API design... the _t suffix is reserved by POSIX,
and should never be used by user code. It's unlikely to cause issues
with these long type names, but I have certainly seen it cause issues
elsewhere (and using...
2015 Jan 30
1
[RFC PATCH v1 2/2] armv7(float): Optimize encode usecase using NE10 library
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.