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. 
7 Dec
7 Dec
9:52 p.m.
New subject: [SOLVED] "Skewed" Audio with JACK
On Wednesday, December 7, 2016 10:43:22 AM EST David Jones wrote:
On Dec 7, 2016 06:48, termtech
<termtech(a)rogers.com> wrote:
It appears to be something related to certain (older?) PCI audio cards.
Although, I think Len said he's running a similar card as mine
and hasn't seen any problems.
An older SBLive! PCI card appeared to work fine. Maybe I should test again...
Tim.
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? 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:
> 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.
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.
Glad you found a solution!
David W. Jones
gnome(a)hawaii.rr.com
authenticity, honesty, community
http://dancingtreefrog.com
10:26 p.m.
New subject: [SOLVED] "Skewed" Audio with JACK
On Wed, 07 Dec 2016 15:52:15 -0500
termtech <termtech(a)rogers.com> wrote:
On Wednesday, December 7, 2016 10:43:22 AM EST David
Jones wrote:
This is most odd. I'm fortunate to have access to several quite different
multicore machines. (2 and 4 core), one working with an elderly 2496, the
others using a KA6 - all the onboard sound chips are rubbish - none of them show
this problem.
Probably not a lot of help though :/
--
Will J Godfrey
http://www.musically.me.uk
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
On Dec 7, 2016 06:48, termtech
<termtech(a)rogers.com> wrote:
It appears to be something related to certain (older?) PCI audio cards.
Although, I think Len said he's running a similar card as mine
and hasn't seen any problems.
An older SBLive! PCI card appeared to work fine. Maybe I should test again...
Tim. 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? 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:
> "[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.
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.
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
2910
days inactive
2910
days old
linux-audio-user@lists.linuxaudio.org
2 comments
3 participants
participants (3)
-
David Jones -
termtech -
Will Godfrey