Threads and Priorities

[ik_ik_ik]

Hi Jorgen,

Following on from the "Click and Pops movin' comps' windows" thread...

Basically a problem with zipper noise/glitches when moving windows around or using other applications. Happens in energyXT sa when using an Echo Indigo (even at high latency) but not when using ASIO4ALL (even at very low latency). The problem is made worse when using a USB mouse. The main energyXT windows seems to behave better than others.

I've done a little more research at the hardware level and discovered that Ricoh cardbus controllers have problems with PCI bursting which in part explains the problems I've experienced when using the Echo Indigo card in my Samsung X10 laptop (which unfortunately uses the Ricoh controller - grrr, there's always one achilles' heel you can't find until a few months later!). This may apply to others that have mentioned similar problems in the past.

However since other applications do seem to be OK I've also delved a little more into the software level...

Boosting energyXT's base priority up to realtime via Task Manager once it's running appears to solve all the problems with zipper noise and glitches I've experienced when moving windows around. Priorities of abovenormal and high did not have any noticable effect. In general running as realtime is not a good idea but it was more a case of trying it to determine whether there was a software rather than hardware solution possible.

energyXT appears unusually to explicitly set it's priority at run time as it overrides the priority set by running the application via the start command e.g. "start /realtime standalone.exe". no bad thing.

So the question is really is it possible that the audio engine's thread priority could be made to be higher/as high as possible (assuming it's a separate thread) as perhaps that's at the root of the glitches? Something like that would probably help in many cases I guess.

Cheers,

Inigo

[jorgen]

Hi, could you try this test version of sa.

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

unzip in same folder as standlaone.exe

I changed the code a bit, and it would be interesting to see if it made any change...

I am not able to reproduce this, so I just have to keep trying different bits code

jorgen

[ik_ik_ik]

Hi Jorgen,

Thanks for that! I've tried the test version. It seems to behave in pretty much the same way. It also responds equally well to being assigned realtime priority after it has loaded - I've since found that even that causes glitches in projects that use say 50-60% cpu or more.

It's sounding likely to be a battle to find a way for the software to not be affected by an unfortunate hardware conflict.

Inigo

[ik_ik_ik]

Hi Jorgen,

Another quick update. I tried to run XT as a VSTi for comparision to standalone - using Art Teknika Console as a host. When it runs this way then I don't experience any of the glitching problems (even in heavy cpu projects) so it does seem to be down to some specific way the standalone version operates.

I'm keen to use standalone in the hope that it will be a stable core to live performance alongside turntables.

Once sync to host is all there i.e. XT picks up its external host's sync information as well as passing its own sync information to internal objects then many doors will open to make using the VST version very interesting

Hope this is all of some help.

Inigo

[tjvigil66]

Hi Jorgen,

Following on from the "Click and Pops movin' comps' windows" thread...

Basically a problem with zipper noise/glitches when moving windows around or using other applications. Happens in energyXT sa when using an Echo Indigo (even at high latency) but not when using ASIO4ALL (even at very low latency). The problem is made worse when using a USB mouse. The main energyXT windows seems to behave better than others.

...

Cheers,

Inigo

I have had no problems with my Echo Indigo card. For what it's worth, I have the IO version of the card. I don't know if that makes a difference, but the zipper noise is obviously not caused by the Echo card itself. My guess is that it is more due to the way video memory is handled in laptops.

[ik_ik_ik]

I have had no problems with my Echo Indigo card. For what it's worth, I have the IO version of the card. I don't know if that makes a difference, but the zipper noise is obviously not caused by the Echo card itself. My guess is that it is more due to the way video memory is handled in laptops.

hi piranha,

i doubt there's much between any of the indigo range as far as this problem goes. i'd agree it's unlikely to be the indigo but i think it's also unlikely to be video memory in this case (dedicated rather than system shared).

it's fairly likely related to the pcmcia controller chip and the way pci burst activity (generally due to graphics activity but also in this case usb mouse activity) is interacting with the indigo. out of interest do you know what your pcmcia contoller chip is?

this interaction though is presumably taking effect at the software level too as i've now established that XT as a VST within another host works flawlesslessly (even at 90% cpu) as compared to standalone and also other applications work fine. that's what leads me to believe there is something that hopefully jorgen might be able to do within XT standalone.

cheers,

inigo

[sluggo]

I've had the same problem with moving windows and zipper noises with the standalone version. I have an Echo Mia card. Unfortunately I haven't had the time to test this very much, but hopefully I can delve into this soon and report back.

cheers

[tjvigil66]

