Print repeating errors only once

[andimik]

test.eti.zip

If you play the attached file (taken with eti-cmdline-airspy from Slovenija sent with ZeroMQ to another device and recorded there) you will get audio, but lots of

EnsembleSource: skipping 22 bytes for sync

Hint: I've used eti2zmq and tried several options

$ eti2zmq 
usage: eti2zmq [--delay] [-i <inputfile>] -o zmq+tcp://0.0.0.0:18082

Additional info related to arguments:
--input or -i <filename>        Provide input file for app
--output or -o <zeromq address>    Provide zeromq output address like zmq+tcp://[local_ip]:[port_to_listen]
--delay or -d                      Force pseudo-realtume streaming (add 24ms delay for each eti frame)
--loop or -l                       Run input file in-a-loop
--no-align or -L                   Disable frame alignment for ZeroMQ packing
--no-cut-tail or -C                Disable removing unneeded fill bytes at ETI frames tails
--activity or -a                   Display app's activity in console
--verbose or -v                    Increase app's verbosity (can be provided multiple times)

$ eti-cmdline-airspy -C 10D -G 90 | eti2zmq -a -o "zmq+tcp://*:9100"

Although this has informative character, I would suggest to minimize these repeating warnings and display only once.

BTW: it cannot be loaded into XPADxpert v1.12 ...

A file recorded on the same machine (= not sent via ZeroMQ) works and does not show these repeating warnings.

[basicmaster]

As a file recorded on the same machine works without these messages (assuming the same ensemble as source), this should already tell you that the location of the issue must be outside of DABlin ;-) So muting warning would only remove the symptoms but wouldn't fix the underlying actual issue; such an ensemble recording would still be faulty.

It seems that using ZMQ for transport, somehow an additional header is inserted into the data stream in regular intervals. As a consequence XPADxpert won't open the file, as it expects frame-aligned ETI (as you know, DABlin has been extended sometime to auto-sync sometime in the past).

Which tool/cmdline do you use to feed the received ZMQ stream into DABlin?

[andimik]

Thanks for you very fast answer :-)

Well, I found out that this is working principally

On the server

$ [LOAD ETI or GENERATE IT] | eti2zmq -a -o "zmq+tcp://*:[IP-ADDRESS]"

on the client

wget http://[IP-ADDRESS]:[PORT] -q -O - | dablin_gtk

or - very easy -

curl [IP-ADDRESS]:[PORT] | dablin_gtk

---

I've tested it as this laptop as server and my RPI3 as client in the same network.

in https://github.com/piratfm/eti-tools/blob/master/eti2zmq.c I see

#define ETI_NI_FSYNC0               0xb63a07ff
#define ETI_NI_FSYNC1               0x49c5f8ff
#define ETI_NI_RAW_SIZE             6144
#define ETI_NI_FRAME_TIME           24000 //useconds

So, the 6144 size length is correct, and the 24 ms should be correct, too.

[basicmaster]

This way just works by chance, as the used format is not supposed to be compliant to ETI (besides that I'm not sure whether HTTP - which wget/curl support - is compatible with zmq, which may add further data "polluting" the output). The transmitted ETI frames themselves are contained in a specific structure that consists of further parameters (version, frame sizes). So the result is definitely not compliant to ETI - thus the showed sync messages are all legitimate. Therefore I close here.

If you need to transmit a complete ensemble, you may want to simply use netcat on both computers.