Threads and Priorities

[ebinary]

the performance is similar however sa5.exe clamps the cpu up to 100% constantly which is probably not an ideal way to go. fans kick in and things start heating up
inigo

Did you confirm that the CPU usage is really 100% (did the rest of your machine slow down to a crawl)?

The reason I ask is that in Sonar, up through version 2.2, Task Manager always showed 100% CPU usage while Sonar was running. However, the true behavior was actually that Sonar had reserved that CPU usage but was not, in fact, using it. So the fans didn't really kick on, etc, any more than the real usage (indicated in the Sonar CPU meter) would cause.

Sonar changed the behavior with respect to Task Manager for version 3+, but it was a known anomally.

Eric

[ik_ik_ik]

Did you confirm that the CPU usage is really 100% (did the rest of your machine slow down to a crawl)?

The reason I ask is that in Sonar, up through version 2.2, Task Manager always showed 100% CPU usage while Sonar was running. However, the true behavior was actually that Sonar had reserved that CPU usage but was not, in fact, using it. So the fans didn't really kick on, etc, any more than the real usage (indicated in the Sonar CPU meter) would cause.

Sonar changed the behavior with respect to Task Manager for version 3+, but it was a known anomally.

Eric

hi eric, difficult to really know but fans defintely kick in over here and blow a lot of hot air - the fans kicking in could be down to how they are triggered but that things heat up seems like the cpu is working flat out and not simply reserved.

speedswitchxp and task manager show 100% cpu. speedswitchxp also shows that the cpu is forced to max speed if i allow it to be dynamically switched (this being a centrino machine).

the system seems to remain responsive though and the odd thing is that when i'm doing something in energyxt e.g. moving windows around, adding components, etc. the cpu meter dips down a bit. in fact, for example, if i right click and a context menu appears then the cpu meter dips to near 0.

that doesn't happen when standalone is running and i do something in another application although the system does stay as responsive.

it seems to me to be genuinely be using 100% but it's being quite polite about it.

cpu hits 100% similarly on a desktop machine with rme pci/multiface although there's no fans or extra heat to check for in this case but the dipping i mentioned seems to happen there too. i expect this will be common to everyone with the new beta.

i wonder what it is that jorgen did in sa5.exe and the latest beta. my gut feeling is that sa4.exe was a better direction than sa5.exe.

all these test versions are hopefully giving some good clues and i hope the result will be a more efficient environment for us happy users

[ebinary]

wonder what it is that jorgen did in sa5.exe and the latest beta. my gut feeling is that sa4.exe was a better direction than sa5.exe.

all these test versions are hopefully giving some good clues and i hope the result will be a more efficient environment for us happy users

I think jorgen is trying his best to avoid raising the priority. Microsoft's development guides (at least in the past) always tried to talk you out of raising priority if at all possible.

