Page 1 of 1

Improper handling of sACN start-codes

Posted: Fri Sep 24, 2021 11:37 am
by jfelber
Hi all,
I encountered a bug in the E1.31 (sACN) input plugin not checking the start-code of an E1.31 packet.
According to E1.31-2018 alternate START codes (non null) should be treated the same way as stated in E1.11 (DMX) (section 8.5.3.3 and 8.5.4):
All receiving devices other than in-line processing devices shall process the START Code and differentiate between those packets with NULL START Codes and those with Alternate START Codes. Devices shall not ignore START Codes by assuming that all packets received are NULL START Code packets.
When using a sACN source which also sends sACN packets with alternate start code, e. g. an ETC eos console which uses 0xDD for per-address-priorities (sent every 0.8 to 1 seconds), QLC+ treats this packets like DMX data.

The resulting behaviour are flickering channels in the frequency of the 0xDD packets, because the priorities (default 100 on eos) are treated as DMX values, thus jumping between DMX data and 100 every 0.8 to 1 seconds.

There exists a free software called sACNView (https://sacnview.org/) which can also send per-channel-priorities with 0xDD start code (just set the priority mode in the send window to per-address).

A list with registered alternate start codes can be found at ESTA https://tsp.esta.org/tsp/working_groups ... eCodes.php.

Further information on this could also be found here: https://support.etcconnect.com/ETC/FAQ/ ... r_ETCnomad

The problem also exists on QLC+ 4.12.2.

The simplest fix would be to check the start code of incoming sACN packets and ignore all, which are not zero.

Thanks

Best regards
Johannes Felber

Re: Improper handling of sACN start-codes

Posted: Fri Sep 24, 2021 5:04 pm
by mcallegari
Check added upstream