Vienna Symphonic Library Forum
Forum Statistics

194,192 users have contributed to 42,912 threads and 257,930 posts.

In the past 24 hours, we have 1 new thread(s), 14 new post(s) and 83 new user(s).

  1. Home
  2. Software
  3. Vienna MIR & Vienna Suite
  4. Build 4657 is less efficient than 4604 and has to run at higher latencies

  • Build 4657 is less efficient than 4604 and has to run at higher latencies

    B
    B

    After singing the praises of build 4604 in the "VE PRO new public beta 4657 available" thread, I've just tried out the latest build 4657 and have found that I have to now run at higher latencies.  As a consequence I've reverted back to build 4604 which is more efficient here than 4657. 

    Details....

    With build 4604 in my current (very large) project I can run at 256 samples without pops and crackles (Cubase4, Lynx L22, XP64).  However with the latest build I cannot run at my preferred 256 samples setting without ASIO spiking causing corresponding pops and crackles.  With build 4657 I have to run at 512, which is simply not responsive enough for me.

    Under both 4604 and 4657 CPU and ASIO meters are barely sweating (both under 20% - i7 920 cpu) however with the latest build I get the dreaded ASIO red light flashing / spiking at 256 samples. VEP latency is at 2 buffers for both examples

    Thought you'd like the feedback.

    Brett
  • A
    A
    interesting. because I'm on cubase and I'm surprised at the latencies too, although I'm no one to complain because I don't even know what is acceptable and whats not. FYI, when I run the samples without any networking and VE PRO, I can run very smoothly at .9 of a millisecond latency on my core i7 and a $75 m-audio card running at 64 samples =] This is not the case with VE PRO. I can't even attempt 64 samples on the m-audio card and usually something like 512 or 1024 samples at 96KHz plus the x2 VE buffer is OK.
  • K
    K
    last edited
    last edited

    @brett said:

    After singing the praises of build 4604 in the "VE PRO new public beta 4657 available" thread, I've just tried out the latest build 4657 and have found that I have to now run at higher latencies.  As a consequence I've reverted back to build 4604 which is more efficient here than 4657. 

    Details....

    With build 4604 in my current (very large) project I can run at 256 samples without pops and crackles (Cubase4, Lynx L22, XP64).  However with the latest build I cannot run at my preferred 256 samples setting without ASIO spiking causing corresponding pops and crackles.  With build 4657 I have to run at 512, which is simply not responsive enough for me.

    Under both 4604 and 4657 CPU and ASIO meters are barely sweating (both under 20% - i7 920 cpu) however with the latest build I get the dreaded ASIO red light flashing / spiking at 256 samples. VEP latency is at 2 buffers for both examples

    Thought you'd like the feedback.

    Brett

    Could you specify your exact setup? Thanks.
  • B
    B

    Sure Karel.

    I'm running Cubase 4 latest version under XP64 with a i7 920 with 12GB RAM.  I'm currently using VEP on this computer locally and am using both the 32 and 64 bit servers.  My current project is rather large and demanding and so latencies would naturally be higher than if I was simply writing a 3 minute song - I'm using about 9GB RAM and have many many cues across 3 x 1hr eps of a TV series.  The demands I'm placing on my setup are largely sample based - everything is in realtime, there are no mixdowns.  As I mentioned in my earlier post, the cpu and asio meters barely raise a sweat (the i7 is great).

    With build 4604 I can run at 256 samples beautifully, however as soon as I installed 4657 I had to bump up to 512 samples latency to avoid breakups.  There seemed to be no extra load shown in the cpu or asio meters.  However re-installing 4604 meant I could drop back to 256 right away.

    If I can have a rant (not directed at VSL) I find it frustrating that I can get crackles when the cpu and asio meters are barely moving at low latencies.  With my old setup (a Pentium D) I would get pops and crackles when the cpu/asio meters were above 90% which makes sense to me.  However on this new system I get pops and crackles when the asio light flashes despite the meter being below 20%.  Raising the latency solves this.  I suspect there are (for want of a better word) asio bottlenecks with cubase and multithreading.  Be great to know where the bottleneck is because it's certainly not with the cpu.

    Anyway, that last paragraph is a separate issue.  The main thing is that we all would like to run at the lowest latencies possible given the particular demands of any given project, and I can run at lower latencies with 4604 (which I love!) compared with 4657.

    Regards - Brett
  • K
    K
    Could you try this: Install 4604, backup its VST dll's and uninstall it again. Then install 4657 and replace its VST dll's with your backup. If my assumptions are correct, this will give you the best of both worlds (and I'll also know for sure what to fix for the next release). Thanks a lot.
  • B
    B
    last edited
    last edited

    @Karel said:

    Could you try this: Install 4604, backup its VST dll's and uninstall it again. Then install 4657 and replace its VST dll's with your backup. If my assumptions are correct, this will give you the best of both worlds (and I'll also know for sure what to fix for the next release). Thanks a lot.

    The above suggestion didn't work I'm afraid - I couldn't run at 256 samples with a 4657 install with the 4604 dll's.  I had to run at 512 to avoid the clicks and pops which is just the same as a clean 4657 install.

    However when I did the reverse - a 4604 install but using the 4657 dll's - I could run at 256 again, the same as a clean 4604 install.  It looks like the issue is with the 4657 exe files rather than the 4657 VST dll's.  Hope this helps

    Brett
  • K
    K
    This helps indeed. Thanks.
  • K
    K
    What I'd like you to try next is just a plain 4657 install, but when running the server/standalone, set the process priority to normal rather than high (you can do this by rightclicking the VE Pro process in task manager). This should fix it.
  • B
    B
    last edited
    last edited

    @Karel said:

    What I'd like you to try next is just a plain 4657 install, but when running the server/standalone, set the process priority to normal rather than high (you can do this by rightclicking the VE Pro process in task manager). This should fix it.

    Well, I would never have expected it but of course you are right Karel.  Lowering the priority cleared up the crackles and allows me to run at 256 samples latency again with 4657.  Seems counter-intuitive to me but it worked.  Did 4604 default to normal priority but 4657 default to high?  What will you do for the next build?

    Brett
  • M
    M

    We have reset the priority to normal for the next build.