[LAD] ALSA Sequencer timestamp on event without scheduling

[Felipe Ferreri Tonello]

Hi Clemens,

On 17/09/16 08:42, Clemens Ladisch wrote:
> Felipe Ferreri Tonello wrote:
>> On 16/09/16 18:41, Clemens Ladisch wrote:
>>> Felipe Ferreri Tonello wrote:
>>>> I have a question. I would like to send sequencer events without
>>>> scheduling but with a timestamp information associated with. Is that
>>>> possible?
>>>
>>> You could set the timestamp field of the event, but why bother when
>>> nobody is ever going to read it?
>>
>> Thant's what I am doing[1] but I would like to know if there is a proper
>> method of doing so.
> 
> You can either schedule an event to be delivered in the future, or send
> it to be delivered immediately.
> 
> In the latter case, setting the timestamp does not make sense.

It _does_ on MIDI-BLE. See below.

> 
>> This is *necessary* for MIDI-BLE at least, where the packet provides
>> timestamp information.
> 
> If an event received over bluetooth is not to be delivered immediately,
> you have to schedule it.

The timestamp on MIDI-BLE is part of the BLE packet and represents the
time on the peripheral device (the one sending the MIDI message). Which
means I can't schedule the event because they are in the past when
compared to the central device[1].

It is also acceptable that one BLE packet has multiple MIDI messages
with different timestamps (always increasing). This happens in an
attempt to lower the latency.

To sum up, this is why I can't schedule these events:
 * We want to deliver these events *ASAP* to the application -
scheduling adds latency, a lot;
 * Timestamps are in the past relative to the central.

But I still need the timestamp information. Why? The spec doesn't
explain, but it makes sense to believe it is used to have a predictable
latency, so if the central device wants to layout these MIDI message,
they little or no jitter in between.

Thus, to be MIDI compliant, we need to set this timestamp some how on
the event. And I think the simplest way, is to use snd_seq_real_time_t
on ev.time.time.

Any thoughts?

[1] Central device represents the one establishing the connection to a
Bluetooth GAP peripheral, similar to a host on USB.

-- 
Felipe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x92698E6A.asc
Type: application/pgp-keys
Size: 7177 bytes
Desc: not available
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-dev/attachments/20160919/fc9b1a0f/attachment.key>