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@email-addr-hidden http://lists.linuxaudio.org/listinfo/linux-audio-userReceived on Wed Nov 2 00:15:01 2016
This archive was generated by hypermail 2.1.8 : Wed Nov 02 2016 - 00:15:02 EET