[puzzle] unknown property
kuroneko
Posts: 3,623
Disclaimer: This one is for real. I don't have an answer (yet) so would appreciate new input.
I setup a counter for audio generation (ctrx/frqx/phsx: DUTY, $80010000, 0). This will generate a pulse train (assuming 80MHz) of 40MHz with a period of 64K cycles. Within those 64K cycles 32K-1 consecutive cycles are inverted (the effect of $80010000). I consider this shape constant (one has to start somewhere).
Now the big question is what other property of the pulse train can be affected/modified so that the audio circuitry would produce the same frequency but at a different volume?
To get an idea of what I mean try the following program with the duty method running in cog 0 and cog 7.
demoboard example (left audio):
A admittedly there is a slight drop in volume for cog 7
I setup a counter for audio generation (ctrx/frqx/phsx: DUTY, $80010000, 0). This will generate a pulse train (assuming 80MHz) of 40MHz with a period of 64K cycles. Within those 64K cycles 32K-1 consecutive cycles are inverted (the effect of $80010000). I consider this shape constant (one has to start somewhere).
Now the big question is what other property of the pulse train can be affected/modified so that the audio circuitry would produce the same frequency but at a different volume?
To get an idea of what I mean try the following program with the duty method running in cog 0 and cog 7.
demoboard example (left audio):
CON
_clkmode = XTAL1|PLL16X
_xinfreq = 5_000_000
VAR
long stack[32]
PUB null
coginit(7, duty, @stack{0})
PRI duty
dira[11]~~
ctra := constant(%0_00110_000 << 23 | 11)
frqa := $80010000
waitpne(0, 0, 0)
What do I have so far:
- this effect is independent of the cog-pin distance and - from a preliminary check - clock frequency
- counter duty outputs follow the [post=976476]delay map[/post] pattern so they are not special in that respect (same mux)
- simulating the above DUTY pulse train with an NCO gives me the same volumeA for all cogs
- Peter (pjv) did some scope tests for me: Oscilloscope traces show no discernable differences [for cog 0/7 pulse trains].
A admittedly there is a slight drop in volume for cog 7
Comments
We all agree that there is quantization noise. Tough but OK. Then there is cross-talk, i.e. don't pick two adjacent pins for audio. OK. The remaining issue for me is cog #7. It was suggested that OR-chain propagation delays could be a possible cause. Which I can't really agree with simply because cog #0 would be ideally paired with pins 7/8 and cog #7 with pins 23/24 (shortest delay). Despite this pairing (checked on a PPDB with a naked prop) cog #7 stays noisy while cog #0 is clean (let's call that DUTY noise for now). This is evident for mono and stereo output.
What did I do next? I wrote a number of soft DUTY generators using outa/phsx[31] and video h/w as line drivers (instead of DUTY, i.e. carry). Resolution is obvioulsy less than 1 system cycle but I managed 4/8/10/16 cycles. All of which still exhibit quantization noise (expected) but are independent of the cog they are running in terms of DUTY noise. Meaning even if I force them to run in e.g. cog 6/7 I don't get the distortion normally associated with DUTY counter drivers running in cog #7. Yes, it comes at a price (I need one cog per channel, best case) but I can accept the quality and I don't have to worry about which cogs to use.
Then it occurred to me that the XTAL circuitry sits exactly between pin group 2 and 3 (pins 23/24). So what if the clock generator has a negative effect on cog #7's DUTY lines (and to a somewhat - a lot - lesser extend on cog #6)? DUTY output, PLL, phsx[31] and pin A1 are all merged in a MUX before going out so unlucky routing for DUTY doesn't sound too unlikely to me. And this would actually be an explanation I could accept.
Thoughts?