Hi, On 2014-10-08 16:26:44 -0400, Jonathan Bagg wrote: > > I just did a comparison of audio codec decode times with libav-11 on > a iMX-53 (arm cortex-A8) with and without neon & vfp optimizations. > There was substantial improvements in aac, ogg and wma with neon & > vfp enabled, but mp3 remained the same. Am I correct to assume the > mp3 decoder does not utilize the neon optimizations? (or is > something screwed up)
you're correct, there are no neon optimizations for the mp3 decoders on arm. I did NEON optimizations for arm64 NEON in 8f9fe6ae3461ce270bce6b7083fda5ec314cdad4 but didn't port them yet to arm. But even with those optimisations it'll probably still be slower than madplay. Which mp3 decoder did you test? Libavcodec has both fixed and floating point. > alac and flac also had little improvement but > I understand that they are very different in that they don't convert > to the frequency domain. alac doesn't seem to have any optimisations but there could be some potential (just looked at the source for a minute). > Tables > > Decode Time (s) > > codec libav libav no neon incumbent % change > compared against > aac 9.7 59.5 40.6 −76.1% faad > alac 8.1 8.1 6.5 24.6% faad > flac 10.9 11.6 11.2 −2.7% flac > ogg 9.9 47.7 35.5 −72.1% ogg123 > mp3 19.2 19.2 8.5 125.9% madplay > wmav2 5.7 38.7 4.8 18.8% gst-wma-codec gst-wma-codec looks fast. Do you know there it is from? Or is it fully in gst? missing from the comaprison is opus (which also misses arm neon backports from arm64). Janne _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
