Another potential issue here that would need to be dealt with, especially if going a DMA route isn’t possible, is that the ws2811 requires disabling of interrupts while writing out LED data - the timing requirements are fairly tight and precise. This means that your protocol for sending data to the DUE’s will need to take into account waiting for them to be in between writing frames of rgb data out. For timing purposes, it rakes about 30µs per rgb led, which means you have, if you use 100% of the cpu 33,333 rgb led updates/second.
Of course, you’ll need to carve out some portion of the CPU time for receiving data from what ever is sending data to your due’s - bringing you down to 16,666 rgb led updates/second and if you want 30fps video that means each due should be limited to 550(ish) leds.
Your 160x8 setup for a single due is going to have a 38.4ms write time, which is going to cap you at 26fps at 100% cpu usage, which means you’re going to get closer to 15-20fps with this arrangement.
I might be able to play games with interleaving ws2811 writes to do multiple strips in parallel, which should up the aggregate data rate per device.
Note that I don’t yet support the DUE in the library - while the teensy 3 is also arm based, i’m not 100% clear on the differences in arm platforms involved. I also don’t have a timeframe for getting DUE support in place yet. I need to get the rest of the library wrapped up and released, in part because I have a handful of large(ish) projects over the next 3 months that I need to start devoting time and attention to.