Open salvaaod opened 3 months ago
packet spreading might help (this was called interleaving until some odr-dabmux version)
Search packet_spread
in doc/advanced.mux
Yes I tried, actually the test I an doing is all in the same network so it is actually not a real udp loss but something weird with FEC, I tried several settings of spread from 0 to the default 95% and I get the same results, around 4% packet corrected. As mentioned, depending of the mux content with same output configuration. I have an example in particular, a mux with 23 services with FEC enabled, it has 0 fec recovered packets,, same configuration with just removing one service I have 4% packets recovered, even changing the bitrate of one service it goes from 0 packets recovered to 4%, makes no sense whatsoever but I can reproduce it anytime..
Will it help if I copy the EDI output of both situations, FEC errors and no FEC erros ?
Following my previous comment, the following sample minimal configuration sends FEC frames with no error, at 16 or 224Kbps the number of corrected FEC packets is 0, any other bitrate will give 4% of recovered FEC packets.
general { dabmode 1 nbframes 0 } remotecontrol { telnetport 0 } ensemble { id 0xFFFF ecc 0xFF local-time-offset auto international-table 1 label "TEST" shortlabel "TEST" } services { srv-p1 { label "TEST" shortlabel "TEST" id 0xFFFF pty 0 pty-sd static language 0x00 } } subchannels { sub-p1 { type dabplus bitrate 224 id 1 protection 3 inputproto edi inputuri "tcp://*:1234" buffer-management prebuffering buffer 40 prebuffering 20 } } components { comp-p1 { service srv-p1 subchannel sub-p1 } } outputs { throttle "simul://" edi { destinations { example_udp { protocol udp sourceport xxxxx destination "x.x.x.x" port xxxxx } } enable_pft true fec 2 } }
Can you try setting tagpacket alignment to 16?
If that still doesn't work, please ask Gatesair. We're using ODR-DabMux in production with GatesAir transmitters, but maybe it depends on the model and/or firmware version.
Thanks, from a situation where is no FEC recovered changing the tagpacket alignment to 16 from the default 8 will create the issue, so, this seems not to help. It is strange because Gates told me the same thing, they have their transmitters with many other multiplexers with no FEC issues, anyhow, I will come back to them.
Just in case I have added two eti files to check, one with OK fec and the other with 4% fec error, the only thing changed between those to files is the audio bitrate.
I Just realized that the ETI (NI) files makes no much sense since they do not have the underline EDI FEC as defined in TS102821, will try to dump a EDI file.
Try to dissect the EDI stream with wireshark too. Maybe it can show protocol errors too.
Tried to use FEC with Gates transmitter and it is self generating 10% of errors with direct EDI ethernet connection, disabling FEC all works ok. On certain mux configurations regarding services, FEC works, not sure what combination of services makes fec work with Gates.
The dataflow is DABMUX-----> EDI2EDI ------> Gates
Not sure where the issue is coming from but seems that Gates is working with many other multiplexers with no issues.
output in dabmux is simple tcp: outputs { throttle "simul://" edi { destinations { tcp { protocol tcp listenport [port] } } } edi2edi is adding fec odr-edi2edi -c [IP:PORT] -w -400 -x -d [IP] -p [PORT] -f 2
Any suggestion on further tests to understand where the issue is coming from ?