search for: koenvos74

Yes those instructions exist, although they're a bit slower than the basic 16x16->32 with 32-bit accumulation (SMLABB). So I'd be surprised if the function with 64 bit accumulation would run as fast as the current code. Don't know how much we care about 16-bit platforms. And accuracy should not matter. On the other hand, a 64-bit implementation is much cleaner/shorter, which is

...perimental version that uses 32 bits but leaves 8 bits margin before accumulating, and that shaves 2 instructions per loop, making it 10. All in all, I am not sure it is worth the hassle though considering this is only about 1/order of the cost of the autocorrelation? Marcello From: KOEN VOS <koenvos74 at gmail.com<mailto:koenvos74 at gmail.com>> Date: Friday, 20 June 2014 22:04 To: "Timothy B. Terriberry" <tterribe at xiph.org<mailto:tterribe at xiph.org>> Cc: "opus at xiph.org<mailto:opus at xiph.org>" <opus at xiph.org<mailto:opus at xiph.or...

...Title: RTP Payload Format for the Opus Speech and Audio Codec Author: J. Spittka, K. Vos, JM. Valin Status: Standards Track Stream: IETF Date: June 2015 Mailbox: jspittka at gmail.com, koenvos74 at gmail.com, jmvalin at jmvalin.ca Pages: 18 Characters: 41770 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-payload-rtp-opus-11.txt URL: https://www.rfc-editor.org/info/rfc7587 DOI: http://dx.doi....

Right, there shouldn't be a problem with undefined behavior. That said, a 64 bit implementation will work very well - in fact that's how it was done originally. The reason for the current implementation is to minimize 64-bit operations in order to improve performance on limited-width architectures. This functions gets used extensively, and I think the current implementation is faster on