Advanced Gtk+ Sequencer

With 24 native threads the system's average load is less than 10 percent. This is a hardware configuration of 2 x Intel Xeon hexa-core processors with hyper-threading. Prior I was having an Intel i7 quad-core with hyper-threading causing an average load of between 30 and 40 percent.

By having 8 audio channel processing threads giving a total count of 18 threads. Note Gtk+ and JACK are known to provide their very own threads, too. This is a very basic stereo audio project:

• 1 x AgsTaskThread
• 1 x AgsThreadPool
• 1 x AgsPollingThread
• 1 x AgsAudioLoop
• 1 x AgsSoundcardThread
• 4 x AgsAudioThread
• 8 x AgsChannelThread
• 1 x AgsGuiThread

This lets me assume that we can gain much more power out of Linux kernel by doing even more parallel computing. There was an idea that may be a ressource is busy. The main goal is to do even more computing threads. And the work-station helps me doing my job more effective and to limit the problem. I can now do conclusions about physical threads and doing posix threads on Linux that relay on kernel threads.

For now I want to extend the threading model. As shown in figure below. Red lines illustrate AgsRecycling tree nested within AgsChannel. Currently only toplevel recycling are mapped to threads. This is going to be extended to the recursive nature of AgsRecycling. This improves especially performance of machines doing deep recursion like AgsMatrix and connected AgsSynth.

Advanced Gtk+ Sequencer does in near future use much more threads thus I have a need of work-station providing Error Correction Code for RAM this helps to debug certain concurrency problems like concurrent access to memory. If GSequencer crashes on machine a not having ECC but not on b doing ECC, this means you have got a concurrent access. ECC is very useful to set limits on faults.

Thank you LinuxFund.org for your support.