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@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev