Vienna Symphonic Library Forum
Forum Statistics

182,000 users have contributed to 42,199 threads and 254,646 posts.

In the past 24 hours, we have 4 new thread(s), 9 new post(s) and 51 new user(s).

  1. Home
  2. Software
  3. Vienna Instruments Pro
  4. event input audio unit - utilising high cpu.

  • event input audio unit - utilising high cpu.

    T
    T

    Hi,

    Ive recently bought VEP5 and I'm very happy with it.

    But Ive been having a small problem.

    Im using a specialised audio unit host that is single threaded, so in order to reduce the load on this host when running VSTS/audio units, 

    I want to just run the VEP EventInput & Server audio units, and then run my instrument VSTs within a VEP instance (on the same machine)

    This works BUT...

    I find for when I'm running some VSTs that have complex patches and are using alot of CPU within the VEP instance (~50% cpu reported in VEP), the VEP EventInput audio unit on the client also consumes alot of CPU.  Its not all VSTs its just some.

    This confuses me... Id have assumed, if I was not overloading the computer (i.e. i have spare cores) then the VEP event input is only sending midi, and so the CPU load in my single threaded client should be pretty constant and low.

    (even when i turned off the output being sent back to client the load was still high... so it seems to be the event input audio unit rather than the server)

    Ive noticed that if I turned the 'latency' up on the on server audio unit up, then this reduces the load in the client.

    ... again, I'm unsure why this would reduce the cpu load on the event input audio unit.

    my only guess, is that the VEP instance is somehow blocking/slowing down associated event input audio unit when its under load... but at 50% load on the VEP instance - I'm surprised its not able to cope a bit better.

    Finally I did a test using the event input audio unit etc in Logic, and it was fine... which perhaps is not surprising, as logic in multi threaded.

    Does anyone have any more suggestions, or perhaps some explanation of what is going on?

    Thanks

    Mark
  • M
    M

    What buffer settings are you using for the VEP instrument plugin(s)?
  • T
    T

    Hi,

    ive tried None to 4 :)   around 2 it does seem to reduce to a reasonable level. (but at the cost of latency)

    What I dont understand is if the instance is under higher load, why should this then create higher CPU load on the plugin, which is only a client after all, and there is plenty of cpu capacity on the machine.
  • M
    M

    In a 0-latency setting the plugin load, or shall we say processing time, will be equals to the processing time of your slave computer, including network latency. This will show up as a load in your sequencer. In a modern multithreaded host this might however only be a virtual load. The time the plugin processing thread spends waiting for processed data to return from the slave is yielded to other threads.

    When using more buffers, the plugin will operate asynchronously, and should immediately return the process call after copying the buffered data, adding a minimal load to the host.
  • T
    T

    thank you for that... 

    so basically:
    no buffer = sync
    buffered = asyncronous

    I find this a bit surprising for event input though... why does it have to wait for audio (when no buffer), when it is only sending midi, and it is the vienna ensemble pro vst that is recieving the audio?
     
    (I do 'kind of' understand why you might want to do this if you send midi to the vienna ensemble pro vst directly, just not when you send it to the VEP event input)

    thanks for your help. this is really helping work out how to get this setup optimally 
    Mark 
  • M
    M
    last edited
    last edited

    @thetechnobear said:

    thank you for that... 

    so basically:
    no buffer = sync
    buffered = asyncronous

    I find this a bit surprising for event input though... why does it have to wait for audio (when no buffer), when it is only sending midi, and it is the vienna ensemble pro vst that is recieving the audio?
     
    (I do 'kind of' understand why you might want to do this if you send midi to the vienna ensemble pro vst directly, just not when you send it to the VEP event input)

    thanks for your help. this is really helping work out how to get this setup optimally 
    Mark 

    Actually, the "1 buffer" setting is a sort of semi-synchronous mode. 2 buffers and up are fully asynchronous.

    Regarding the Event Input, it doesn't send any data directly to the VEP server. It sends its data to the VEP plugin - which then sends it to the server. As I explained before, in a zero-buffer mode the host has to wait for the midi data to be processed, returning a block of audio samples. Depending on the process block size of the host, some further rebuffering of midi data from the event input plugin is necessary. In most cases you should try to avoid using the Event Input plugin.
  • T
    T

    Thanks for that, your explanation corresponds very well to what Im seeing with the host Im using... 

    Im using the Event Input plugin, as Im doing alot of voice per channel midi using an Eigenharp,

    I assume I have to use the Event Input plugin so that each VST in VEP gets 16 channels. ( I think this is the only way I can get multiple midi ports on one VEP instance?)

    Thanks

    Mark
  • M
    M

    Which host are you using?
  • T
    T

    the main host im using is EigenD which is written for thr Eigenharp, which is why im interested in having 16 channels per instrument  to utilise 'voice per channel' midi, but im aslo trying to use Max/msp as well.

     is there another way i can get 16 channels per instrument, on the same instance without using event input.

    if it can be done in another way perhaps i can implement this in max.