Threads and Priorities

[ik_ik_ik]

hi jorgen,

superb to get the recent updates, especially midi out haven't checked out the sync stuff yet though...

i'm still very keen to try some possibilities of asio.dll with different priorities as you mentioned above. the problems still exist in the most recent beta versions but i'm quite sure you have been busy adding the features

cheers,

inigo

[jean-mi]

Hey Pirhana you're a lucky guy : I have a Toshiba satelleite and experiment glitches as well when moving windows in XT SA (with RME multiface). It especially seems to happen when nothing has moved on the screen for a little time. I thout it was videomemory but it is dedicated here as well.
why is it that we shouldn't set priority level to realtime ? can someone explain me ?

[ebinary]

Hey Pirhana you're a lucky guy : I have a Toshiba satelleite and experiment glitches as well when moving windows in XT SA (with RME multiface). It especially seems to happen when nothing has moved on the screen for a little time. I thout it was videomemory but it is dedicated here as well.
why is it that we shouldn't set priority level to realtime ? can someone explain me ?

If you set realtime scheduling and encounter, say, a denormalization plug bug, your computer will stop responding entirely, windows will not be able to close files or swap memory, etc.

Depending on how XT is written, it may not be even be able to pre-empt its own thread to show GUI elements.

In short, it can be dangerous under normal and definately under exceptional conditions.

A more typical approach might be (for jorgen to) boost just the audio-engine thread's priority within XT, with programmatic tests to prevent hogging the CPU.

Eric

[jorgen]

ik_ik_ik, coming soon

jorgen

[jean-mi]

Ebinary, I didn't know ! That would mean the deep-blue-with-a-lot-of-esoteric-words-on-it... no way !
Thanks !

[jorgen]

No prob, blue-screen is on my todo-list

[ik_ik_ik]

ik_ik_ik, coming soon

fantastic...

No prob, blue-screen is on my todo-list

...and fantastic

[jorgen]

ok, I uploaded 2 new asio test dll's

http://www.xt-hq.com/beta/asiodlls.zip

unzip in same folder as asio.dll, then select asio_1 or asio_2 from the audio setup window.

let me know if it helps on the "moving window issue"

cheers
jorgen

[ik_ik_ik]

ok, I uploaded 2 new asio test dll's

http://www.xt-hq.com/beta/asiodlls.zip

unzip in same folder as asio.dll, then select asio_1 or asio_2 from the audio setup window.

let me know if it helps on the "moving window issue"

cheers
jorgen

thanks jorgen, i'll check those asap and let you know how i get on.

inigo

[xian]

<edit>what was I thinking?</edit>

[DarkStar]

<edit>what was I thinking?</edit>

beats me, probably in 4/4 time

[ik_ik_ik]

ok, I uploaded 2 new asio test dll's

http://www.xt-hq.com/beta/asiodlls.zip

unzip in same folder as asio.dll, then select asio_1 or asio_2 from the audio setup window.

let me know if it helps on the "moving window issue"

cheers
jorgen

hi jorgen,

i spent some time last night testing the two DLLs but alas can't report any real change.

if anything asio_1.dll may have made matters worse - it seemed that as windows were moved around there was more of a trail of ghost windows. hope that makes sense.

realistically though i think there was very little difference between these test DLLs and the standard asio.dll

i tried a number of ways to switch between them and also made sure to restart the application between different DLLs. logically no need but we all know computers are far from logical

i wonder if anyone else had any success? and i wonder what xian was thinking...

do you have some other ideas?

it looked to me like the biggest clues have been the fact that energyxt perfoms ok when used as a vst inside another host and secondly that standalone seems to work ok when forced to realtime priority via task manager. perhaps standalone is just not "rude" enough?

cheers,

inigo

[jorgen]

k_ik_ik, ok thanks. Now try this test version of sa instead:

http://www.xt-hq.com/beta/sa1.zip

just unzip sa1.exe and run it from the same folder as your standalone.exe

let me know how it works

cheers
jorgen

[plastique]

if i may ... i tried the new sa1 and while using the mousewheel in the midipart an error occurs:
"0001D8B4".
i tested this because i still have these glitchy noises when using the mousewheel in the midiparts (in other ext versions as well ,so it might just be this particular computer setup (usb mouse,other asio driver etc.), while on another computer it seems to be fine).

this new sa1 not only produced noise but threw this error which is kind of a progress in some way IMO.

[ik_ik_ik]

k_ik_ik, ok thanks. Now try this test version of sa instead:

http://www.xt-hq.com/beta/sa1.zip

just unzip sa1.exe and run it from the same folder as your standalone.exe

let me know how it works

cheers
jorgen

hi jorgen,

the new sa1.exe is a vast improvement - good news i think thanks for your efforts!

i noticed it now runs at high priority.

i also get the exception 0001D8B4 that plastique mentioned if i scroll the mousewheel whilst over the midipart and can confirm that didn't happen previously.

there are still glitches with sa1.exe but they are much less frequent so this is a good sign. the glitches seem to occur most of all when the window being dragged is over a window with active elements e.g. mixer level meters. it's at that point that the most obvious "ghosting" of the dragged window occurs too. that behaviour has been consistent across all version of standalone.

increasing the buffer size to 2048 helped a little but this is a lot higher than i'd expect to be able to run - 512 should realistically be possible.

getting close