On Sun, 2007-12-02 at 12:58 +0000, Krzysztof Foltman wrote:
> I think the version you (probably) proposed is:
>
> struct LV2_EVENT_HDR
> {
> uint32_t frame, subframe;
> unsigned int size:24;
> unsigned int type:8;
> // put data here, but header size+data size must be a multiple of 8
> };
>
> plus 8-byte alignment requirement (ie. header size+payload size must be
> an integer multiple of 8), is going to work.
More or less agreed. The size thing isn't really an issue in practise,
just reaching for equivalence with OSC/Jack for equivalence's sake.
Dealing with a 24 bit number is pretty weird though. Worth it?
> Either that, or 16 bits for both size and type. Or 16 bits for size and
> 8 bits for type, and the remaining byte may be used for char field in
> payload (5 byte payload "for free"). All three are more or less equally
> good/bad.
The 'free' payload is tempting since the majority of events (at least
for now) are going to be 4 bytes of MIDI. OTOH, we probably want the
data itself aligned (consider e.g. ramp events)
We have 32-bit alignment for the data. Is 64-bit alignment worth
shooting for?
> MIDI would look like this: 12 bytes header, (up to) 3 bytes content, 1
> byte padding - which is fine.
>
> Same for pointer-only data on 32-bit architecture, for 64-bit, there
> would be a padding of 4 bytes followed by 8-byte pointer. Not very
> elegant, but perfectly acceptable. Plus, the compiler takes care of
> generating padding.
These structs don't actually 'exist', for the nth time ;) so the
compiler doesn't take care of any padding/alignment etc. We're defining
the internal layout of a byte array here, not an actual C struct.
Alignment stuff is simple enough anyway, maybe with a macro or two.
-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 20:15:02 2007
This archive was generated by hypermail 2.1.8 : Sun Dec 02 2007 - 20:15:02 EET