On 12/03/2016 01:50 PM, termtech wrote:
> On Saturday, December 3, 2016 1:20:09 PM EST David Klann wrote:
>> 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:
> " [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.
>
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.
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
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
