Right channel stops playing audio after a few seconds (samd51)

[jepler]

While trying to reproduce #1992, I ran into this behvaior instead.

Testing setup: A0, A1 into o'scope. Put some.wav and code.py on CIRCUITPY.

Initially, A0 and A1 both display a signal, but often A1 stops showing signal before A0 even though both halves of the sample should play for the same duration. The length of time A1 plays varies. Oddly, it also varies whether the DAC value is high or low at the end of sample playing, on A0 and A1.

The conjecture is, it's a problem with DMA.

Tested in 4.1.0 and master on a Metro M4 Express.

Code to create wave file:

import array 
from numpy import zeros 
import scipy.io.wavfile 
 
X=-32768+8000 
Y=32767 
 
sz = (512, 2) 
a = zeros(sz, 'h') 
a -= 32768

for i in range(0,sz[0],2):
    a[i,0] = X
    a[i,1] = X
scipy.io.wavfile.write("some.wav", 200000, a)

Code to run on circuitpython:

import board
import audioio
import array
import time

X = 4000
Y = 65535
data = array.array('H', [0,0,Y,X])
#sample = audioio.RawSample(data, sample_rate=24 * 1000, channel_count=2)
some_wav = open('some.wav', 'rb')
sample = audioio.WaveFile(some_wav)

### A0 will be x, A1 will be y
a = audioio.AudioOut(board.A0, right_channel=board.A1)

while 1:
    a.play(sample, loop=True)
    time.sleep(1)
    a.stop()
    time.sleep(1)

[dhalbert]

This sounds related to the "refresh" needed on the SAMD51 DAC's. Their output needs to be refreshed explicitly by forcing a reconversion, or else the charge will decay away. If you put various pulldowns on A1 I have a hunch you'll see it decay faster depending on the value of the pulldown.

Turning on refresh is done in ports/atmel_samd/asf4_conf/hpl_dac_config.h: CONF_DAC0_REFRESH and CONF_DAC1_REFRESH are both set to 2. But the symptoms above sound like that value is being changed. Maybe the audio code is somehow ignoring that setting or overriding it?

I originally fixed this issue in #649. @kevinjwalters mentioned this also in #1991 (comment).

[jepler]

I will check into that, but doesn't this apply only to static signals? The value is being changed a nominal 100,000 times per second between 0 to 4000 continuously.

[dhalbert]

Good point. Is the loss of signal abrupt or does it fade down? Abrupt would sound like a DMA problem (if DMA is being used here).

[jepler]

abrupt, like DMA stops

[kevinjwalters]

There's also another setting about current (CONF_DAC0_CCTRL and CONF_DAC1_CCTRL). I've not experimented with this, just came across it in the MicroChip docs. Mentioned on: Adafruit Forums: What's fastest practical sample_rate for M4 DACs?
.

[jepler]

I updated the initial comment with new code and an oscope grab. And just when you got things weird enough, I got this one too:

[jepler]

[kevinjwalters]

I think the SAMD51 has a pseudo-differential mode for the DAC pair? When I saw that in docs I realised bugs around that area could be a cause of some of these coupling-related oddities but there seem to be so many strange quirks that defy an obvious explanation. I did a quick check of the SAMD21 on a CPX a few months back and it's so clean and predictable! It's as if there's a poltergeist in the SAMD51's DACs.

[kevinjwalters]

I wonder if we should take Malvin's advice and start at the beginning? Even at first use the SAMD51 DACs used from CircuitPython behave strangely with #1991 .

Another question is when is the right time to refer an issue to the manufacturer...

[jepler]

Based on this looking "right" in an Arduino environment, I am hoping there's just some spot of setup that we've missed. Unfortunately, I think I've ruled out everything in the DAC's registers. Moving on to clock setup now, h/t @sommersoft

[kevinjwalters]

You are likely to have already observed it or read it, but when I last looked the DACs weren't clocked fast enough in CP to get the higher rates, 3rd post in https://forums.adafruit.com/viewtopic.php?f=60&t=153797#p759051

I'm wondering if that might be an explanation for a few things. Atmel/Microchip may have done all their testing with the DACs clocked at the top rate as there's little (?) reason to go lower.

[jepler]

Since #2552 we use just a single DMA channel to send stereo audio (at least when it's 16 bits). This should resolve such problems. If the problem is not resolved with CircuitPython 5.3.0, feel free to reopen this bug.