[Bug 787683] alsamidisrc behavior with non-live sinks

[GStreamer (GNOME Bugzilla)]

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

--- Comment #3 from Antonio Ospite <ao2 at ao2.it> ---
Hi Nicolas,

> Be aware, I'm not that familiar with that element and MIDI in general. It is
> first time I ear someone is using alsamidisrc.
>

I appreciate even more that you took the time to comment then.

> I think the element have several issues.
> 
> 1. Tick duration is not always 10ms (there is an ALSA API to read it)

The ticks used by alsamidisrc are not the ticks-per-beat which depend on the
"tempo" but rather some real-time tick[1] that MIDI never specified
officially, the 0xf9 message used here is also used by midiparse to let the
pipeline progress (in fact that's where I got the idea from) and it is parsed
by fluiddec, so I think we can safely assume one "real-time-tick" each 10ms in
a GStreamer context.

[1]
https://web.archive.org/web/20160223003358fw_/http://www.blitter.com/~russtopia/MIDI/~jglatt/tech/midispec/tick.htm

> 2. Tick time is indicated per event, right now we assume all events are on
>    consecutive ticks. That's wrong and worst you could have two events with
>    the same tick.
>

I agree that there must be more granularity in event timestamps.

Some comments in the code also mentions that the current situation was meant
as a proof-of-concept.

> The problem with implementing get_times() is that you may endup loosing
> events. Though, if you wait up to 1 tick duration, you should not be having
> issues.
>
> I think the proper solution is to poll, but instead of a duration use
> a proper timeout (calculate max delay from the clock). This way, instead of
> waiting 10ms, you look at the clock for when the next tick should happens,
> and wait at most this time. After which, you produce a MIDI tick. As a side
> effect, if the mini input is silence, you'll get a perfect stream of midi
> tick, without any jitter.
>

I noticed that midiparse does not set a duration for buffers either, and
I guess this make sense for MIDI events which do not have a concept of
duration.

I took a better look at the sequencer API and it looks like I can use it to
schedule future events, so this could be a better way to produce the periodic
ticks: let the ALSA sequencer produce them and have alsamidisrc just poll with
no timeout and forward the buffers downstream regardless of their type (tick,
note, etc.).

I still have some doubts tho:

  - I am not sure how and where to correlate the timestamps from the ALSA
    sequencer queue with the GStreamer element running time.

  - Should I handle the PAUSED state? Is it a valid state for live elements?

Ciao ciao,
   Antonio

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