Options
DSP0 & DSP1 BusTx BusRX
soundmindz
Posts: 0
Can I assign my object in London Architect to a specific DSP?
By doing this and knowing which objects are in which DSP, I can control the amount of bus traffic required between chips and not exceed the bus limitations when I design files correctly.
It appears as if the program fills DSP0 and then begins using DSP1 which means that I there will have to be a lot of figuring out ahead of time which objects to create and what order to create them in to try to guess which DSP will be assigned automatically by London Architect.
By doing this and knowing which objects are in which DSP, I can control the amount of bus traffic required between chips and not exceed the bus limitations when I design files correctly.
It appears as if the program fills DSP0 and then begins using DSP1 which means that I there will have to be a lot of figuring out ahead of time which objects to create and what order to create them in to try to guess which DSP will be assigned automatically by London Architect.
0
This discussion has been closed.
Comments
Short answer: No
Medium answer: No, you don't need to.
Longer answer: I think the idea of allocating objects to particular DSP's has stemmed from previous (and older) iterations of other DSP platforms where a combination of things meant that as a system designer, it could be prudent to consider these things for very DSP intensive systems.
However, the Soundweb London hardware and compiler do a whole heap of wizardry behind the scenes which means you just don't need to think about that sort of thing, particularly if you're using the 'X4' range of processors (BLU-800's or BLU-160's).
Martin
My current configuration for BLU-160 has exceeded 100% in the BUStx - BUSrx even though I have quite a bit of DSP remaining.
The reason I surmise is that as I add devices in the program in the beginning they are added to DSP0 until a certain level is reached and then they are added to DSP1.
I was not programming configuring linearly following signal flow since I discovered the new wiretags. I was placing like devices in labeled boxes so that each could be found with relative ease for making adjustments. The entire system is programmed with wiretags.
The flow is such:
Equipment Room 1
All Inputs - All mixers - All Room Combiners - All EQ - All Crossover/Limiters - All Outputs
I then added duplicate wiretag destinations for four points in the signal path for external monitoring. These points run into source selectors
Duplicate the above for Equipment Room 2 and Equipment Room 3
By the time I get some of the Source Selectors, they are creating multiple BUS connections between the two chips causing it to exceed the limitations.
If I can go into a single \"room\" in signal flow and reassign these to the same chip, it will eliminate many of the BUS connections.
My only other option is to reconfigure the whole system by adding only the objects that I want on DSP0 first, then adding the objects that I want on DSP1 - this is a whole lot of extra work.
I sent the file to tech support and was told that I was taking multiple locations to multiple places and this was causing the issues. It was suggested that I drop some of the bands in the parametric EQs to get back DSP of which I responded that DSP is not the issue BUStx and BUSrx are exceeded and I do not understanding how dropping a few filters will give these back to me - I do not have an exceed DSP - It jumped from 60% to >100% by the connection of one wire.
Wow, that's quite an achievement....!
Unfortunately, the simple answer to your question is still no but I suggest bugging the TSG guys (particularly Dan, he loves it) to see if there's anything which could be done from their end.
I suspect however that regardless of the answer, it's still going to be quicker for you to attempt to rebuild it to in a different order to see if it helps.
Sorry I couldn't be more help.
Martin
All of that being said, it's possible that this bs-tx/rx problem is being caused by using so many wire tags. I haven't seen your design file, but I wouldn't be surprised to find that it works fine if you rewire it without the wire tags. This would be a good idea as a general principle anyway. Always remember that somebody else will almost certainly have to deal with your design file someday. In most cases, using more than a few wire tags makes the design file almost impossible to read or understand.
Dan
A Processing Object is made up of many (sometimes hundreds) of primitives. A primitive is essentially an algorithm in the DSP. The compiler distributes primitives across the DSPs. So by forcing a whole Processing Object on to a specific DSP, then you're already less efficient than the compiler.
There are also other considerations, for example particular processing objects can only live on a particular DSP, latency through the DSPs, and delay compensation.
The compiler tries to be as smart as it can in coming up with a solution. The only true way to come up with the best solution all the time is to try all possible combinations, but that's not practical (you'd be long dead before it finished compiling).
It does seem tempting that you could manually produce a better result than the compiler, and you may get lucky and somehow pick a more optimal solution. However, given what I said in the first paragraph, it's extremely unlikely.
Graham
P.S. We did look to see how long it would take to compile a design of 25 processing objects testing every possible combination. If your PC was fast and could do 10 compilations a second, then it would take something like 20 billion years to complete. The big bang was only 13 billion years ago.