Another potential fallout of raising priority is that XT may not behave nicely when running alongside other audio applications (I typically use XT in standalone and Sonar along side it, so if it killed Sonar's usability I would not be able to use it anymore).

Eric

[ik_ik_ik]

I think jorgen is trying his best to avoid raising the priority. Microsoft's development guides (at least in the past) always tried to talk you out of raising priority if at all possible.

Another potential fallout of raising priority is that XT may not behave nicely when running alongside other audio applications (I typically use XT in standalone and Sonar along side it, so if it killed Sonar's usability I would not be able to use it anymore).

Eric

heh, that sounds like guidelines from the dark and not too distant past when microsoft didn't really cater for realtime multimedia applications - i remember battling with the multimedia api in win95

i'd definitely agree that altering an application's priority is not the best way to go at all, and hope i hadn't given the impression otherwise, but it can indicate where a problem may lie so it's a valuable test during this beta phase.

i'm hoping for a solution that doesn't require anything other than normal priority for the core application - similar audio applications and xt as a vst seem to work ok at normal priority. it may be that some thread within standalone, a critical section, needs to operate at a higher priority for example or, conversely, a gui thread may need to operate at a lower priority.

let's hope the results of sa4.exe and sa5.exe will have supplied more clues to jorgen as they've certainly had an effect on the application's efficiency and performance

[jorgen]

how was 1.25 compared to sa4?

jorgen

[ik_ik_ik]

how was 1.25 compared to sa4?

jorgen

well, firstly jorgen, thanks for 1.25!

1.25 is more glitchy than sa4 but better in general than 1.24 and the other betas by virtue of the dragging window outlines only.

glitches most often happen now when for example opening new windows, plugins especially, when resizing windows and when clicking on save, etc. most of those can be avoided by setting the buffer size to 4096 but that's huge

the cpu is not maxed out now with 1.25 like it was with sa5. a relief

looks like the priority is back to normal with 1.25 too which is a good thing. the gui freezing that you introduced in sa4 and sa5 is not there in 1.25.

this is all with the echo indigo and native asio drivers at buffer sizes of 512 or 1024 on an ext that uses around 30-35% cpu. a buffer size of 512 is very stable with most other apps even at quite high cpu load.

with the echo indigo via asio4all i can now run down to buffer sizes of 64 or 128 without too much trouble (glitches when saving) on the same ext happy to aim for a buffer size of 512 though as a rule.

maybe resign to stick to asio4all, wait for echo to one day update their asio drivers and see if that helps. it's a niggle that the native drivers don't work so well with standalone but are ok with other apps and energyxt as a vst. unless you have some ideas from the recent tests? but please let me know if you would rather call it a day since there seem to be few other people chipping in with similar problems.

resizing windows by outline only might be a nice idea anyway?

i'm finally getting a bunch of other more useful general ideas together for another post...

[ik_ik_ik]

i'm guessing that simart's post last night...
"Audio performance and latency--Standalone vs. Effect" [HERE] is essentially the same issues we're talking about here.

[ebinary]

maybe resign to stick to asio4all, wait for echo to one day update their asio drivers and see if that helps. it's a niggle that the native drivers don't work so well with standalone but are ok with other apps and energyxt as a vst. unless you have some ideas from the recent tests? but please let me know if you would rather call it a day since there seem to be few other people chipping in with similar problems.

Thanks for this tip on ASIO4ALL for Indigo. In sonar I finally gave up on the Idigo ASIO drivers and returned to WDM. But that wouldn't help me in XT.

Fortunately, I use a MOTU828mkIi most of the time.

Eric

[simart]

Somebody a couple posts back mentioned that I (unknowing) started a different thread on the same subject. Thanks for the suggestion to use ASIO4ALL instead of the Echo Indigo drivers. I'll give it a try.

-Art

[jens]

Jorgen,

as I have big problems with my Echo Mia I have made extensive tests:

Asio1 and asio2 do not make any real difference for me.
Standalone5 and 1.25 likewise. (Standalone 1-4 I haven't tried because the link is broken (I assume you deleted them))

My problems are the following:

- lots of crackles especially when I open windows or move windows or when I adjust vst's/vsti's and things like that. some vst's are far worse that others.
(Nonlinear is a prime example of the bad ones)
- Sometimes eXT completely hangs while I tweak a
'bad' vst, especially when the song is playing.

My cpu resourses are big enough.

I found three diffrent generic asio drivers on the web:

-AsioX

-Asio2ks

-Asio4all


Asio4all makes all the difference.
When I'm using it all my problems are gone -
I can use incredibly low latencies without a problem.
There are no crackles while opening and moving windows or tweaking vst's

There's only one problem: It doesn't recognize the digital-in of my Echo Mia

[ik_ik_ik]

I've also been back in the studio, finally, where i have an echo mia and concur with Jens above. Very similar problems to those with the Indigo card but clearly a very different hardware/software environment. What's common though is are the ASIO drivers.

So, I think it only adds to my feeling that there is some incompatability between Echo's native ASIO drivers and energyXT standalone. I only wish we knew what it was

cheers,

inigo

[ebinary]

So, I think it only adds to my feeling that there is some incompatability between Echo's native ASIO drivers and energyXT standalone. I only wish we knew what it was

cheers,

inigo

I can confirm that in Sonar, the Indigo ASIO drivers are worthless (require very high latency to avoid pops - use lots of CPU), so I use WDM. ASIO4ALL seems better on my first go round, though not perfet.

On the same system, MOTU828 mkii ASIO drivers are da bomb.

Eric