<div dir="ltr">If wikipedia is correct (have not verified this in any manner), then setting the mode to RESTRICTED_LOWDELAY will disable SILK: <a href="https://en.wikipedia.org/wiki/Opus_(audio_format)#Quality_comparison_and_low_latency_performance">https://en.wikipedia.org/wiki/Opus_(audio_format)#Quality_comparison_and_low_latency_performance</a><div><br></div><div><a href="http://www.opus-codec.org/docs/html_api-1.1.0/group__opus__encoder.html#gaa89264fd93c9da70362a0c9b96b9ca88">http://www.opus-codec.org/docs/html_api-1.1.0/group__opus__encoder.html#gaa89264fd93c9da70362a0c9b96b9ca88</a><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jul 6, 2015 at 4:25 PM, Andrew Lentvorski <span dir="ltr"><<a href="mailto:bsder@allcaps.org" target="_blank">bsder@allcaps.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I saw the custom API, but nothing explicitly says "CELT-only" just<br>
"custom sample rate and frame size".<br>
<br>
I'll dig further now that you've pointed me in a direction.<br>
<br>
Thanks,<br>
-a<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
On 7/6/15, 6:18 PM, Jean-Marc Valin wrote:<br>
> -----BEGIN PGP SIGNED MESSAGE-----<br>
> Hash: SHA256<br>
><br>
> I believe what you want is called Opus custom (OPUS_CUSTOM in the<br>
> code). With that you can compile only the contents of the celt/<br>
> directory and use it like the old CELT.<br>
><br>
> Jean-Marc<br>
><br>
> On 07/06/2015 06:48 PM, Andrew Lentvorski wrote:<br>
>> Is there a configuration or compile flag that lets me disable the<br>
>> SILK portion of the codec and use CELT only?<br>
>><br>
>> I could have sworn that there is something, but I can't seem to<br>
>> find it in the mailing list archives.<br>
>><br>
>> The application here is that I am attempting to update from the old<br>
>> CELT codec to OPUS. Unfortunately, the CELT codec was running<br>
>> *very* close to the CPU (MIPS32--80MHz) limit (over, actually,<br>
>> occasionally a packet didn't have time to get encoded and the<br>
>> application treated it as a lost packet). SILK probably isn't in<br>
>> the cards.<br>
>><br>
>> Now, I do know that *some* improvements have been made in<br>
>> performance, but I really can't count on that being good enough<br>
>> since I really had to tune things in the first place. If I can<br>
>> come back later and switch the SILK portion on I'll give it a try<br>
>> then.<br>
>><br>
>> Thanks, -a<br>
>><br>
>><br>
>><br>
>><br>
>> _______________________________________________ opus mailing list<br>
>> <a href="mailto:opus@xiph.org">opus@xiph.org</a> <a href="http://lists.xiph.org/mailman/listinfo/opus" rel="noreferrer" target="_blank">http://lists.xiph.org/mailman/listinfo/opus</a><br>
>><br>
<br>
</div></div><br>_______________________________________________<br>
opus mailing list<br>
<a href="mailto:opus@xiph.org">opus@xiph.org</a><br>
<a href="http://lists.xiph.org/mailman/listinfo/opus" rel="noreferrer" target="_blank">http://lists.xiph.org/mailman/listinfo/opus</a><br>
<br></blockquote></div><br></div>