The newcomer who wants to write his own software does not have
to know anything about the header, he can just use the 1024
bytes of data and ignore whatever has been appended. Having a
header which has to be properly decoded in order to extract
the data builds a threshold that makes it more difficult to
get started. (Processing simple .wav files has a pretty high
threshold in decoding the header. Common practice between
amateurs has been to just dicard the header and read the actual
data using the information supplied with the file. Those
who worked with the UNKN422 challenge were adviced to do
so for example.)

WAV is an example of a file format where *everyone* added their own custom headers/chunks, without any planning. As a result, no program can read all existing WAV files; WAV is considered an example how *not* to do a file format.

Would you consider a very simple, easy to parse header like this:

typedef struct {
  short header_len;  // This field is always present, and always first
  short data_len;    // This field is always present, and always second
  [ header contents, including header version, type, etc. goes here ]
  char data[];

This is still easy to parse, since all a user needs to do is something like

  struct NET_RX_STRUCT *rx_packet;
  char *my_data;
  short i, my_data_len;

  rx_packet = ReceiveData();
  my_data = ((char *) rx_packet) + rx_packet->header_len;
  for(i = 0; i < rx_packet->data_len; i++)

 > That, too, makes it harder for dedicated hardware receivers; ideally
 these would not need _any_ communication from the slave to the
 master. As I see it, encoding this information in the header of each
 package is a low-overhead way to reduce ambiguity, too.
The problem is that there are so many possibillities. I do not
want to invent a complicated scheme for describing the myriad
of things I can imagine now only to discover in a few years that
something entirely different has evolved.

I would suggest keeping it extremely simple. There is not very much information that varies between sampled systems:

- sample size
- sample rate
- number of channels (could even be fixed to 'always I/Q')

and, for radio systems,

- center frequency

This is enough for basic decoding of any stream, no ? Even the center frequency can be seen as superfluous (since it's only for display and not strictly needed for decoding).

I cannot imagine what systems would evolve over the coming five years that couldn't fit in this framework.

At 17:47 +0100 04-01-2007, Leif Asbrink wrote (in another mail):
Would you agree on milliseconds since midnight? From JDB I
learned that a double with seconds since Unix epoch
would be a bad idea since conversion may be difficult on
non-PC platforms. (It is the internal time format within
Linrad however)

I would use the same interface that gettimeofday() uses: a long with seconds since the Epoch (Jan 1 1970), and a long with microseconds.

The formats I intend to use within Linrad will use IA32 little endian
(as well as IA32 float) I have no intention to make Linrad portable
to other platforms and I am pretty sure I will not change my mind
on this point for the next 5 years or more. Probably never.

OK, that's fine, so please document this somewhere so those of us on non-IA32 can deal with it.

As an example: I'm currently soldering the prototype of an audio-to-Ethernet converter as part of a portable hard disk recorder. This design uses the CS5381 ADC, one of the best professional audio converters on the market with a dynamic range approaching 120dB. This is an open-hardware system[1], and with a few modifications I could see it being usable for Linrad. A lot of the limitations (time jitter on the system clock etc) that are present on a PC platform simply do not appear for such a dedicated device. How would you like me to interface such a system to Linrad ? Should it be able to act as a Linrad master ?

[1] Converter schematics are here:
LART. 250 MIPS under one Watt. Free hardware design files.

This message is sent to you because you are subscribed to
 the mailing list <>.
To unsubscribe, E-mail to: <[EMAIL PROTECTED]>
To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]>
To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]>
Send administrative queries to  <[EMAIL PROTECTED]>

Reply via email to