hyperthreading and sonar

Just guessing, but I think you put too much onus on Sonar's developers. There are chipset drivers that are awfully important in this picture. [Feel free to correct this assumption] Sonar works above the hardware abstraction layer. As such, the best it can do is efficiently divide work among worker threads. These threads are then queued to the available processors (not by Sonar) and the returned work is then aggregated and assembled into a result. Each plug-in does this on at least one thread and may spin up more threads. I imagine that most DLLs will load in the same process space as Sonar (unless some heavy lifting is done to pipe the requests and results between processes (I'd avoid this if I could)). One of the advantages of separate process spaces is memory protection. The cost of spinning up a process space is large (measured in hundredths of a second at least) where spinning up threads is much much faster. I've done a programming presentation at a Microsoft Code Camp demoing the cost of spinning up processes to do work v. threads. The difference was huge when you need to process each thread in less than .5 seconds. The cost of spinning up the process and closing it down was more than the cost of all the work the process was doing in some cases. Threads spin up with substantially less cost. So, most of the time, Sonar spins worker threads to do it's bit work inside the one large process space. This is where it gets muddy when you have a plug in that doesn't play nicely with others. If the plug-in doesn't correctly de-allocate memory, then the available memory for the entire process space is diminished.

The 256 thread limit is for mobile devices only...
http://msdn.microsoft.com/en-us/library/system.threading.threadpool.setmaxthreads.aspx

The minimum max thread value that can be set on a thread pool is the count of processors on the PC, but you don't have to use all the available threads in the pool. This is interesting because if you know that another process space has a thread pool that is using half the processing power, and you want to program both processes to limit to half the processors, then you would have to manually control the number of worker threads you spin.

See this link for a discussion of threads v. processes
http://archives.postgresql.org/pgsql-general/2004-10/msg01346.php

For more info on Windows and threading, see this...
http://blogs.msdn.com/oldnewthing/archive/2005/07/29/444912.aspx

Of course if you go 64 bit, things get more exciting...

All of this is way off the subject. You asked if Sonar did what it needs to do to take advantage of hyper threaded processors. The answer is most definitely. Sonar is way ahead of the curve in taking advantage of spun worker threads scaled appropriately to the hardware available.

Check out this interesting demo on intel nehalem (different from current intel core architecture)...
Go here
http://www.intel.com/technology/architecture-silicon/next-gen/?iid=SEARCH
And check out the video about half way down the page..

Also, try this...
http://www.intel.com/technology/product/demos/turboboost/demo.htm?iid=tech_tb+demo

Something this demo shows but doesn't describe is the management of two threads merged to a core at the processor level. This is new in the way it will (is) be implemented. Also, the processors will start to detect loop and skip work steps where safe assumptions can be made to return results with less work done, creating the appearance of doing more work in the same time.

Nehalem chips were released in the US on 11/17/2008
http://en.wikipedia.org/wiki/Intel_Nehalem

Link to a couple of Dells that have this processor
http://search.dell.com/results.aspx?s=gen&c=us&l=en&cs=&k=i7&cat=all

Most of what Sonar does is spin worker threads based on a best estimate of the capacity of the onboard hardware. I believe that Sonar also takes adavantage of under utilized memory on GPUs where available (and may perhaps work the GPU for worker threads where it appears available -- this is a guess).
http://www.cakewalk.com/Vista/default.asp (see the section about offloading processing from the CPU to the GPU, I'm presuming they are not just talking about video processing).

So, get good hardware with good drivers and you'll get more bang for your buck.

G

