Artnet and osc

[CoreyMcCdallas]

I have a large install that incorporates many video outputs, lots of layering, and lots of artnet mapping. (Currently 48 fully loaded universes with another 48 to come).
Even with the datapaths taking a lot of the workload offt of the video output end, running an i7 with 64gigs of ram, raid ssd's, a Titan x, and zero real time effects, I am experiencing very low frame rates when I get to just 4-5 layers.. (this may be a file format thing so the next question I have been searching the forums for is the best way to convert existing .mov video files to the files to dvx3 codec)

Even if, because of the lack of unicast in the artnet implementation, I will need to have another machine handing artnet for the second part the pixel mapping element. (Or if nothing else, just to have some redundancy)

So question is, because of the broadcast nature and the heavy artnet traffic, can I still get reliable communication between tthe machines via OSC?
I have no problem adding another set of gigabit cards to the machines, but can Resolume utilize one network simply for OSC, while still using the onboard gb lan card for artnet?

New machine was just ordered with same specs as above, only I was able to snag one of the new 2016 titan x pascal cards that just got released. (Hoping there are not comparability issues there as well)

I am just trying to find a way to make them behave more as a single entity. Currently everything is planned controlled by midi and the plan is to have two concurrent machines running different aspects of the project.

But the new computer should be delivered in the coming week and I can't seem to find enough info on running osc concurrently with the seemingly heavy artnet load already being placed on both machines.

Hope the question I am trying to ask makes sense, perhaps I will be able to more fluently express it after I have had some sleep.

Tia

-Corey

[Zoltán]

48 universes is not much traffic , about 5 megabits/seconds if I calculated right, (48u*512ch*8bit*25Hz+10% overhead)
I wouldn't worry about it unless you'll run both machines to the same wifi hotspot, adding another 48 universes definitely doesn't need another machine.

with broadcast, traffic is the same amount of data sent out from resolume as unicast,
unicast would be better if you have a segmented network with lots of switches and heavy load, where the broadcast packets would arrive everywhere, where the unicast packets would not.

regarding the low fps, what is composition resolution, and file codecs?
DXV would be the way to go btw.

[.lov.]

48 universes is not much traffic , about 5 megabits/seconds if I calculated right, (48u*512ch*8bit*25Hz+10% overhead)

Some corrections: the packet size is 530bytes because of the Art-Net header. Art-Net's refresh rate is 44Hz.

unicast would be better if you have a segmented network with lots of switches and heavy load

Yes, but if you want to make DMX from Art-Net at the end, you will need lots of Art-Net interfaces and network devices like ethernet switches, and that could slow things down since they need to forward data to every ports, especially with non-high quality products.

[Zoltán]

Some corrections: the packet size is 530bytes because of the Art-Net header. Art-Net's refresh rate is 44Hz.

Also the TCP/IP packet adds 20bytes overhead, thus you can count with roughly 10% overhead total.
ArtNet's recommended maximum refresh rate is 44Hz, to keep compatibility with DMX-512, however the minimum is 4 seconds, (800-1000ms recommended).
I measured the Resolume refresh rate being 25Hz.

[.lov.]

Also the TCP/IP packet adds 20bytes overhead

Yep, nice catch!

ArtNet's recommended maximum refresh rate is 44Hz, to keep compatibility with DMX-512, however the minimum is 4 seconds, (800-1000ms recommended).

4 seconds its not the minimum, but the rate of the Art-Net Keep-Alive transmission - if channel data does not changing for 4 seconds, the sender should re-send the packet. Otherwise connection should be considered as closed. Some DMX fixtures automatically set themselves to demo/automatic mode that way.

I measured the Resolume refresh rate being 25Hz.

I guess it depends on the frame rate of the clip actually playing.

[Zoltán]

I measured the Resolume refresh rate being 25Hz.

I guess it depends on the frame rate of the clip actually playing.

It's 25 hz also if nothing is playing,it seems to be independent of the rendering fps also.

[.lov.]

I measured the Resolume refresh rate being 25Hz.

I guess it depends on the frame rate of the clip actually playing.

It's 25 hz also if nothing is playing, it seems to be independent of the rendering fps also.

That is interesting. Would not be wiser to use the clip's fps if its lower then 44?

[Zoltán]

Actually when the fps drops from 60hz the artnet rate drops also from 110kBits/channel.

That is interesting. Would not be wiser to use the clip's fps if its lower then 44?

The clips are rendered at the speed you see in the fps counter regardless of their source frame rates which can also vary, and the lumiverses get their input from the composition.
So I guess you could get the best output quality with 44 fps ArtNet, but then again when the fps drops to 30 you don't have 44 frames ready/seconds.

But seeing the ArtNet refresh drop to 74Kbit/sec at 33 fps rendering - gives around 16 fps ArtNet rate - is not quite what I expect if there are rendered frames which could be sent...

[.lov.]

The clips are rendered at the speed you see in the fps counter regardless of their source frame rates which can also vary, and the lumiverses get their input from the composition.

Yep, I know that, but that would not stop Resolume to send out Art-Net packets less frequently than the rendering thread draws frames, but a higher rate then 25fps IMHO. But our conversation is already off-topic

But seeing the Art-Net refresh drop to 74Kbit/sec at 33 fps rendering - gives around 16 fps ArtNet rate - is not quite what I expect if there are rendered frames which could be sent...

That sounds interesting indeed. @Joris, maybe Art-Net packet transmission limited to the half of the rendering refresh rate somehow?

48 universes is not much traffic...

Back to the start, anyone ever tested how many universes can Resolume output safely? People wiser than me saying in practice you cannot drive more than 10 universes using broadcast safely, even if the theoretical max is a higher number. Never tested it by myself since I don't have enough fixtures to do that, but I'd be curious about the results.

[Zoltán]

48 universes is not much traffic...

Back to the start, anyone ever tested how many universes can Resolume output safely? People wiser than me saying in practice you cannot drive more than 10 universes using broadcast safely, even if the theoretical max is a higher number. Never tested it by myself since I don't have enough fixtures to do that, but I'd be curious about the results.

Enabling all universes in resolume, you can see data rates nicely climbing up to to around 28 megabit/sec. that's still not much on a 100BaseT wired network. (256 universes, and 131k channels, about 200x200 RGB pixels)
Over Wifi that would be another story, which would need further testing.

You could test it with the few fixtures you have, they all will get the broadcasted packets. if they play along nicely I would say it's safe to assume that -at least the same type fixtures- will work just as fine.

I think the limitation with broadcast will be in the receiver node and how fast it can drop the other universe's packets.