Possible idea to fix slow Break time on serial-based controllers degrading refresh rate

Hi.

Having the same problem on another platform (Linux, PC), I found another solution : instead of explicitely sending a Break, if we send a null byte at a slow enough baudrate, it will be interpreted as a Break followed by the Mark-After-Break on the fixtures' side.
(I thought about this trick first for microcontrollers with rudimentary UARTs which can't explicitely send Break states).

Therefore, in the _transmit() method from the SerialController class, instead of :

        # Write
        self.__device.send_break(100e-6)
        sleep(10e-6)
        self.__device.write(data)

I would do something like :

        #self.__device.flush()
        self.__device.baudrate = 80000
        self.__device.write(bytearray(0))
        self.__device.flush()
        self.__device.baudrate = 250000
        self.__device.write(data)
        #self.__device.flush()

Because the serial device stays opened, we need to flush the write operations before changing the baudrate (it is not done in the Serial class, despite the reconfiguration), especially just after writing the null byte at a slower baudrate.
However, whereas a flush after writing the DMX data is required in a raw test of this code snippet, it seems to break things when done inside the SerialController class, for an unknown reason.

So the fix can unfortunately not be validated yet, not counting that I can't test it on several platforms.
By the way, the raw test shows a refresh rate of 34Hz or a bit more (VS the theoretical maximum of 44Hz) for a 512-channel frame : it seems not so bad, given the processor time consumed by the Python interpreter and all software layers down to the kernel.

What do you think about it ?

Start by reading the SerialController._transmit() method and compare its current send_break sequence with the proposed baud-rate and null-byte sequence. Reproduce the raw serial test, then validate the controller behavior across available platforms; done means improved DMX refresh without the flush or reconfiguration issues described.