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. -- Chris Caudle _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