...

it's fairly likely related to the pcmcia controller chip and the way pci burst activity (generally due to graphics activity but also in this case usb mouse activity) is interacting with the indigo. out of interest do you know what your pcmcia contoller chip is?

cheers,

inigo

Ahhhhh. That could very well be it. I have a Toshiba Sattelite notebook, but I don't know what pcmcia controller chip is in there. Also, I don't use a USB mouse... but I do use my ReMote25 via USB.

[sluggo]

I've installed the newest beta, and I still get audio glitches etc when moving windows with the standalone version. The plugin versions of xt work fine.

[ik_ik_ik]

piranha,

chances are you've got a Texes Instruments controller chip - seems like a lot of the Toshibas do. Lucky for some!

sluggo,

at least i'm not alone although i guess it's unlikely to be pcmcia controller related in your case. as an aside i do have a mia card in my studio pc though and that was much better once i'd discovered that in fact the best pci slot to use on my motherboard was in fact the first - commonly understood to be the the worst place as it often shares with the agp slot but *not* on the asus cusl2 board where the first slot is actually dedicated and can also be assigned to be high priority in the bios. handy. worth checking yours is in the right slot for the job?

cheers,

inigo

[ik_ik_ik]

hi jorgen,

just to keep you in on the loop. some results of potential interest today...

previously running my laptop's internal sound via ASIO4ALL has proven to be very stable down to a buffer size of 512 (13ms) - lower than that there are dropouts associated with system activity as i'd expect.

a buffer size of 512 always seems a good mix of stability and in my experience.

today i thought i'd try running the echo indigo via ASIO4ALL and to my suprise could also run it down to a buffer size of 512 (13ms) without any of the glitches that are present when using the indigo via its native ASIO drivers (at any buffer size). at lower latencies, as expected, the same dropouts occur.

that, to me at least, indicates a few things...

- there may be a hardware conflict issue as noted previously but is perhaps a red herring as it appears not to affect many cases of using the indigo - i.e. it works very well with many other applications with its native asio drivers and it also works very well within energyxt via the ASIO4ALL drivers.

- since the indigo works very well with other applications via the native asio drivers and within energyxt via ASIO4ALL there might be an issue between the native echo asio drivers and energyxt's implementation of them? this might extend to other asio drivers that perhaps behave in non-standard ways or report non-standard information to the application?

- finally that ASIO4ALL is very useful

there does seem to be some confusion with how energyxt populates the buffer size options - the values seem to be quite arbitrary and oddly they seem to change as the result of a selection. this might just be related to the problem somehow?

have you had any thoughts?

hope this helps.

cheers,

inigo

[tjvigil66]

inigo,

My laptop has a power/energy feature that lets you set how it runs if it is plugged in, running from battery, running a DVD, etc.

Does yours have this type of control? If so, how is yours set up to run?

Do any settings work better than others or does it have no effect on how things run?

[ik_ik_ik]

inigo,

My laptop has a power/energy feature that lets you set how it runs if it is plugged in, running from battery, running a DVD, etc.

Does yours have this type of control? If so, how is yours set up to run?

Do any settings work better than others or does it have no effect on how things run?

hi pirhana,

my samsung x10 is a centrino and i've avoided the samsung/windows power management as much as possible and am using speedswitch xp...
http://www.diefer.de/speedswitchxp/index.html

speedswitch is a very useful tool for anyone using a centrino with xp (in xp microsoft removed some quite important power management parameters). it allows you to accurately control a centrino independently for mains and battery - e.g. you can force cpu to full throttle when on battery or mains, etc. it's also possible to tweak fairly low level power management settings such as sleep states, idle thresholds, etc. although that's largely uneccessary.

the glitching and audio performance are as expected less severe and superior when the cpu is full throttle, which is how i run it when working with audio applications, but the problems with the indigo and energyxt persist.

the problems are similar when using standard windows power management settings.

also, toggling processor scheduling between programs and background services (which i have it set to usually for asio performance) makes little difference.

inigo

[jorgen]

ik_ik_ik, energyXT doesn't know anyting about audio drivers (because of cross platform design), it uses the ASIO.dll for audio (coded in VC6). Well, I'm sure you know already anyway, I could of course make a few ASIO.dll's for testing with different priorities and see how it works, and if successfull I may add a "priority" in audio driver setup...

So if you have the time to test it for me (I'm not able to reproduce this on my laptop ), I will post a few links...

jorgen

[ik_ik_ik]

hi jorgen,

i'm more than happy to help out with some testing.

cheers,

inigo