7 Dec
2016
7 Dec
'16
9:43 p.m.
On Dec 7, 2016 06:48, termtech <termtech(a)rogers.com> wrote:
On Wednesday, December 7, 2016 7:34:25 AM EST David Klann wrote:
Well, I have 2 PCs I do audio on. One has 4-core AMD Phenom II (no hyperthreading). Other
has Intel i7 (4 cores + hyperthreading). Have never tweaked anything like what you're
talking about and have never had any such problem as you had.
I do not have Pulseaudio installed on either of them.
My final guess at root of problem: hardware issue with CPU itself. Maybe some
manufacturing defect that only manifests when all cores are in use?
Glad you found a solution!
David W. Jones
gnome(a)hawaii.rr.com
authenticity, honesty, community
http://dancingtreefrog.com
On 12/03/2016 01:50 PM, termtech wrote:
Ah thanks, I was looking for something like taskset.
I wondered if the entire audio chain, from driver to application,
should somehow be set to one CPU even if all four are enabled.
Please let us know how it works out for you.
I am very late to this multi-core party. It's my first such PC.
I am sure this episode has been repeated before in other threads.
It's hard to dig through the confusion and misinformation.
Even though I did research these CPUs before buying, I didn't
expect it would affect things in this manner.
Tim.
> Thank you everyone who weighed in on this, and especially Paul for
> pointing out that it cannot be an issue introduced by JACK.
>
> Best regards,
>
> ~David Klann On Saturday, December 3, 2016 1:20:09 PM EST
David Klann wrote:
Hi Tim!
Thanks for this tip! I probably never would have considered this even
though it was a vague, nagging thought in the back of my head.
Disabling three of the four cores (or hyperthreads?) on the CPU fixed
the problem for us!
Specifically (and to tweak your command set), I placed the following in
/etc/rc.local to ensure the CPU disabling survives a reboot:
<code>
for c in 1 2 3; do echo 0 > /sys/devices/system/cpu/cpu${c}/online; done
</code>
In reading the "Crackles in audio..." thread, I am curious to know why
this happens with some CPUs and not with others. My understanding is
that this is fundamentally a timing issue between processes that are
running on different CPUs (or cores). So, while it's not specifically a
JACK issue, if the jackd process is running on CPU0 and the audacity
process is running on CPU3 then a timing error may be introduced between
those two CPU's. Is that a reasonable summary of the effect?
And for my next trick, I will experiment with the taskset(1) command to
set processor affinity for the audio processes. Maybe we can leave all
four CPU's enabled and still avoid the "left-right channel skew" problem.
Greetings,
Long-time Linux user, and relatively new JACK user here. I have built
...
Hello, this might be a long shot, but maybe not.
You mentioned it did this when Jack was disabled,
so it seems Jack is not the problem.
Look for the LAU thread on Wednesday titled:
"[LAU] [SOLVED] Crackles in audio, drifting intermittent noise etc."
I was having very strange phasing problems, although I didn't notice
from channel to channel but I wasn't really listening for that.
I knew it was hardware related, only that could cause it.
My ONLY solution was changing the number of enabled CPU cores,
either through my BIOS or through Linux commands such as:
echo 0| sudo tee /sys/devices/system/cpu/cpu3/online
cat /sys/devices/system/cpu/cpu3/online
I found that I must run with just ONE core for the most stability.
(I had posted that I found TWO cores were OK but actually
further test revealed it was not OK.)
So try:
echo 0| sudo tee /sys/devices/system/cpu/cpu1/online
echo 0| sudo tee /sys/devices/system/cpu/cpu2/online
echo 0| sudo tee /sys/devices/system/cpu/cpu3/online
cpu0 will always be online.
Tim.