audioio does not maintain synchonisation of A0/A1 looping some audioio.RawSample data

[kevinjwalters]

I appear to have made some data which despite being even in length (4930 samples = 2465*2) when passed to audio.RawSample with channel_count=2 and then sent to output with play() with loop=True it will play but the A0/A1 will not stay synchronised and drift around. At 100kHz playback it takes 60 seconds to return to being very briefly in sync. I might expect this if I passed an odd number of samples, e.g. 9 could end up as 5 looping on DAC0 and 4 looping on DAC1.

Code is rather large because it contains the data as a list, see https://github.com/kevinjwalters/circuitpython-examples/blob/master/pygamer/audioio-phasebug.py. In that example there's a boolean which controls whether to replace the data values with an alternate set of rising values without changing the total number of values (samples). Doing that makes the bug go away, the bug appears to be very dependent on the data values with no obvious explanation.

This does seem rather unlikely so there's a minor chance I have made an error here...

BTW, what's the intended behaviour for audioio.RawSample if it's given a number of samples which are not exactly divisble by the channel_count?

[tannewt]

I'd expect it to throw an exception when the sample count isn't divisible by channel_count. I'm not positive it does though.

I'd encourage you to dig into the C side of the audio APIs. I bet you could fix a number of these issues.

[kevinjwalters]

I'm in the middle of some application programming at the moment but will have a look when I get to end of that.

I've also discovered another problem with dacs.play(something, loop=True) ceasing output and possibly leaving output on the last sample in something. I thought it was time based but it's not, sometimes it's 20 seconds, sometimes over a 100, sometimes seems to run ok "forever". It's very unclear what the trigger is for cessation of looping! The code in question was just doing a while True: pass after the play().

[kevinjwalters]

I'm running with a smaller amount of data now (882 * 2 = 1764) and if I transform those values keeping length identical sometimes A0/A1 stay in sync and sometimes they don't.

"When they are in sync there might be a few samples missing too". I was wrong here, this was due to a bit of visual confusion from an in-place update on an existing "H" array for audioio.RawSample() causing the update to go out gradually as I slowly updated the array. I've intentionally started using "h" now to take advantage of its creation of a second buffer for DAC output.

[kevinjwalters]

Another observation, I was looking for a workaround and I've noted for similar code/data I've found the bug appears if I use the range 0-32768 on DAC but with same data rescaled to 0-25000 the sync bug goes away.

[kevinjwalters]

It's possible that a bizarre workaround for this is to do a single

rawdata.append(0)

on the end of the data. This doesn't make sense as for 2 channels one would expect the array to always need to be even in length!

CORRECTION, it takes three magic 0s! This makes everything ok.

bizarre_workaround = True
if bizarre_workaround:
    rawdata.append(0)
    rawdata.append(0)
    rawdata.append(0)

[kevinjwalters]

Reproducible on a Feather M4 too. The bizarre_workaround also fixes it on that Feather.

[kevinjwalters]

Also on a Metro M4.

[kevinjwalters]

Worth monitoring #1908 as this also relates to (more fatal) problems that are being attributed to DMA woes.

[jepler]

Reproduced on Metro M4 express. On my scope, the one trace slowly moves with respect to the other one at a constant rate. Just to add to the findings, if I decrease the sample rate enough (24 * 1000) the problem goes away, at least for this sample data. As the original reporter states, somehow this is dependent on specific sample values, too, which really is a problem for any explanations I might have put forward. Debugging hasn't yielded any insights yet.

[kevinjwalters]

Nice to know it's not just me!