Re: [LAD] ALSA Sequencer timestamp on event without scheduling

[Felipe Ferreri Tonello]

Hi Clemens,

On 30/09/16 19:46, Clemens Ladisch wrote:
> Felipe Ferreri Tonello wrote:
>> This event we are discussing is time based.
>> The only difference is that the event time is not its delivered time,
>> but some time in the past.
>>
>> I just want to make ALSA Sequencer support this idea, which is new and a
>> requirement for MIDI over BLE to work properly.
> 
> I see no such requirement in the BLE-MIDI specification, which says:
> | To maintain precise inter-event timing, this protocol uses 13-bit
> | millisecond-resolution timestamps to express the render time and event
> | spacing of MIDI messages.
> and:
> | Correlation between the receiver’s clock and the received timestamps
> | must be performed to ensure accurate rendering of MIDI messages, and
> | is not addressed in this document.
> 
> In the context of the ALSA sequencer, "rendering" means delivery.

Yes, the correlation exists on the current implementation I am working
on[1].

The problem is the latency on receiving BLE packets. The timestamp the
device sends and the "receiver's clock" (ALSA Seq) will very quickly get
out-of-sync, causing this timestamp to be invalid. Thus we need somehow
to set the event timestamp to any arbitrary value, in practice it will
be the BLE-MIDI timestamps (normalized to the central timestamp, of course).

[1] https://github.com/ftonello/bluez/blob/midi/profiles/midi/midi.c#L138

-- 
Felipe


0x92698E6A.asc
Description: application/pgp-keys
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] ALSA Sequencer timestamp on event without scheduling

[Clemens Ladisch]

Felipe Ferreri Tonello wrote:
> This event we are discussing is time based.
> The only difference is that the event time is not its delivered time,
> but some time in the past.
>
> I just want to make ALSA Sequencer support this idea, which is new and a
> requirement for MIDI over BLE to work properly.

I see no such requirement in the BLE-MIDI specification, which says:
| To maintain precise inter-event timing, this protocol uses 13-bit
| millisecond-resolution timestamps to express the render time and event
| spacing of MIDI messages.
and:
| Correlation between the receiver’s clock and the received timestamps
| must be performed to ensure accurate rendering of MIDI messages, and
| is not addressed in this document.

In the context of the ALSA sequencer, "rendering" means delivery.


Regards,
Clemens
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] ALSA Sequencer timestamp on event without scheduling

[Felipe Ferreri Tonello]

Hi Paul,

On 30/09/16 14:48, Paul Davis wrote:
> 
> 
> On Fri, Sep 30, 2016 at 4:35 AM, Felipe Ferreri Tonello
> > wrote:
> 
> 
> >
> > The time of an event is the time at which it is actually delivered.
> > If you want to be compatible with most other applications, you have
> > to deliver the events at the desired time.
> 
> Ok. This is *not* an option. We need to overcome this somehow.
> 
> 
> Don't use the ALSA sequencer. The whole term "sequencer" is a reference
> to organization/scheduling based on time. If you're not going to comply
> with that basic concept of what the sequencer is/was about, use raw MIDI
> ports instead.

But this is the whole point. This event we are discussing is time based.
The only difference is that the event time is not its delivered time,
but some time in the past.

I just want to make ALSA Sequencer support this idea, which is new and a
requirement for MIDI over BLE to work properly.

-- 
Felipe


0x92698E6A.asc
Description: application/pgp-keys
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] aBLETON lINK

[David Robillard]

On Fri, 2016-09-23 at 13:00 +0200, Patrick Shirkey wrote:
> I suppose that their marketing department has decided that Linux
> Developers/Users don't represent a big enough share of the market to
> justify committing more resources to the platform.
> 
> However JACK also runs on the other two main platforms so what is their
> rational behind completely ignoring it altogether while committing
> resources to creating a competing API?

Let me start by saying I love the idea of Jack.  IMO it is,
unquestionably, The right way to do an audio API/system, and it's
fantastic.

... however, using Jack on other platforms is a gigantic PITA.  Hell, it
is on Lignux, too, but we're just used to it.  It lacks the polish of
something that can act as The system audio API, largely because all of
that stuff (shiny device selection support, flexible handling of
changing rates, and so on) wasn't in its design priorities in the first
place, but that doesn't change the reality of things.

