<div dir="ltr"><div class="gmail_extra"><br>
<br><div class="gmail_quote">On 1 February 2015 at 16:26, Timothy B. Terriberry <span dir="ltr"><<a href="mailto:tterribe@xiph.org" target="_blank">tterribe@xiph.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Viswanath Puttagunta wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Could you please elaborate on "It would be nice to have"? Specifically:<br>
- Are there use cases where fixed point is preferred when AAarch64 has<br>
mandatory support for floating point both in regular CPU as well as<br>
NEON?<br>
</blockquote>
<br></span>
Even on x86, when the complexity setting is below the maximum, then for medium-low bitrate speech the fixed-point encoder will generally be faster, because much of the SILK processing uses exact integer math, and this avoids several float->int->float round trips. That's why the x86 intrinsics code Cisco contributed focused on fixed-point, for example.<br>
<br>
I have not tested on aarch64, but I expect similar properties to hold.<br>
<br>
It also depends on the rest of your pipeline. If your whole audio pipeline is fixed-point (which is common in real-time stacks), then you'd have to pay additional conversion penalties to use the floating-point API.<br></blockquote><div> Thanks.. I will add adding neon capabilities to fixed point to by todo list. </div></div><br></div></div>