> 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++)
DoSomethingWithMyData(my_data[i]);
Yes, but but these modern ways of writing scares off all my
friends who can use old-fashioned C but not C++.
First of all ReceiveData() has to be written, separate
buffers of size NET_RX_STRUCT have to be allocated and
managed etc. I do not currently have such code and I suspect
it involves needless copy operations. I am looking
for bandwidths of 2 MHz and above (for VHF noise blanking
to remove static rain) so needless copy - probably
up and down to main memory is something I want to avoid.
I've never written a single line of C++ in my life. As for the
ReceiveData() function, that line can be directly replaced with your
recvfrom() call (I just was too lazy too look up recvfrom() when I
wrote that example). I don't see that having a header in front of the
package needs more copy calls than one after the package; even if it
did, it matters very little on modern CPUs (packets this size will
remain entirely within the CPU cache). Zero-copy architectures make
sense for hi-speed packet switching on slow computers; as soon as you
add any processing on the data, that single extra copy gets lost in
the noise. Cache line/block alignment is much more important for
performance.
> 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).
The primary usage of the Linrad network was for the second operator
in a contest station. It is an obvious advantage that the display
is always correct - particularly if several bands are monitored
simultaneously.
I cannot imagine what systems would evolve over the coming five years
that couldn't fit in this framework.
Linrad can also send data in the frequency domain and there is
quite a lot of info that a slave will need. Admittedly those
formats are likely to be used by Linrad only but they carry
many more complications.
OK, I see.
I was assuming that the multicast connection would be used for
distributing raw data only. Re-reading your earlier posts it looks
like you want to be able to send both raw *and* cooked (processed)
data. Why ? Do you expect the slaves to be much slower than the
master ? Do you want to have an exact, synchronized display on
multiple machines ?
Looking at other network protocols (especially streaming), it has
historically been a bad idea to combine multiple modes into one
protocol, for reasons of maintainability, performance and clarity.
Linrad is your code, and it's completely up to you, but might I
suggest you consider either splitting the transmission modes in raw
and cooked, or (better) multicasting only raw, unprocessed data and
sending all filter parameters over a separate channel ?
> [about an ADC-to-Ethernet]
Probably it would be better to connect it to a socket on a
dedicated ethernet port on one computer, the one which has
the controls for the radio hardware connected to this soundcard.
The master wants 100% reliable data because I assume you do not
want to put the master system clock on the audio-to-Ethernet
converter.
Why not ? It has a GPS-controlled OCXO to synchronize all sampling
clocks and to keep time, isn't that sufficient ?
Are you aware of any standard format for streaming unprocessed
audio data?
At my previous job we had a few, but they were paper-only. There is
MADI (digital audio) and SMPTE-259M (digital video) over ATM, but
that doesn't quite apply here. I believe the AES have some, but those
are for-pay documents, and I'm not an AES member anymore.
What data format were you contemplating before this discussion
started?
Pretty much what I described above: header with header length, data
length, number of channels, sample size, sample rate, timestamp and a
few descriptive fields (with a version field, so that -- if truly
necessary -- upgrades are possible). Nothing that isn't strictly
required: less is more.
It's what everybody else does. I know that that's not much of an
argument ('50 million Elvis fans can't be wrong'), but in 15 years of
working on network protocols, this is pretty much the only way that
I've seen working reliably for successful sampled AV or radio
projects (I've seen a similar system used on an antenna array for
MIMO trials). Conversely, I have never ever seen a combined
raw/cooked protocol that worked, or better: that remained working. Or
it evolved into something like WAV: a historical accident that
everyone loves to hate.
JDB.
--
In protocol design, perfection has been reached not when there is
nothing left to add, but when there is nothing left to take away.
-- RFC 1925, "Fundamental Truths of Networking"
#############################################################
This message is sent to you because you are subscribed to
the mailing list <linrad@antennspecialisten.se>.
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]>
