[LAU] [SOLVED] Crackles in audio, drifting intermittent noise etc.

[termtech]

On Tuesday, November 1, 2016 2:36:21 PM EDT Chris Caudle wrote:
> This shows that there are 4 real cores, not 2 cores with hyperthreading:
> > core id         : 0
> > core id         : 1
> > core id         : 2
> > core id         : 3
> 
> With hyperthreading you would see processor 0 and processor 1 both on core
> id 0, and processor 2 and processor 3 both on core id 1.
> But that means as far as the kernel is concerned, there is not really any
> difference between two cores enabled and four cores enabled.  The big
> change is from single core to multi-core operation.  So no obvious
> explanation why changing from four to two processor cores would make a
> difference.
> 
> On Mon, October 31, 2016 6:13 pm, termtech wrote:
> >> > This time however, I noticed something: When using the card in an
> >> 
> >> 'effect' situation, where audio input is passed through to an audio
> 
> output,
> 
> Using analog in and out?  When I asked about the clock configuration
> previously I was thinking of effect in the opposite directly, for example
> play audio out through S/PDIF into a digital effect of some kind, and the
> audio with effects is returned through S/PDIF.  If all the I/O is only
> through the analog in and out then it is much harder to mess up the clock
> configuration.
> 
> > With playback only, there were crackles and pops and eventually, depending
> > 
> >  on the test tone, it could lapse into horrible permanent screeching.
> 
> What is the software stack?  The full software stack, what software was
> playing the test tone, does that software access the ALSA device directly,
> or through jackd, or through pulseaudio?  If using pulseaudio is it using
> the ALSA device directly or through jackd?
> 
> What you describe with playback only sounds like a problem I used to get
> when running my audio hardware at 44.1k sample rate and playing back audio
> at 48k sample rate (like from a video).  The pulseaudio server was running
> a sample rate conversion rather than switching the hardware clock rate,
> and eventually there would be some underrun condition and the pulseaudio
> sample rate converter never recovered.  I changed my default clock rate to
> 48k and the problem went away, so now I leave the hardware set at 48k for
> general use with pulseaudio (mostly playing youtube videos), and just
> change to 44.1k if I want for a specific project using jackd.
> 
> Might not be related, but would be worth checking if you are using
> pulseaudio.  I am reasonably sure it was pulse specific, although I assume
> other software could do something similar with implicit sample rate
> conversion.
> 
> > This test suggests maybe one core is handling playback and
> > 
> >  another is handling record
> 
> It doesn't really work like that, the processor clock cannot be
> synchronized to the audio sample clock, so eventually there would be drift
> and synchronization problems.  The audio card sends interrupts when the
> buffers have enough bytes available to read (on the input side), or when
> there is enough space available for more playback data on the output side.
>  The cores don't have to know anything about sample clocks or playback
> rate, they just have to be able to service the interrupt in enough time
> that the next buffer is filled before it is needed for playback, or that
> the incoming bytes are cleared out before the input buffers run out of
> room.
> 
> > It's on internal 44KHz clock, not spdif or external clock.
> 
> That configuration plus the fact that the problem shows up with playback
> only would suggest the problem is not caused by synchronization.  Whether
> there could be additional problems relating to the simultaneous input and
> output I'm not sure, but obviously with output only and internal clock
> there cannot be a need for synchronization.
> 
> >> >  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 was years ago.
> https://en.wikipedia.org/wiki/Time_Stamp_Counter
> https://en.wikipedia.org/wiki/High_Precision_Event_Timer
> 
> > The problem exists in Windows (7), and in Linux with Jack or Pulse.
> 
> Those would be pretty different implementations of the audio drivers and
> the audio API's in the operating system.  Hard to think a software problem
> would affect Windows and jackd the same as it does pulse, so maybe my
> earlier suggestion about implicit sample rate conversion doesn't apply.
> Although Windows probably has implicit sample rate conversion, it would be
> surprising if it was buggy in exactly the same way that pulse is.
> And jackd does not do any sample rate conversion, all software running
> with jack as a backend must use the session sample rate, so maybe I got
> off base when I saw test tone web site.  Is the behavior with jackd really
> the same as with pulse?
 
> So I'm still a bit stumped if this is really the same problem on playback
> only as it is on in/out pass through.

My thoughts as well, since the slight glitches (see my posted sample)
 that accompany the drifting noise seem to be separate and pervasive
 throughout the slow appearance then disappearance of the drifting noise,
 and they are the same pervasive glitches in the playback only situation.

My dealer said today, when told of all this:
"I forgot to tell you. I had to do the same thing for another client who 
 was running Cubase. He asked for the 'lastest and greatest' hardware 
 but in the end I had to drop to two cores because the software just 
 didn't handle multi-core very well at the time."
I pointed out that might not be the same as these hardware issues;
 that Cubase and others' effective use of threading, and how it has 
 evolved, is a different thing. But then, these apps also contain
 drivers and ASIO and so on, so who knows, eh?

Yesterday I read somewhere, and was reminded, that audio 
 processing is a 'serial' task that may not benefit well from 
 n-core CPUs and therefore one should choose a CPU with the 
 highest possible clock and try to run with fewer cores.


I must mention something that adds mud, but clears it up more:

When I try the on-board sound, or an old spare PCI SoundBlaster Live!,
 the sound is actually OK ;-)
I've yet to verify that statement for this replacement PC, but it's true for 
 the unit it replaced. That test did not bode well for this Delta1010 card.

For that reason I may chalk this up to just a weird combination
 of this older PCI sound card (PCI rev 2.0 or 2.1 I think) and this
 new-fangled MB and CPU.

Maybe there's hope that a driver tweak could help?
The Windows driver hasn't been updated in four years.
Maybe it and the Linux driver share the same problem - needing an update?
But then, this MB and the other one are from around 2009/2010 or so.
If not then it's likely just this hardware combo.
Heck it could still be /this/ specific unit.
It would be nice to get some verification from similar users...

It's just so weird. A brutal stupid ironic introduction to n-core CPUs.
Happy I can play keys now though. Persistence pays. No new card!
And at least my *guitar* doesn't need a freakin' CPU, just my brain :-)

Thanks. Cheers.
Tim.