Re: [LAD] "enhanced event port" LV2 extension proposal

On Sat, 2007-12-01 at 22:19 +0100, David Olofson wrote:
> On Saturday 01 December 2007, Dave Robillard wrote:
> [...non audio time timestamps...]
> > All I ask for is a few measley bits :) That I can point to widely
> > accepted standards (one of which is very, very close in domain to
> > this event stuff) that use timestamps of this sort is telling..
>
> Sure, I have no problem with that. I just don't want to make sure
> we're not confusing this with types of event communication that just
> doesn't fit in the model of this particular event system. I mean,
> it's kind of pointless to pollute *this* event system with features
> that you need a completely separate LV2 extension to actually
> use. :-) (Well, unless that other LV2 extension can use this one as a
> transport layer in some sensible way, maybe.)

Understandable. I'm thinking the events themselves can be the same
(they're so open-ended, why not..) but the transport mechanism would
just be different. Some kind of one-event-at-a-time thing instead of a
big flat buffer.

There's also the sharing of transport layer and 'crossing' contexts,
yes. The way I see it in both cases the generic event is just a time
stamp, size, and some data, so might as well make this one good enough.
Precise timing resolution never hurt anyone anyway.

> > Anyway, making the frames part 16 bits screws up parity with Jack
> > MIDI. We already have a uint32_t frame timestamp. We want
> > fractional, so stick a fractional part in there, voila. The host
> > just sets the fractional part to 0 from Jack, things can use the
> > fractional bit (or not) as they please.
> >
> > Simple.
>
> Yes, that makes sense to me. It seems like the general case (even when
> making use of sub-sample timing) favors separate integer and
> fractional parts, and then, why not just use an int for each?

Yep. Something ala:

struct LV2Event {
        uint32_t frames;
        uint32_t subframes;
        foo_t type;
        uint32_t size;
        // data follows here
};

Best choice for order and foo_t for alignment? Making it smaller than
32 makes size's (and data) alignment suck, but 2^32 types of events at
one time is pretty nuts.

Cheers,

-DR-

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Sun Dec 2 00:15:10 2007