That's unfortunate, but one needs to have been living deep in the LAD
bubble to pretend otherwise.  We haven't even managed to make Jack the
go-to out of the box audio API on Linux distributions, to say nothing of
OSX or Windows.  Which, in terms of market relevance, does mean that
companies like Ableton have little incentive to care.  For most users,
it's just this extra thing they have to deal with that doesn't provide
much if anything for their use case.

I don't think it's particularly helpful to complain that commercial
companies don't build on our technologies, regardless of what you think
of them.  It's more useful to ask: why?

Much of it (a bit ironically) boils down to the very fact that we aren't
driven by certain forces that commercial developers are.  We can, and
do, just ignore polish, or ease of use, or features that we don't
particularly feel like bothering with, and so on.  That's the nature of
unfunded free software development, really.

That said, occasionally, there are nefarious motivations behind lack of
adoption / platform support, and so on... but not always.

Jack is not my child, though, so it's a bit more honest and revealing to
use LV2 as an example.  It's a free and open audio plugin spec, it's
powerful, it does mostly everything, and considerably more, than the
proprietary specs, and it does some things dramatically better.  Why,
then, has it not taken over as the go-to audio plugin spec for everyone?
Is it because the commercial developers are evil?  Well, maybe, a little
bit, for a few of them with a vested interest in the proprietary APIs
themselves, but really it's because LV2 is "weird", distributed in a
Linuxey modular way where you need a bunch of separate libraries to
implement it, there's no standard shiny/easy C++ bindings, nobody really
regularly does the effort to make it super integrated and easy to use on
other platforms, and other external issues like the good ol' portable
plugin UI problem make things difficult.  There's a few technical points
in there, but it really just boils down to polish, packaging,
documentation, and so on.  There's a long list of things that need to
happen there, I'm keenly aware of what most/all of them are, and I don't
blame commercial developers for not caring at the moment.

It's not their fault for not adopting it.  It's ours, it's mine, for not
presenting things on as polished a silver platter as possible, and I
accept that.  So it is with Jack.

(Interesting intersectional sidenote: I've realized lately that in order
to better establish LV2 on Windows/OSX, I need to write a native host,
which is to say, a non-JACK one.  A JACK one is weird and requires
setting up a bunch of other stuff at which point you've already lost)

It's getting better, and we're making progress, but whining that nobody
likes / cares about / uses our technology isn't going to help.  They
have reasons.  Our technology is fantastic in many ways, better than
what the proprietary people work with in several, but it's also terrible
in other ways, and those ways are considered equally, if not even more,
important by most commercial developers.  Hobbyists working on the fun
parts in their spare time don't share those priorities, but they're
priorities nonetheless.

-- 
dr


___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] ALSA Sequencer timestamp on event without scheduling

[Paul Davis]

On Fri, Sep 30, 2016 at 4:35 AM, Felipe Ferreri Tonello <
e...@felipetonello.com> wrote:

>
> >
> > The time of an event is the time at which it is actually delivered.
> > If you want to be compatible with most other applications, you have
> > to deliver the events at the desired time.
>
> Ok. This is *not* an option. We need to overcome this somehow.
>

Don't use the ALSA sequencer. The whole term "sequencer" is a reference to
organization/scheduling based on time. If you're not going to comply with
that basic concept of what the sequencer is/was about, use raw MIDI ports
instead.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] ALSA Sequencer timestamp on event without scheduling

[Felipe Ferreri Tonello]

Hi Clemens,

On 20/09/16 18:11, Clemens Ladisch wrote:
> Felipe Ferreri Tonello wrote:
>> On 20/09/16 15:26, Clemens Ladisch wrote:
>>> In other words: any application that does care about timestamps will
>>> never see your timestamps.
>>
>> Yes. And that's why my first question.
>>
>> How can we implement this timestamp feature in ALSA with the current
>> implementation?
> 
> Not at all.
> 
>> If it is not possible, how feasible is for us to add this feature?
> 
> The ALSA sequencer API is an interface between multiple drivers and
> applications.  Adding a feature to the interface will not have any
> measurable effect because no other application will use it.

No other application will use it because it has not been implemented
yet. It doesn't mean that applications who cares about MIDI over BLE
will not use it. It is a very small patch anyway.

> 
> The time of an event is the time at which it is actually delivered.
> If you want to be compatible with most other applications, you have
> to deliver the events at the desired time.

Ok. This is *not* an option. We need to overcome this somehow.

-- 
Felipe


0x92698E6A.asc
Description: application/pgp-keys
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev