25 Jul
2014
25 Jul
'14
6:50 p.m.
On Jul 24, 2014, at 5:20 PM, Len Ovens
<len(a)ovenwerks.net> wrote:
Interesting. Thnks for the info.
My work horse machine is an i5. It is a beefy processor IMHO. I have zero issues with how
it performs. It will run rock solid all day at 64/2, running kxstudio OOTB. I may just
need to dig it out o storage and set it up instead of messing around with trying to
squeeze droplets of performance out older gear. I run the Echo Audiofire 12 in it which
also performs quite well.
Thank you all for your time.
Regards
R
On Thu, 24 Jul 2014, Russell Hanaghan wrote:
Wow! Pci(e)? USB? Fw? What IZ interface? That's a lot better than I'm getting.
What is your rig/desktop?
I was not long ago running an old P4 at 2.4G with 2.5Gram I could get 2/16 on that too,
but it didn't take much load to mess things up.
I just got myself an i5 (i5 has no hyperhtreading, i7 does... couldn't see any other
differences) 3.2G and 8Gram.
I am using an older ice1712 based delta66 PCI audio card. I chose my new mother board for
maximum number of PCI slots as I use an old ens1370 audio card as well just for MIDI. Own
irqs, CPU to performance, I set my rtirq for my main sound card then any other snd
(snd_ice1712 snd) I do the same on my laptop where I use a USB IF. I have found that USB3
is the only USB that is not shared so I do "usb3 snd usb" for order.
Boost is off in BIOS... Thats about it. With the old P4 it even mattered which order my
PCI cards were in as the D66 seemed to work better if it had a higher irq than the
ensoniq.
I hear you... I look briefly thru those to look
for snares such as irq
piling. The bios in this old Vaio is about a useful as a
chocolate teapot! But I set CPU to performance in user spc (I think...) nowhere to deal
with hyper. I don't think this dual core has it actually.
dmesg or syslog should tell you near the begining of the boot logging if you have
hyperthreading or not. If you do it will look like you have 4 cores instead of two. Turn
off cores 1 and 3 on the kernel command line in GRUB.
> The second thing to remember is that
multicore CPUs have changed the
way lowlatency can ....
Could I trouble you to elaborate on last paragraph a little??
With a single core, audio processing has to be able to have access to that core on time
all the time. WIth multi-cores, The OS can be set to run most of it's stuff on one
core and the audio RT stuff on the other(s). This is making true real time kernels less
important than they were. The audio world has yet to really put this into practice, but it
is possible and I think it is not long till it gets to be the normal way to do things.
Servers already often have memory that is on a per CPU basis and I think this will work
it's way into desktops as well. Effectively, it starts to become like having two (or
more) closely coupled computers.
This is not a comprehensive description at all :) just enough to point you in the right
direction if you want to learn enough to implement it on your own machine. (I am not there
here either)
Even with no fancy set up, multicore CPUs seem to make a difference with audio stability.
(maybe it is just that this is so much faster than what I had before...
--
Len Ovens
www.ovenwerks.net