[Bug 787683] New: alsamidisrc behavior with non-live sinks

[GStreamer (GNOME Bugzilla)]

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

            Bug ID: 787683
           Summary: alsamidisrc behavior with non-live sinks
    Classification: Platform
           Product: GStreamer
           Version: 1.12.2
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gst-plugins-base
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: ao2 at ao2.it
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

Created attachment 359802
  --> https://bugzilla.gnome.org/attachment.cgi?id=359802&action=edit
Program to play midi notes at fixed intervals

Hi,

a user reported to me that alsamidisrc produces unexpected results when
recording to a file.

Bug description
---------------

The following pipeline gives the expected result of live real-time
samples:

  $ gst-launch-1.0 alsamidisrc ports=128:0 ! fluiddec ! autoaudiosink

The following one does not:

  $ gst-launch-1.0 alsamidisrc ports=128:0 ! fluiddec ! wavenc !  filesink
location=alsamidisrc_out.wav

The user found that the music recorded in the file was "slower" compared to
what was played on the MIDI keyboard, like if the pauses between the notes
were longer than they should have been.

This turned out to be because, even though the alsamidisrc element is
supposed to be a live source[1], when using a non-real-time sink more
midi ticks (silence buffers) than expected are created.

Using "filesink sync=true" (or using "identity sync=true" right after
alsamidisrc) would work around the issue, producing wave files with the
expected timing.

A more reproducible test can be performed generating midi notes at fixed
intervals (see the attached midi_virtual_ticks.py) and comparing the
files produced with and without sync=true (after aligning the first
note) see the attached alsamidisrc_test.sh script.


Bug analysis
------------

alsamidisrc is based on GstPushSrc[2], and AFAICS at a lower level the
observed behavior depends on how often the create() method of the src
element gets called. In case of sync=true the pipeline seems to wait
that the duration of the buffers actually passes before requesting
(accepting?) a new buffer, conversely when sync=false buffers are
created as soon as possible.

>From the logic in gst_base_src_do_sync[3], and from some other docs
[4,5] it seems that live sources are expected to behave like the
sync=true behavior from above (wait for the buffer duration to pass),
some comments suggest that live sources must implement the get_times()
callback to enable this "sync" behavior.

Can anyone confirm if this is actually the issue?
Do I have to implement get_times() in alsamidisrc?

A quick experiment seems to confirm that implementing get_times() makes
alsamidisrc behavior less surprising but I'd like to have confirmation
before proposing a patch.

Thanks,
   Antonio

[1]
https://cgit.freedesktop.org/gstreamer/gst-plugins-base/tree/ext/alsa/gstalsamidisrc.c#n264
[2]
https://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer-libs/html/GstPushSrc.html
[3]
https://cgit.freedesktop.org/gstreamer/gstreamer/tree/libs/gst/base/gstbasesrc.c#n2178
[4] https://gstreamer.freedesktop.org/documentation/design/live-source.html
[5]
https://cgit.freedesktop.org/gstreamer/gstreamer/tree/libs/gst/base/gstbasesrc.c#n87

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