Rayzoon Technologies LLC

[dancerchris]

I'm seeing some chatter on the forum here, but no obvious concensus on the issue of the GUI and it's effect on dropouts. I am running J3 the same way I did with J2 and the effect seems to be that the interface graphics are causing audio dropouts (goes away when I close the GUI).

Was there a significant increase in the compute power required from 2-3 or is there a different graphical method. Admittedly I run a low latency set up, and I haven't set the articulation display to off (but doesn't that defeat the editorial purpose of the interface anyway?) I have tried turning LOD off and it makes no difference. Another thing is that I am already running my Graphic accelleration slider way down so that I can achieve the high latencies with my vid card.

Any comments?

[Ralph [RZ]]

Personally, I do not recommend setting graphics acceleration to zero. This burdens the CPU more instead of letting the GPU handle very common routines, such as BitBlt. If you cannot reach low latency with full GFX acceleration then there is another underlying issue, such as IRQ sharing.

Please make sure you are running JS 3.0.1 and also keep tabs on this forum as we will continue to optimize GUI performance.
_________________
Ralph Zeuner
Rayzoon Technologies LLC
http://www.rayzoon.com

[dancerchris]

Thanks for your response Ralph.

Actually I'm running with the accelerator slider at about 40%, not 0%. I've run into problems with the card at full and it is mostly mouse "zipper noise" when I'm running low latencies. This is with my DAW Ableton Live. This is independent of JS. I have been able to run at very low latencies in this arrangement and be free of pops etc. The IRQ that my graphics card is on is only being shared by the PCI standard PCI-to-PCI Bridge. (Not much I have been able to do seems to change the automatic setup of the IRQs.) I was able to run JS2 in this mode free of problems, but now JS3 seems to get a lot of pops when just running alone (albiet with a Toontrack Superior 2 kit). It also hangs a bit with a very load pop when closing the interface window. Then with the interface closed it is quite and smooth as butter while playing.

My question was since the interface is different than JS2, is the higher graphics demand causing problems on different systems?

Thanks

Chris

[Ralph [RZ]]

Quite a few things are different under the hood of JS3 bu the GUI is larger and more GFX intensive. We are working on optimizations. Are you rinning 3.0.1?

When you say 'mouse zipper noise', are you saying the noise is related to mouse movements? If so, I recommend changing mouse drivers as this should not occur.
_________________
Ralph Zeuner
Rayzoon Technologies LLC
http://www.rayzoon.com

[dancerchris]

Yes, I am using 3.0.1.

Ralph, I don't expect you to run down my problems with hardware issues (if I have them.) I have lots of tools to do that myself. (DPC latency checkers, etc.) I am just trying to ascertain the difference in graphics usage so I can see whether or not there is an issue with my hardware and whether or not to wait and see if there is something buggy with JS3. I mention the mouse "zipper noise" becuase that is what most people describe it as. Personally I would just say that mouse actions cause video actions that create problems with the audio in the form of dropouts or pops. I am using an NVidia video PCIe card and a firewire audio box. I am running total latency cycles of about 10 ms.

Again, I didn't seem to have that under JS2. To me it would seem that JS3 which has (as you say) a different graphics scheme is either tweaking some graphics issue that my hardware has, or the new JS3 interface is causing some kind of DPC Latency problems.

Yours Truly,

Chris

[Ralph [RZ]]

Let's see how 3.0.2 will work for you. We should have it out as a Beta in a few days.
_________________
Ralph Zeuner
Rayzoon Technologies LLC
http://www.rayzoon.com

[dancerchris]

Ralph: Interesting note to you reguarding sub-hosting S2. On a whim I decided to try to use J3 to just send MIDI only to my host and then on to S2 on another track. This seemed to work better than actually subhosting S2 in JS3 terms of the number of dropouts. But I did note a couple of things. If I loaded the kit with S2 subhosting it would add the kit samples in both JS3 and the external instance of S2 into the cache buffer for S2. When I would delete the kit within JS3 the external instance of S2 would still have the samples for the JS3 instance loaded. I couldn't get it to dump the cache without getting rid of the track with JS3 on it even after changing to a JS3 native kit.

Is JS3 not letting go of this subhosted instance of S2?

Also I was a little unclear as to how to load the mapping for a S2 kit into JS3 without triggering the subhosting. I managed to stumble into it but it is still unclear to me.

FYI.

Yours Truly,

Chris

[Ralph [RZ]]

Chris: the trick is to use 'MIDI Out Only' in JS3, which causes JS3 to use the mapping needed for S2 without actually loading S2.
_________________
Ralph Zeuner
Rayzoon Technologies LLC
http://www.rayzoon.com

[dancerchris]

Yes I figured that part out. There is the little switchable text in the mixer panel. However if I inadvertently load the subhosted kit, it basically allocates memory space in the S2 application for the kit samples. Even after I go switch the "midi only" text in the mixer panel to "on" it does not release the memory for the samples that were loaded into the subhosted instance of S2. I can open up the DAW hosted instance of S2 and the amount of memory for samples loaded starts out with the sample size of the subhosted S2 kit. So it would seem that there needs to be some notification that the memory was released and it is not being done.

BTW I can avoid this problem by turning on the "midi only" switch first before selecting the internal S2 kit for proper external midi mapping. I'm just pointing out to you that there are possible problems with the memory allocation here, i.e. S2 needs to be notified that the JS3 allocated memory can be released when the "midi only" switch is turned on. (I'm not a VST programmer so I don't even know if this is possible.)

[dancerchris]

Ralph: I am still have problems with dropouts and JS3. I really suspect now that it is not my hardware but JS3. I use DPCLAT.exe to check for DPC latencies and I'm all good even when I'm getting the dropouts in JS3. I wanted to try to go back to JS2 but my links are expired on my download page. Can you update these.

Also what can I do to help diagnose a problem with JS3. I am assuming the JS2 will run fine (like it did in the past). Is there some way to look at the log file to find error notices? I recorded a session and selected the "full debug log" which caused even more dropouts (intensive disk write, I know). Any help here would be appreciated.

Thanks!

[Ralph [RZ]]

Please send me rzdlog.txt from My Documents\jamstix3 and tell me your OS version, host version and audio driver.
_________________
Ralph Zeuner
Rayzoon Technologies LLC
http://www.rayzoon.com

[dancerchris]

BTW. Do you have a minimum host plug-in buffer size. I am currently using a value that is equal to my latency buffer. What do you suggest for JS3?

[Ralph [RZ]]

The log shows you are running at 96 samples latency. Please increase to 128 and see if the dropouts stop.
_________________
Ralph Zeuner
Rayzoon Technologies LLC
http://www.rayzoon.com

[netandif_2008]

[dancerchris]