[Bug 772872] New: audioconvert: superfluous quantization when converting S24LE to S24LE causing extra CPU load

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=772872

            Bug ID: 772872
           Summary: audioconvert: superfluous quantization when converting
                    S24LE to S24LE causing extra CPU load
    Classification: Platform
           Product: GStreamer
           Version: 1.8.3
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gst-plugins-base
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: brain at jikos.cz
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

While measuring the audioconvert plugin performance I found that converting
S24LE to S24LE format (i.e. no change of the format at all) causes superfluous
quantization. This results in extra CPU load.

The reason for this peculiar behaviour is that the first and mandatory step in
an audio conversion is to unpack the data to either 16 or 32 bits. So 24-bit
data is internally expanded to 32-bits. Then in the following if statement the
chain_quantize() function logic decides that a quantization is needed:

  /* we still want to run the quantization step when reducing bits to get
   * the rounding correct */
  if (out_int && out_depth < 32
      && convert->current_format == GST_AUDIO_FORMAT_S32)


Obviously, if 24-bits are expanded to 32-bits and then again compacted to
24-bits, no quantization is needed.

Not sure how exactly the if statement should be altered, but shouldn't it also
take the in_depth into account (like: ... && in_depth != out_depth)?


My test pipeline:

gst-launch-1.0 audiotestsrc samplesperbuffer=48 !
"audio/x-raw,format=(string)S24LE,rate=(int)48000,channels=(int)2" !
audioconvert !
"audio/x-raw,format=(string)S24LE,rate=(int)48000,channels=(int)2" ! alsasink
can-activate-pull=true provide-clock=false buffer-time=8000 slave-method=none
blocksize=192

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.