Re: [LAU] [SOLVED] Example captured: Crackles in audio, drifting intermittent noise etc.
1 Nov
2016
1 Nov
'16
5:24 a.m.
On Monday, October 31, 2016 4:35:44 PM EDT you wrote:
On Mon, Oct 31, 2016 at 4:13 PM, termtech
<termtech(a)rogers.com> wrote:
Yeah nice one but I doubt heat related - more like voltage drop spike
related, more activity on the power rails causing more spikes causing
the audio card to glitch.
In the original thread we talked about weak capacitors on the sound card.
I was seriously contemplating that possibility once again today,
until I managed to capture the sound and analyze it :
https://dl.dropboxusercontent.com/u/53315356/Test_tone_passthru_noise.ogg
It is a recording of a hardware audio sine generator (my keyboard),
input to the Delta1010, recorded as it is being passed through to an
audio output via Jack. What you hear is what I hear out of that output.
Hey all you digital audio experts!
Listen to the recording, be patient and watch how the distortion slowly
drifts in then out. Open it in Audacity or something, and notice the spikes.
Seems to me, that you can tell by the distortion's overtones which slowly
rise in spectrum then disappear, that this /resembles/ a textbook case of
some read pointer 'meeting up with' and passing some write pointer and
when they meet there is distortion.
In other words they are at slightly different /rates/.
Do you hear what I mean about being easily recognizable as a sync problem?
But how? And why core related?
I mean... I'll have to check chip docs but the card may have separate
read and write sample rates...
But no, look closely at the spikes in the wave in Audacity. It appears some
buffer is 'starting' too early or too late - like the buffer is suddenly
being switched in the middle of a wave and it is that switching time
that is varying.
So maybe not a /soundcard/ clock rate problem but something is not filling
the buffers at the right time? Again - core synchronization?
Also, aside from the drifting noise, notice the slight glitches in the sound
that are pervasive throughout.
/That/ is what I hear even with simple playback of test tones on websites!
You can hear the clock rates jumping around slightly. Yes, I know this is
/usually/ caused by Speed Step, Hyper Threading and so on, but the
fscking thing does it with all such setting turned off. On the other PC too.
Only choosing TWO (or one) cores instead of FOUR stops all these noises.
Thanks for listening. Whaddya think?
Tim.
On Monday, October 31, 2016 3:55:30 PM EDT Chris
Caudle wrote:
Yeah, I know. Very strange. Single card. No other audio enabled.
Onboard audio disabled.
With playback only, there were crackles and pops and eventually, depending
on the test tone, it could lapse into horrible permanent screeching.
With full duplex audio in -> audio out (live effect or pass-through
situation mentioned above), eventually the slow drifting was noticed.
This test suggests maybe one core is handling playback and
another is handling record, and they are drifting in time such that
every 15 minutes it drifts into that bad noise and then drifts out again.
How else to explain? It sounds like exactly what happens when you
actually purposely force a playback DAC to a slightly different
sample rate than the recording ADC, in a pass-through situation.
(Intel
Any chance that it's a heat issue? More cores can generate more heat (I
think) and turning off 2 might be something? Or, a power issue? More cores
will draw more power, and if the PS is marginal this could be an issue.
I'm suggesting this because having the same software problem on Win and
Linux is odd :) On Mon, October 31, 2016 2:18 pm, termtech
wrote:
'effect'
Recall: My Delta1010-LT card was not OK in my new
PC...
...
> This time however, I noticed something: When using the card in an > situation, where audio input is passed
through to an audio output,
either
> directly or with some effect, horrible
noise would appear after 15
>
> minutes and then... slowly drift into working again for 15 minutes,
> and then slowly drift into noise again for 15 minutes, then
> working again for 15 minutes and so on.
>
> This was a HUGE clue. This slow drifting in and out of noise is
familiar.
It is
instantly recognizable to me (as should you) as a
synchronization
problem, not a PCI voltage or bus problem.
This is with a single 1010LT card, correct?
I think that clock sync problems should not be possible with a properly
configured single card. Can you show the clock configuration for your
card some way? Maybe
screen
capture of envy24control? I think that there
should be options for
internal clock, S/PDIF recovered clock, or word clock input for the
output. If you are using external S/PDIF connected devices you will
probably need to verify that there is one device set to use internal
clock, and all other devices synchronized to the received S/PDIF clock.
No trouble there. It's on internal 44KHz clock, not spdif or external
clock.
And I tried flipping the setting a few times. And rebooting.
I even unplugged the Delta 1010's multi-connector containing the sync
and spdif cables, in case interference was getting in.
> So... on this replacement PC there is a
setting in the BIOS for the
number
of CPU
cores to activate. The cheaper original new PC had NO such
setting.
Physical cores, or virtual cores? Virtual cores would usually be called
simultaneous multi-threading (SMT, generic term) or hyper-threading trademark). Enabling hyper-threading can
increase latency, disabling
and
measuring change in worst case latency is usually one of the things to
check when tuning a machine for low latency.
in
I had even researched these CPUs and had read
that it is possible that
the CPU Clock signals can be independent for each core, thus causing
some synchronization problems.
There are multiple things that can accurately be described as a "clock" modern CPU's, some of which change with core
speed if using power
savings
modes which modify the CPU frequency. Competently designed modern
software would not use those timers and would use a core frequency
invariant timer.
when
At this point I'm not sure if this a clock
signal sync problem or a
timer/counter problem. I had also read that 'local' timers/counters
can be a problem with multi-core CPUs - that time is not quite the
same in each core.
That is correct, you can research how that is handled in modern CPU's software needs accurate timekeeping. It is
basically a solved problem,
although using inappropriate timers could be a problem if using software
which was developed many years ago.
> IIRC Someone told me that a quad core is two chips each with two cores
??
That tended to be true in 2005, not so much these
days. Most processors
with up to 12 cores, sometimes more, are single die now. Those which
are
not do not tend to show up in desktop computers.
processors.
Can anyone shed some more light on these
multi-core problems?
Comments welcome, please!
I personally have not experienced any problems with multi-core When you enable all four cores, what is in the
contents of
/proc/cpuinfo?
First impression is that this is a problem with the card synchronization
settings, but I have no idea how changing the CPU configuration could
affect that.
What software is running? Is this system using jackd, or direct ALSA
access, or something else?
The problem exists in Windows (7), and in Linux with Jack or Pulse.
For example simply going to a test-tone website and playing the
tones in Windows, or in Linux via Pulse. Jack isn't running in
that case but maybe Pulse is starting Jack... Must check.
And certainly with any Linux Jack app it does it (MusE, JackRack etc).
I tried running Jack with hpet clock source (I had to run as root), no
luck.
Here is my cpuinfo with two and four cores:
Can you spot anything? Thanks for your help!
Tim.
[With two CPU cores:]
========================
cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 30
model name : Intel(R) Core(TM) i5 CPU 750 @ 2.67GHz
stepping : 5
microcode : 0x3
cpu MHz : 2668.000
cache size : 8192 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 2
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx
rdtscp lm
constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc
aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm
sse4_1 sse4_2 popcnt lahf_lm tpr_shadow vnmi flexpriority ept vpid dtherm
ida
bugs :
bogomips : 5333.11
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 30
model name : Intel(R) Core(TM) i5 CPU 750 @ 2.67GHz
stepping : 5
microcode : 0x3
cpu MHz : 2668.000
cache size : 8192 KB
physical id : 0
siblings : 2
core id : 1
cpu cores : 2
apicid : 2
initial apicid : 2
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx
rdtscp lm
constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc
aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm
sse4_1 sse4_2 popcnt lahf_lm tpr_shadow vnmi flexpriority ept vpid dtherm
ida
bugs :
bogomips : 5333.11
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
[With four CPU cores:]
========================
cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 30
model name : Intel(R) Core(TM) i5 CPU 750 @ 2.67GHz
stepping : 5
microcode : 0x3
cpu MHz : 2668.000
cache size : 8192 KB
physical id : 0
siblings : 4
core id : 0
cpu cores : 4
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx
rdtscp lm
constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc
aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm
sse4_1 sse4_2 popcnt lahf_lm tpr_shadow vnmi flexpriority ept vpid dtherm
ida
bugs :
bogomips : 5333.44
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 30
model name : Intel(R) Core(TM) i5 CPU 750 @ 2.67GHz
stepping : 5
microcode : 0x3
cpu MHz : 2668.000
cache size : 8192 KB
physical id : 0
siblings : 4
core id : 1
cpu cores : 4
apicid : 2
initial apicid : 2
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx
rdtscp lm
constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc
aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm
sse4_1 sse4_2 popcnt lahf_lm tpr_shadow vnmi flexpriority ept vpid dtherm
ida
bugs :
bogomips : 5333.44
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
processor : 2
vendor_id : GenuineIntel
cpu family : 6
model : 30
model name : Intel(R) Core(TM) i5 CPU 750 @ 2.67GHz
stepping : 5
microcode : 0x3
cpu MHz : 2668.000
cache size : 8192 KB
physical id : 0
siblings : 4
core id : 2
cpu cores : 4
apicid : 4
initial apicid : 4
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx
rdtscp lm
constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc
aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm
sse4_1 sse4_2 popcnt lahf_lm tpr_shadow vnmi flexpriority ept vpid dtherm
ida
bugs :
bogomips : 5333.44
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
processor : 3
vendor_id : GenuineIntel
cpu family : 6
model : 30
model name : Intel(R) Core(TM) i5 CPU 750 @ 2.67GHz
stepping : 5
microcode : 0x3
cpu MHz : 2668.000
cache size : 8192 KB
physical id : 0
siblings : 4
core id : 3
cpu cores : 4
apicid : 6
initial apicid : 6
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx
rdtscp lm
constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc
aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm
sse4_1 sse4_2 popcnt lahf_lm tpr_shadow vnmi flexpriority ept vpid dtherm
ida
bugs :
bogomips : 5333.44
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user 
1 Nov
1 Nov
8:02 a.m.
New subject: [SOLVED] Example captured: Crackles in audio, drifting intermittent noise etc.
On Tue, 01 Nov 2016 00:24:16 -0400
termtech <termtech(a)rogers.com> wrote:
Yeah nice one but I doubt heat related - more like
voltage drop spike
related, more activity on the power rails causing more spikes causing
the audio card to glitch.
In the original thread we talked about weak capacitors on the sound card.
I was seriously contemplating that possibility once again today,
until I managed to capture the sound and analyze it :
https://dl.dropboxusercontent.com/u/53315356/Test_tone_passthru_noise.ogg
It is a recording of a hardware audio sine generator (my keyboard),
input to the Delta1010, recorded as it is being passed through to an
audio output via Jack. What you hear is what I hear out of that output.
Hey all you digital audio experts!
Listen to the recording, be patient and watch how the distortion slowly
drifts in then out. Open it in Audacity or something, and notice the spikes.
Seems to me, that you can tell by the distortion's overtones which slowly
rise in spectrum then disappear, that this /resembles/ a textbook case of
some read pointer 'meeting up with' and passing some write pointer and
when they meet there is distortion.
In other words they are at slightly different /rates/.
Do you hear what I mean about being easily recognizable as a sync problem?
But how? And why core related?
I mean... I'll have to check chip docs but the card may have separate
read and write sample rates...
But no, look closely at the spikes in the wave in Audacity. It appears some
buffer is 'starting' too early or too late - like the buffer is suddenly
being switched in the middle of a wave and it is that switching time
that is varying.
So maybe not a /soundcard/ clock rate problem but something is not filling
the buffers at the right time? Again - core synchronization?
Also, aside from the drifting noise, notice the slight glitches in the sound
that are pervasive throughout.
/That/ is what I hear even with simple playback of test tones on websites!
You can hear the clock rates jumping around slightly. Yes, I know this is
/usually/ caused by Speed Step, Hyper Threading and so on, but the
fscking thing does it with all such setting turned off. On the other PC too.
Only choosing TWO (or one) cores instead of FOUR stops all these noises.
Thanks for listening. Whaddya think?
Tim.
As a matter of interest, have you got access to a USB sound unit? If so does
that exhibit the same problem?
The reason I ask is that I have a Novatech nspire laptop with a quad core i5,
and have no issues at all using it with a KA 6 - indeed I used it on last
year's LAC where it was running for an hour and a half. At that time it wasn't
even running an RT kernel.
--
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.
1:50 p.m.
New subject: [SOLVED] Example captured: Crackles in audio, drifting intermittent noise etc.
On Tue, 01 Nov 2016 00:24:16 -0400
termtech <termtech(a)rogers.com> wrote:
In the original thread we talked about weak capacitors
on the sound
card.
I more or less recently changed the alsa part of the jackd incantation
to have larger 'frames' (sorry if that's not the proper term) and a
larger number of them, which is now:
/usr/bin/jackd --sync -T -P80 -ndefault -dalsa -dhw:M1010LT -r44100
-p256 -n4
It was: -p128 -n2
Since then there are much less happenings/events of crackling. Which
would perhaps make sense since 'these' are larger and have more of them.
It still looks like a combination of user actions between using for
example firefox audio (youtube clips) while Bitwig is running (but
not playing audio) can throw the system in crackling audio mode at which
point a reboot is needed to straighten things back.
In this case, the problem is not constant and is created at the
software level. There is probably no relation between software actions
and pushing weak capacitors beyond their weakened limits.
--
NP: "lo stato delle cose" - Deus ex Machina
https://www.youtube.com/watch?v=z-vnkn8gAxc
2945
days inactive
2945
days old
linux-audio-user@lists.linuxaudio.org
2 comments
3 participants
participants (3)
-
jonetsu -
termtech -
Will Godfrey