On 11/01/2016 11:45 PM, termtech wrote:
> On Tuesday, November 1, 2016 2:36:21 PM EDT Chris Caudle wrote:
...
> Yesterday I read somewhere, and was reminded, that audio
> processing is a 'serial' task that may not benefit well from
> n-core CPUs and therefore one should choose a CPU with the
> highest possible clock and try to run with fewer cores.
At least on Linux this is not necessarily true. It all depends on the
software you run and what it can do. If it is single threaded yes,
higher clock speed would help. If not, multiple cores can help. I
usually use all cores for the stuff I do.
> I must mention something that adds mud, but clears it up more:
>
> When I try the on-board sound, or an old spare PCI SoundBlaster Live!,
> the sound is actually OK ;-)
Ah... something related to the pci bus then?
Looking at the waveform it looks like the glitches happen every 256
samples (more or less). And the glitch itself seems to be around (more
or less) 8 samples wide at its widest. Then it gets narrower and
narrower towards the end, then it is just one sample wide and finally it
disappears...
Very weird...
> I've yet to verify that statement for this replacement PC, but it's true for
> the unit it replaced. That test did not bode well for this Delta1010 card.
What motherboard does the pc have?
On linux the output of dmidecode would have that information. Does it
have more than one PCI slot? I presume you tried on all of them if it
has more than one, right?
> For that reason I may chalk this up to just a weird combination
> of this older PCI sound card (PCI rev 2.0 or 2.1 I think) and this
> new-fangled MB and CPU.
That could very well be the problem. I have had problems with PCI RME
soundcards not being happy with a newer faster motherboard and processor
(they worked fine in older hardware). Progress, I guess. Never managed
to fix it or really diagnose it, sorry.
Now as to why the problem stops when you disable two cpus? Wow. How
about disabling just one? I can only think of some hardware interrupt
routing problem as a possible cause. But a problem that comes and goes?
In Linux if you can see this (as root):
cat /sys/devices/system/cpu/cpu1/online
You could disable just one cpu while the system is running (you should
have four):
For example, running as root this will disable your last cpu:
echo 0 > cat /sys/devices/system/cpu/cpu3/online
This should re-enable it:
echo 1 > cat /sys/devices/system/cpu/cpu3/online
(not that this would be a fix, just curious)
You could also see which cpu is handling the soundcard interrupts if you
check out this:
cat /proc/interrupts
Each column is one cpu, each row is one interrupt source. The one
corresponding to your soundcard should be incrementing...
> Maybe there's hope that a driver tweak could help?
> The Windows driver hasn't been updated in four years.
> Maybe it and the Linux driver share the same problem - needing an update?
Are you running a reasonably recent kernel? "uname -r" would tell you
what you are booting. If both Win* and Linux have the same problem that
would seem to point to hardware. Not good news.
> But then, this MB and the other one are from around 2009/2010 or so.
> If not then it's likely just this hardware combo.
> Heck it could still be /this/ specific unit.
> It would be nice to get some verification from similar users...
>
> It's just so weird. A brutal stupid ironic introduction to n-core CPUs.
> Happy I can play keys now though. Persistence pays. No new card!
> And at least my *guitar* doesn't need a freakin' CPU, just my brain :-)
:-(
Good luck!
-- Fernando
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-user
Received on Tue Nov 29 12:15:01 2016
This archive was generated by hypermail 2.1.8 : Tue Nov 29 2016 - 12:15:01 EET