Created attachment 248248 [details] [review]
patch which disables NEON for 16-bit int

I found out that the resampler's ARM NEON code paths contain a bug with 16-bit integer samples. It only occurs if all of the following criteria are met:

1) 16-bit audio sample format
2) target platform supports the ARM NEON instruction set (BeagleBone, BeagleBoard, i.MX6 etc. but NOT the RaspberryPi from what I know)
3) GStreamer was built with Orc acceleration
4) at run-time, during element initialization, the audioresample element benchmarks backend speeds and decides to use the int16 backend
5) the full sinc table is used

In the vast majority cases, (4) will not occur; it will choose the float backend instead. However, if all criteria are met, then no sound will be produced.

The following command line reproduces this:

gst-launch-1.0 audiotestsrc wave=square volume=1 ! "audio/x-raw, format=S16LE, channels=2, rate=44100" ! audioresample sinc-filter-mode=1 ! "audio/x-raw, rate=48000" ! audioconvert ! autoaudiosink

if all of the criteria are met, nothing will be heard until S16LE is replaced with S32LE.

Note that 32-bit floating point NEON support works fine.

The attached patch removes NEON support for the 16-bit integer backend. I do not understand why it doesn't work, since it has worked before. However, looking for the cause is probably not worth it, since the performance gain for 16-bit samples is small (NEON seems to pay off more for the 32-bit float samples.)

If anybody cross-compiled GStreamer 1.1.1 for a platform with ARM NEON support , please run the gst-launch line above.