Late addition: I read up on VST SDKs (software developer kits). I read this...
http://www.gersic.com/vstsdk/
Check the Examples link for those who can read a little code (you don't have to understand everything to get some value out of this).

For one, I learned that the VST DLL just reports to the UI thread that it's UI segment is dirty and should be repainted, rather than trying to handle any painting itself. This is important because it means you don't have a number of different threads trying to repaint different screen segments simultaneously. So, this probably helps with the XRay feature in Sonar. Because the Sonar UI Thread is in control, it can know that the UI for a particular thread should have a low opacity value (transparency rating) and consequently it will paint it that way. The plugin doesn't know this, and consequently couldn't paint the area properly. I just thought it was interesting. If the Plugins were responsible for their own repaints, then the XRay thing probably either wouldn't have worked or it would have had to be implemented across all VSTs. Each VST would have been responsible for it's own XRay support. This seems to be an example of fortunate upfront design that paid off.

I know sonar used to have a lot of problems with hyperthreading technology.

No it didn't. I've used it for years with HT.

ORIGINAL: ba_midi


From what I've read over time, many users seemed to need to turn off HT at the BIOS level for things to go smoothly. Wonder why that was?

Because a lot of plugins didn't play well with HT and the way it was implemented in P4s; NI's for example. That's why NI still recommends turning off HT on P4s with their products, especially if you're also using them as standalone apps. Read the blurb about HT in their tuning tips for Vista:

http://www.native-instruments.com/knowledge/questions/354/Tuning+Tips+for+Windows+Vista+for+audio+processing

ew

Hey Ba_Midi,

I found this...
http://searchservervirtualization.techtarget.com/expert/KnowledgebaseAnswer/0,289625,sid94_gci1211979,00.html

So, hyper threading problems we are talking about pre date the use of the MultiMedia Class Scheduler Service model of device drivers dealing in real time streams (like audio)...
http://msdn.microsoft.com/en-us/library/ms684247.aspx
or a developers thread
http://social.msdn.microsoft.com/forums/en-US/windowspro-audiodevelopment/thread/b545f1ac-213f-4e61-b7fa-b61df9823b73/

So, my guess is that in some cases trying to slip in work for thread A in the under utilized space of thread B then caused thread B to return more slowly. If thread A could have waited for the completion of thread B then the real time app would have been better off.

Microsoft is trying to deal with thread priority in Vista with MMCSS model in which the thread that really shouldn't be interupted will not be, but other threads (perhaps a timer thread of some Windows service that is waiting on a poll cycle) can be interrupted. So, for the lower priority thread, the hyperthreading interruption would occur, but on the short burst from the higher priority thread, this thread would be allowed to under use the core without injecting work.

Does this sound valid?

I found this...
"WASAPI Shared mode good enough for PRO audio?"
http://channel9.msdn.com/Search/?Term=mmcss

Which led me to this...
"Exclusive-Mode Streams"
http://msdn.microsoft.com/en-us/library/bb614507(VS.85).aspx
"Windows Vista has several features to support applications that require low-latency audio streams. As discussed in User-Mode Audio Components, applications that perform time-critical operations can call the Multimedia Class Scheduler Service (MMCSS) functions to increase thread priority without denying CPU resources to lower-priority applications. In addition, the IAudioClient::Initialize method supports an AUDCLNT_STREAMFLAGS_EVENTCALLBACK flag that enables an application's buffer-servicing thread to schedule its execution to occur when a new buffer becomes available from the audio device. By using these features, an application thread can reduce uncertainty about when it will execute, thereby decreasing the risk of glitches in a low-latency audio stream."

"In addition, USB audio devices rely on system software to transport data between application buffers and hardware buffers. To improve the performance of exclusive-mode applications that connect to audio devices that rely on the system for data transport, WASAPI automatically increases the priority of the system threads that transfer data between the applications and the hardware. WASAPI uses MMCSS to increase the thread priority."

Reducing unnecessary animation makes sense to me (although this probably will not have much of an impact if you aren't opening and closing windows on top of Sonar. In other words, if you just open Sonar and use it, disabling windows animation (the way minimizing and maximizing windows is animated on the screen) shouldn't make a difference.

With Aero on its not going to have much impact to leave this on fully. Its all done via the GPU. If you don't have Aero on then it might be better to do as they say. However, as confirmed by CW's people here on some of my threads dealing with Aero, it does help to have Aero on. Now you do have to have the right system and the right graphics card for this all to work seamlessly but it does.

Excellent post, gswitz!

Being Vista Compliant now is exciting in part because of what is coming. This is a major OS adjustment that will serve to improve performance of applications like Sonar. Vista is a seed that will grow over the years to come. As we can start using MMCSS we should see real bang that we could not get past otherwise.

According to this link, Asio4All v 2.9 out in November integrates WaveRT...
http://acoustica.com/kb/Get-Incredible-Low-Latency-Audio-With-Vista-And-The-Latest-ASIO4ALL-Drivers_1100.html
"You'll need to use the ASIO4All drivers in order to take advantage of WaveRT. The latest ASIO4ALL drivers utilize the new Vista WaveRT real time audio drivers which boast incredibly low latencies! We are calculating around 5 milliseconds on just a standard run of the mill sound card!"

I think drivers from device manufacturers may well take advantage of WaveRT now, but FYI about the Asio4All thing...

Back to Video

"Vista Audio Subsystem was abstracted to User Mode. The Sonar audio engine is user mode (doesn't use Vista's audio engine) -- routing audio through various complex topologies -- Kernel Streaming, wave rt, ASIO, MME, ... only time we touch the Kernel is when it's [sound is] actually getting out of the system... Everything in the system is in User mode. Sonar will not crash Vista, but the driver can crash Vista. We added Crash Protection to Sonar... [They created a plug in to crash Sonar.] "

Link on WaveRT
http://msdn.microsoft.com/en-us/library/aa474703.aspx

A Wave Port Driver for Real-Time Audio Streaming
http://www.microsoft.com/whdc/device/audio/wavertport.mspx
"The WaveRT port driver supports audio applications that reduce the latency of audio streams by using the real-time scheduling support that is available in Windows Vista and later. Hardware innovations, such as the low-latency isochronous transfer modes of PCI Express devices, complement real-time scheduling.

To take advantage of these improvements, an audio device should be able to play or capture audio data with little or no intervention by the driver software. If designed properly, the audio hardware should require no help from the driver from the time that the audio stream enters the run state until it later exits that state. The result is low-latency audio that consumes few host-CPU cycles and is free of timing glitches."

I don't know to what extent current interface devices are already designed to be effectively compliant. For example my $50 Line6 Gearbox... does it meet this requirement? I've got a hunch here...

Back to Video info...

WER [crash dumps through Watson Error Reporting (Windows 2000 and later)] is something Sonar subscribes to so it can get crash dumps from users who submit them to Microsoft. Microsoft guy talks about new crash diagnostics features that allow you to bring back an app in the same state as it was in pre-crash. Noel said he was interested and would read about it.

Noel reports that the Microsoft documentation on WaveRT and MMCSS is lacking.

Requirement to use Microsoft Installer was a bummer for being Windows Vista compliant.

Hi G,

IIRC, WaveRT can only support audio devices on a system bus (e.g. PCI, PCI-Express).
WaveRT is not applicable to USB or Firewire (IEEE-1394) audio interfaces - which a lot of people use.

Your Gearbox is USB-based...

Regards,

Jim

Thanks for the good info guys!

Perhaps the all-intel-ness of it has something to do with it...

That's very possible. That's one reason I only use Intel processors.