On Monday, October 31, 2016 4:35:44 PM EDT you wrote: > On Mon, Oct 31, 2016 at 4:13 PM, termtech <termtech@xxxxxxxxxx> wrote: > > On Monday, October 31, 2016 3:55:30 PM EDT Chris Caudle wrote: > > > On Mon, October 31, 2016 2:18 pm, termtech wrote: > > > > Recall: My Delta1010-LT card was not OK in my new PC... > > > > > > ... > > > > > > > This time however, I noticed something: When using the card in an > > > > 'effect' > > > > > > 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. > > > > 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. > > > > > 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 > > > > (Intel > > > > > 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. > > > > > > > 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" > > > > in > > > > > 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. > > > > > > > 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 > > > > when > > > > > 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. > > > > > > > Can anyone shed some more light on these multi-core problems? > > > > Comments welcome, please! > > > > > > I personally have not experienced any problems with multi-core > > > > processors. > > > > > 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@xxxxxxxxxxxxxxxxxxxx > > http://lists.linuxaudio.org/listinfo/linux-audio-user > > 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 :) 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. _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
