3 Dec
2016
3 Dec
'16
8:20 p.m.
Greetings,
Long-time Linux user, and relatively new JACK user here. I have built
some audio workstations for the community radio station where I
volunteer (WDRT, Viroqua, WI, US). I recently switched one of the
workstations to use JACK, along with PulseAudio. We use Audacity to edit
audio and we have noticed that the "left" and "right" channels are
out
of sync with each other. We have witnessed the "skew" to be as few as
two samples (which is unnoticeable to the ear) to as many as a couple
hundred samples (which sounds a lot like a phase error).
We performed a lot of troubleshooting, including swapping PCI audio
cards (ESI Juli@, Digigram VX222), disabling JACK, running Audacity on
the same hardware booted from a USB stick and a completely different
Debian environment. I am not *completely* confident, but the likely
culprit seems to be JACK.
We have recorded audio using jack-record and experienced the same
left-right channel skew.
Can anyone help point to JACK or OS configuration parameters that we
might look at to get our left and right channels in sync?
Details:
OS: Debian Jessie (8.6), up to date (kernel: 3.16.0-4-amd64 #1 SMP
Debian 3.16.36-1+deb8u2 (2016-10-19) x86_64 GNU/Linux)
JACK (jackd2): 1.9.10+20140719git3eb0ae6a~df
PulseAudio: 5.0-13
ALSA: 1.0.27+1
CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz
RAM: 8GB
Audio Cards: ESI Juli@ PCI, Digigram VX222HR PCI
Thanks for your consideration!
~David Klann
3 Dec
3 Dec
8:50 p.m.
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
some audio workstations for the community radio station where I
volunteer (WDRT, Viroqua, WI, US). I recently switched one of the
workstations to use JACK, along with PulseAudio. We use Audacity to edit
audio and we have noticed that the "left" and "right" channels are
out
of sync with each other. We have witnessed the "skew" to be as few as
two samples (which is unnoticeable to the ear) to as many as a couple
hundred samples (which sounds a lot like a phase error).
We performed a lot of troubleshooting, including swapping PCI audio
cards (ESI Juli@, Digigram VX222), disabling JACK, running Audacity on
the same hardware booted from a USB stick and a completely different
Debian environment. I am not *completely* confident, but the likely
culprit seems to be JACK.
We have recorded audio using jack-record and experienced the same
left-right channel skew.
Can anyone help point to JACK or OS configuration parameters that we
might look at to get our left and right channels in sync?
Details:
OS: Debian Jessie (8.6), up to date (kernel: 3.16.0-4-amd64 #1 SMP
Debian 3.16.36-1+deb8u2 (2016-10-19) x86_64 GNU/Linux)
JACK (jackd2): 1.9.10+20140719git3eb0ae6a~df
PulseAudio: 5.0-13
ALSA: 1.0.27+1
CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz
RAM: 8GB
Audio Cards: ESI Juli@ PCI, Digigram VX222HR PCI
Thanks for your consideration!
~David Klann
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
2:34 p.m.
New subject: [SOLVED] "Skewed" Audio with JACK
On 12/03/2016 01:50 PM, termtech wrote:
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.
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
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.
5:26 p.m.
New subject: [SOLVED] "Skewed" Audio with JACK
On Wed, 7 Dec 2016, David Klann wrote:
On 12/03/2016 01:50 PM, termtech wrote:
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
Even with the same cpu/audio driver and I think both with jack2. I don't
have the problem. I do have only one RAM socket filled with 8G rather than
the suggested two 4G RAM so the cpu can access ram faster (I don't know
the right words). Anyway, I have the lowest priced ASUS MB that has 3 PCI
slots, ps2 mouse and keyboard plugs... nothing else matters :) Well
actually, having too many bells and whisles on the MB may matter, but I
haven't tried that.
Another thing to try if you already run in performance mode, do you have
"Boost" turned off in bios? In performance mode with Boost enabled, the
cpu speed may still change between the highest normal cpu speed up to the
highest boost speed. Changes in CPU speed has been known to cause audio
irregularities. That is I can run with the cpu a solid 800MHz with less
trouble at lower latency than with ondemand (atom single core cpu was
tested most though I did do some testing on an old P4 as well and
performance mode does still make a difference with the i5 though I have
not tested how much) Ondemand can run anywhere from 800Mhz to top speed.
I have just learned how to control boost from the cli and will do some
testing with it on and off to see how much difference it makes for me.
Be careful when you see the words good low latency performance from
computer people. Low latency for most computer engineers seems to mean
less than 30ms. 30ms is pretty much useless for live effects (guitarix) or
live softsynth use.
--
Len Ovens
www.ovenwerks.net
5:48 p.m.
New subject: [SOLVED] "Skewed" Audio with JACK
On Wednesday, December 7, 2016 7:34:25 AM EST David Klann wrote:
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.
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. 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
4 Dec
4 Dec
12:59 a.m.
There's more or less no way for JACK to do this. Its entire design is "be
woken by hardware to process N samples; process N samples; go to sleep". It
is a synchronous low latency design that does not offer scope for
processing different channels or different outputs at different times.
On Sat, Dec 3, 2016 at 7:20 PM, David Klann <dxklann(a)gmail.com> wrote:
Greetings,
Long-time Linux user, and relatively new JACK user here. I have built
some audio workstations for the community radio station where I
volunteer (WDRT, Viroqua, WI, US). I recently switched one of the
workstations to use JACK, along with PulseAudio. We use Audacity to edit
audio and we have noticed that the "left" and "right" channels are
out
of sync with each other. We have witnessed the "skew" to be as few as
two samples (which is unnoticeable to the ear) to as many as a couple
hundred samples (which sounds a lot like a phase error).
We performed a lot of troubleshooting, including swapping PCI audio
cards (ESI Juli@, Digigram VX222), disabling JACK, running Audacity on
the same hardware booted from a USB stick and a completely different
Debian environment. I am not *completely* confident, but the likely
culprit seems to be JACK.
We have recorded audio using jack-record and experienced the same
left-right channel skew.
Can anyone help point to JACK or OS configuration parameters that we
might look at to get our left and right channels in sync?
Details:
OS: Debian Jessie (8.6), up to date (kernel: 3.16.0-4-amd64 #1 SMP
Debian 3.16.36-1+deb8u2 (2016-10-19) x86_64 GNU/Linux)
JACK (jackd2): 1.9.10+20140719git3eb0ae6a~df
PulseAudio: 5.0-13
ALSA: 1.0.27+1
CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz
RAM: 8GB
Audio Cards: ESI Juli@ PCI, Digigram VX222HR PCI
Thanks for your consideration!
~David Klann
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
6:06 p.m.
On Sat, 3 Dec 2016, David Klann wrote:
Long-time Linux user, and relatively new JACK user
here. I have built
some audio workstations for the community radio station where I
volunteer (WDRT, Viroqua, WI, US). I recently switched one of the
workstations to use JACK, along with PulseAudio. We use Audacity to edit
audio and we have noticed that the "left" and "right" channels are
out
of sync with each other. We have witnessed the "skew" to be as few as
two samples (which is unnoticeable to the ear) to as many as a couple
hundred samples (which sounds a lot like a phase error).
Pulse is pretty much guarenteed to loose samples here and there. Audacity
uses portaudio (I think) to talk to jack, I don't know how good that is or
not.
We performed a lot of troubleshooting, including
swapping PCI audio
cards (ESI Juli@, Digigram VX222), disabling JACK, running Audacity on
the same hardware booted from a USB stick and a completely different
Debian environment. I am not *completely* confident, but the likely
culprit seems to be JACK.
I do not know about the juli, but the digigram does rather a lot of
processing including the posibility of sample rate conversion. One of it's
features is a continuously variable sample rate which may be a SRC derived
process. There have in the past been audio interfaces (SB 94ish?) that
have a one speed codec that runs through a HW SRC unit to provide the
computer with the requested sample rate. In that case they even did
48k->48k SRC with the result that any long recording had a different sized
file for left and right. As src is common in broadcast audio interfaces
(particularily on aes3 inputs) I would want to make sure that is turned
off.
Have you tried mhWaveEdit instead of Audacity? It may not provide all the
features Audacity does plugin wise, but other than that it seems quite
solid.
--
Len Ovens
www.ovenwerks.net
5:37 p.m.
On Sun, 4 Dec 2016, David Santamauro wrote:
On 12/04/2016 12:06 PM, Len Ovens wrote:
Pulse doesn't tell you about xruns. It makes whatever it has as an input
fit what the output needs by whatever method needed with the least amount
of audible distortion. Just like most people can not tell the difference
between an MP3 and the wav it came from, most people can not tell the
difference from pulse's input to it's output. But in the same way you
wouldn't use MP3 as a DAW tracking standard, I wouldn't use pulse for
recording unless there was no other way. (skype phone call for example)
It is another way of saying it handles just
about anything gracefully.... even skype. But it is a desktop audio system
that is designed for audio consumption, not audio creation. It does really
well at what it is designed for and even not too bad at what it is not
designed for.
I run pulse on my desktop as a front end for jack. Pulse sees jack as the
(only) audio device. I try not to record anything so badly I need to use
the noise remover in Audacity.... the Audacity noise removal plugin being
the only feature I can't find elsewhere.
letting Pulse directly see/connect to any real audio device will
compromise the pulse-jack bridge and cause xruns.
I hope I have made clear I am not against pulse. It works very well in the
place it was designed for. I still prefer a boxend wrench over an
adjustable wrench when I work on a truck too.... but will use vicegrips in
an emergency. Every tool has it's place.
--
Len Ovens
www.ovenwerks.net
Pulse is pretty much guarenteed to loose samples
here and there.
Please define "loose samples here and there" ... thanks
2910
days inactive
2914
days old
linux-audio-user@lists.linuxaudio.org
8 comments
5 participants
participants (5)
-
David Klann -
David Santamauro -
Len Ovens -
Paul Davis -
termtech