fantastic! thanks for your report. Still not sure whether to update the mobo thou. I have a ASUS that dates from way back 2008 (!) with Intel COre 2 Duo E8400, 3 GHz. Can someone tell me if a 4 core Intel CPU will be significantly faster when it comes to audio processing? -- View this message in context: http://linux-audio.4202.n7.nabble.com/Re-Updated-to-kernel-4-4-1-missing-mo… Sent from the linux-audio-user mailing list archive at Nabble.com.

It is good to know that there is still a modern motherboard out there with PCI for my Delta1010 (not LT). I have no xruns at 1.3 latency with my Dual Core CPU. I find it strange that because my system is 8 years old i still have doubts if a new system with Quad Core will be a big improvement... -- View this message in context: http://linux-audio.4202.n7.nabble.com/Re-Updated-to-kernel-4-4-1-missing-mo… Sent from the linux-audio-user mailing list archive at Nabble.com.

On Fri, 19 Feb 2016, Menno wrote: faster is not really the right measure I think. I have an i5 4 core cpu and my son has a 2 core cpu simmilar to yours (but newer). From a desktop perspective and in terms of "snappy feel" there is really not much difference. Mind you he uses his for mostly watch youtube stuff where GPU makes the most difference anyway. I do notice that compiling a program is faster on the i5, but that is hardly a measure for audio use. Raw speed does not give a good measure of lowlatency, it seems the more tricks the cpu uses to improve throughput, the higher the latency as well. Latency depends on being able to meet schedules, tricks like "Boost", "Hyperthreading" and their AMD counter parts will affect the OS ability to meet short schedules. This is why I chose the i5 over the i7. On my atom based netbook, I found that turning HT off and setting my cpu to run at 800Mhz gave better audio (no xruns) at lower latency than letting the cpu run faster in ondemand (variable from 800 - 1600mhz). In theory, ondemand should not make any difference, the speed switching is very quick. However, any loop time based on cpu clock will go over time if the cpu speed suddenly lowers during that loop. (that is the only thing I can think of that gives xruns right when the cpu speed drops) "Boost" is just more of the same speed change issues. With audio use, the whole measure is if the DSP does not run out of time in one period. That is, if jack is set to 32/2, is all the DSP finished in less than 1.33ms. If 4 cores is better than two depends on the DSP being done. For example in a use case where there is incoming MIDI that runs a softsynth to create dirrect sound for stage use, all the processing is serial and so would all have to be done on one core anyway. (overly simplified BTW) More complex setups might very well be able to split DSP over more cores. Are you using Jack1 or jack2? Jack1 is single core, Jack2 tries to spread the load over cores. An audio application may be able to spread it's own processing over cores beyond what jack does too. At least the GUI stuff does not need to be a part of the DSP thread. So the answer is... it depends. ;) -- Len Ovens www.ovenwerks.net

On Sat, 20 Feb 2016, Menno wrote: The question then is what is "real time" for you? What latency are you running now? If you take a low cpu synth what is the lowest latency you can run at without xruns (what is the lowest latency you can run jackd for some hours at doing nothing with no xruns)? Are you already using a lowlatency or real time kernel? As I said before, speed is generally not the question though speed can help. Certainly more speed in the basic processor itself will help provided the cpu is not using tricks to acheive throughput that damage latency. Also stay away from MB where the main claim to fame is low power use as you will want to turn almost any power saving stuff off for reliable low latency audio use anyway. Some people are able to work with as high as jackd running 256/2 for real time use, I need 128/2 minimum and prefer at least 64/2. This not zero latency but small latency (there is no such thing as zero latency even with all analog gear. The air adds latency at least which our brain just deals with). So far you have not told us what latency you use now or how low you have tried to run. I have been able to do low latency audio (guitarix at 64/2) with no xruns on a single core atom running at 1.5Ghz. (disclaimer, there were some of the default presets that did cause xruns, but most not) Your system should be able to do better. If you can run your current setup with less processing requirements at a reasonable latency (internel intel HDA may not be able to go below 64/3 for latency anyway), then adding more processing power may help. If your workflow allows the use of multi-cores even better. Use jackd2 should help some. So, what are you doing now? What interface? how low can you run jack? What sample rate (48k should be fine)? Also, I don't know C sound or Blue well, is there buffer size adjustments inside these applications as well? It would be nice if you left the questions you are replying to in your answering email as well. -- Len Ovens www.ovenwerks.net