How does the virus distribute DSP load?

  • I am trying to troubleshoot a multi-timbral song I've composed for the Virus TI Desktop. The Virus appears to be running out of DSP power at one point in the song. At first, a particular FX sound would only play about 50% of the time. By removing some notes/parts around the time that sound is triggered, I can at least make it trigger 100% of the time- but there is often a loud pop now right before you hear the sound, which is not part of the patch itself. This only occurs about 50% of the time- so the note always plays now, but half the time it's accompanied by a loud pop.


    The Virus is not clipping (max volume's just a little higher than -6db for the mixed output), so I'm almost certain this is a DSP/polyphony issue. (Also, while I do have the Virus Control plugin loaded, all audio is going out Analog Out 1+2, not the USB audio. My audio interface is a RME Fireface UFX at 44.1kHz, 24-bit, 256 samples, and I do not experience performance-related pops of this nature with any other instrument.)


    Anyway, in this thread, I noticed this passage:

    Quote

    there are 2 chips in the Ti and they each get one synth part; 1st chip gets part 1. 2nd gets part 2, then the 1st gets part 3, and 2nd chip gets part 4....etc. What does this mean? Simple: If you use a thick unison lead and pads on channels 1, 3 and 5 you might run out of voices, even though the 2nd chip still has DSP power to spare.


    So, my question: What exactly is this saying? Does the virus assign even-numbered multi parts to one chip, and odd-numbered parts to the other? If so, wouldn't that mean the virus never used all its DSP power if you were using it mono-timbrally (only one multi part)?


    I ask, because I wonder if I can minimize the DSP load during my song by shuffling the parts around. I don't want to bother with this if the Virus actually distributes the DSP load differently.

  • is there an official source for that? (dsp for odd/even parts


    it seems unlikely to me, as it would also limit part priority usage,
    id assume/hope it allocates per note using current load and 'patch complexity' to determine allocation.


    you might be able to test the odd/even hypothesis ...
    part 1 - create a really complex patch (usual suspects reverb, delay, osc , etc etc), so it will note steal noticibly
    part 2 - simple patch
    use a split (or midi) play notes on both parts, now ... does the ti steal from both part 1 & 2 or just 1


    if note stealing occurs on both, then the hypothesis is false...
    if its only in part 1, more digging is needed ... (hypo is not necessairly true) as it could be intelligently deciding to cripple one part rather than both ... as we dont know its stealing strategy, perhaps putting part 2 as low priority might tempt it to steal part2 .. again to disprove hypo.


    would be interesting to get an offcial answer :)

  • I confirmed it with a test. The problematic patch is on part 11. If I mute part 11 and move the patch to part 14 the note won't play at all (out of DSP- and I confirmed my MIDI and output settings were correct, too... you can hear the patch if you play it by itself). If I mute part 14 and un-mute part 11, I can hear the note again- but of course still with the pop.


    So, I learned something about the Virus, but it didn't help me with this issue. :)


    However, I just went through all the patches currently loaded and set any instruments that were only playing one note at a time in the song to "Mono 1", and this appears to have given me enough juice to avoid that pop.


    I am still frequently hearing an unwanted click later on (around when this FX patch stops playing), but haven't diagnosed it yet. It is quiet enough that it might be acceptable for my purposes, though.

  • Ok, I was intrigued... and think I have disproved the theory... (unless someone can see a flaw in my test)


    Part 1, used GertLead and removed mono (i..e play poly) (complexity 5)
    Part 2, used AI2 Pad (complexity 3)


    played a high note on Part 2 (channel 2) and kept it down.
    played many notes on Part 1 (channel 1) , layed my arm across keyboard to get enough notes :o)


    Part 2 stopped playing, i.e note was stolen to handle Part 1.


    Out of interest (only) i decide to test priority - I then made part 2 a high priority (default is low), did the same test... and this time Part 2 continued to play.
    Finally I set both to high priority, and then had first behaviour, Part 1 stolen as expected, as they are then equal priority (both high in this case, both low in previous case)


    This means that the note stealing algorithm treats odd and even parts as equals i.e. same resource
    I believe this proves the dual DSP are a shared resource across parts, and the odd/even split of DSPs resources is a myth, or at least not true of OS 5.0.3


    Of course, my suspicion is the note stealing algorithm is not as simple as above might suggest ... there could be all sorts of 'interesting' considerations it could take into play. e.g. audibility, usage of FX, tail times etc etc.
    The above only proves it can steal across odd/even parts so must consider this shared.
    (the only 'flaw' in my argument I can see, is if there was a mismatch in the note stealing algorithm and the DSP algorithm but this is highly unlikely and would be a bug)


    It would be cool if someone else could verify my above test (or similar) , as i think its pretty important to squash this myth... if we dont get confirmation from Marc/Access


    Sorry, I know it doesnt help your situation UltimateOutsider ... as im not sure how this affects your problem.


    EDIT:
    just did another interesting test with unison... it seems it will steal notes out of a unison first which is quite cool.
    i.e. same test as above but changed part 2 to use twin unison, and carefully introduced notes in part 1, and you could hear part 2, first loose on voice in the unison.
    im guessing it probably thins all voices first, and then only cuts all notes if absolutely necessary ... though its quite hard to hear (which is guess is the point ;o)
    (also be careful, if you up the relative priority, again it will not steal the unison voices either... be nice if that was an 'option')




    conditions of test:
    5.0.3, TI (1) Keyboard, VCC but using direct audio output (to avoid issues with USB audio)
    a TI2, would use same algo, but of course may require more notes to reproduce test.
    patches were chosen to have long sustain, and to be sufficiently different hear note stealing.

  • Thanks Marc - but now im confused :o)


    In the above test, playing notes on part 1, caused notes from part 2 to be stolen...
    but your statement contradicts this entirely, since part 2 (being even) should be independent of part 1 (being odd) ... i only had one simple note playing on part 2,
    so if it had its own DSP there is no way it should have been curtailed.
    yet, it was clear this was happening in VC, and also clear from the audio..


    Note:sorry when i said stopped playing the part, this was only because there was one note... as i followed onto to say, it stopped because 'the note was stolen'


    what am i missing? I was doing this in ableton live directing the keyboard input to TI track 1 & 2, it was obvious this was being routed correctly, as i could see and hear the 2 parts playing.


    if the DSPs are allocated by part (/midi channel) as you say, then the only explanation I have for the above behaviour is that their is a serious bug in the note stealing algorithm, with it not taking into account the DSP allocation of channels... (which i mentioned in my post as a possible but unlikely reason) ... do you think there is such a bug? is access aware of such a bug? perhaps you can attempt to reproduce with my steps above?



    can someone else test this to prove im not mad, and mixing something fundamental up :o)

  • @ thetechnobear - i did what you describe and happens to me exactly what you describe.
    Marc says you should avoid reverb and unison, but your patches doesn't have unison and reverb.
    Only long sustain on the pad and delay on both.
    Even with the delay off it continues to happen.


    what makes the patches so dsp stressful?

  • Load... well this will be quite complex, but I think can be simply thought of as, what creates work for the DSP.
    a) to start with you have number of notes presents... or to me more specific voices - obvious unison increases this.
    b) then its how long does the note last ... this is from note on, to the time the last bit of sound is present (if you have 0 release, and no delays etc, then its when you release the key, but adding delay ,release,reverb all extend this time)... actually, if you think about it, this is really just an extension of (a)
    c) processing required to produce the sound... here we have things like number of oscillators, type (e.g. hypersaws use more processing power), fx (distortion doesnt increase (b), but it still takes power)
    in my example, really i went for a pad, so hits (c), but keeping the notes down, due to sustain hits (b)


    good that you reproduced, shows i didn't just do something strange :o)


    but, its back to access... if odd parts are to DSP 1, and even parts are to DSP 2, then why does a note played on an even part ( on DSP 2) caused a note to be stolen from an odd part (on DSP 1)
    this makes no sense, and is either a bug or the explanation of voice allocation over DSPs is incomplete.


    as I said at the start, even and odd channels being used as an allocation algorithm seems way to simplistic, and lets be clear, it would be very easy to come up and implement a better algorithm for something that is fundamental to the operation of the TI. I find it very hard to believe the talented programmers (and i really believe they are!) at Access would settle on such an approach.
    for (an obvious) example distribute the load evenly across the DSPs on a per note basis, i.e. have the same number of voices being voiced on each.
    this of course would depend on two things....
    a) patch data is available to both DSPs, so both DSPs are capable of playing any patch at any point in time.
    b) the scheduler, needs to be know the current DSP load (would be useful to also know patch complexity, to have an idea 'expected' load in near future due to tails)
    Even if this was not possible, then a more intelligent algorithm could still be implemented on a patch basis (i.e. that one DSP has to process the same part) , this would be based on two criteria
    a) complexity of patch and expected duration (tails)
    b) priority
    the first could be used to even distribute 'expected' load, then second could be used dedicate first dsp to low priority parts, the second to high priority (or probably better would be to combined with low 'complexity' parts)


    id assume in all cases of allocation, the note stealing algorithm must match and must be on a per DSP basis i.e. there is no point in stealing a note, on the DSP that does not have an issue with current load.. you gain nothing.


    I might do some more testing,
    e.g. do you get more voices in single mode for a particular patch? (i.e is it using both DSP), can we determined other scenarios when note stealing is avoid (like ive shown with priority) ... can we prove that (or not) that note stealing doesn't happen across DSPs , if so this may lead us to a way to better understand DSP voice allocation.



    As I say back to Access...
    - is there a bit more intelligence to DSP allocation that just the odd/even split, can we get some details?
    - In single mode... are you saying only one DSP is used?

  • thetechnobear -


    sorry, it took me a couple of days to find out myself. each DSP can load balance ONE part to the other DSP which will assist unless it is under heavy load as well. as it turns out, you cannot determine which part will balance off because the process in itself is dynamic and depends on the current workload. that of course makes it impossible for you to guarantee that the situation described above can never happen.
    one thing might help: navigate to the part bar and open the context menu for the "D" button (see attached screenshot). you will see an option called "Part Priority". this will help to balance things.


    hth, marc

  • thanks for getting back to me,
    its really good to hear that the virus is using dynamic allocation, somethings id assumed and hoped was the case :)


    the only thing i don't understand, is that i only had 2 parts on part 1 & 2... since the note was stolen it must have been on the same DSP
    ... no other parts were bring voiced, so why would part 1 be shifted to part 2 dsp ( or vica versa).
    i could understand this IF part 1 used all of the its dsp resources, and the new voices for part 1 were added to part 2 dsp , ie it wasnt moved totally, but just moved over new voices to allow more notes for part 1... this would be reasonable since, then if it used up ll resources on the 2nd dsp, part 1 would likely be stolen as its note had been down longest.
    ( if this is the case this implies the virus is allocating ( or reallocating) at voice level rather than the whole part - no?)


    as i mentioned in my earlier post, part priority does come into play and prevent the steal - unsure if it stops the allocation to the 2nd dsp, or if its just steal from the lower priority part on that same dsp (once its been pushed over)


    thoughts?

  • cool, that was kind of my assumption.
    presumably its basically, shifts the voices of a part, to avoid note stealing on that part IF...it wouldn't 'obviously' cause note stealing on the other DSP.
    this strategy works quite well with part priority.


    I assume that the once part 1 shifts to DSP 2, it stays there, unless DSP 2 later under high load, and then there is 'space' to move it back to DSP 1.


    In practice (with a few parts) as you say this would all become quite dynamic, as parts are moved around depending upon current free load on DSPs.
    ... which is cool, means the DSPs are being utilised well :o)

  • If I'm doing my test correctly this odd/even part dsp balancing in multi mode no longer seems to be the case (I haven't tested the seq mode yet) on TI2 5.1.7. (At least when effects are not used) I seem to be able to achieve around 84 voices in one odd-numbered part before I hear a low priority note being stolen from an even-numbered part.

  • If I'm doing my test correctly this odd/even part dsp balancing in multi mode no longer seems to be the case (I haven't tested the seq mode yet) on TI2 5.1.7. (At least when effects are not used) I seem to be able to achieve around 84 voices in one odd-numbered part before I hear a low priority note being stolen from an even-numbered part.

    Which odd numbered Part did you test with?

    Part 1 is special as it can use both DSPs (at least in SEQ MODE).

    Bass Player and Synthesist.
    Virus TI2 Darkstar | Virus TI2 Desktop | Moog Sub 37 | Blofeld | Machinedrum | Monomachine | Analog Four | Digitone | MPC Live | NI Maschine+
    Mac OS X 10.14.6 (Mojave) | Cubase Pro 11.0 | Ableton Live 9.6 | Logic 10.4 | MainStage 3.4 | NI Komplete Ultimate 13 | RME Fireface UFX+

  • I now doubt my test results, it's possible voice stealing still occurred without me noticing if the virus just lowered the actual played unison voice count. I will attempt a different testing method without using unison to detect voice stealing