Some ports which actually don't have audioio or audiobusio were still
calling into audio_dma_background(). This wasn't an error until
the assignment to audio_dma_state in audio_dma_stop was added, though
it's not clear why.
audio_dma_stop can be reached twice in normal usage of AudioOut.
This may bear further investigation, but stop it here, by making the
function check for a previously freed channel number. This also prevents
the event channel from being disabled twice.
The first stop location is from audio_dma_get_playing, when the buffers
are exhausted; the second is from common_hal_audioio_audioout_stop when
checking the 'playing' flag.
As identified in #1908, when both AudioOut and PDMIn are used, hard
locks can occur. Because audio_dma_stop didn't clear audio_dma_state[],
a future call to audio_dma_load_next_block could occur using a DMA
object which belongs to PDMIn.
I believe that this Closes: #1908 though perhaps it is still not the full
story.
Testing performed: Loaded a sketch similar to the one on #1908 that
tends to reproduce the bug within ~30s. Ran for >300s without hard
lock. HOWEVER, while my cpx is no longer hard locking, it occasionally
(<1 / 200s) announces
Code done running. Waiting for reload.
(and does so), even though my main loop is surrounded by a 'while True:'
condition, so there are still gremlins nearby.
The original formulation was because I saw the need to avoid a transition
from playing to stopped exactly when a resume was taking place. However,
@tannewt was concerned about this pause causing trouble, because it could
be relatively lengthy (several ms even in a typical case).
After reflection, I've convinced myself that updating the registers
in this order in resume avoids a window where a "stopped" event can
be missed as long as the shortcut is updated first.
Testing re-performed: pause/resume testing of looped RawSample and
WaveFile audio sources.
Snekboard does not expose any pins for SPI to the user, so delete
the SPI object reference as that won't work.
Signed-off-by: Keith Packard <keithp@keithp.com>
Snekboard has been assigned the following PIDs:
PID 0x004D # bootloader
PID 0x804D # arduino
PID 0x804E # circuitpython
Signed-off-by: Keith Packard <keithp@keithp.com>
This is another SAMDG2118A design with built-in 9V motor controllers
that are designed to be used with Lego PowerFunctions devices.
Signed-off-by: Keith Packard <keithp@keithp.com>
This implements AudioOut, with known caveats:
* pause/resume are not yet implemented (this is just a bug)
* at best, the sample fidelity is 8 bits (this is a hardware limitation)
Testing performed:
My test system is a Particle Xenon with a PAM8302 op-amp
https://www.adafruit.com/product/2130 and 8-ohm speaker. There's no
analog filtering between the Xenon's PWM pin and the "A+" input of
the amplifier; the "A-" pin is disconnected. It is powered from
VUSB.
I used pin D4, which is *NOT* listed as a low-speed-only pin, but
the code does NOT switch the pin to high drive. This is related to
an open issue for general inability to set drive level for pins
being used by a "special function" on nrf:
https://github.com/adafruit/circuitpython/issues/1270
Nothing about the code I've written should limit the usable pins.
All samples I played were 16-bit, generally monophonic at 11025Hz
and 22050Hz from the Debian LibreOffice package.
When nrf pwm audio is introduced, it will be called `audiopwmio`. To
enable code sharing with the existing (dac-based) `audioio`, factor
the sample and mixer types to `audiocore`.
INCOMPATIBLE CHANGE: Now, `Mixer`, `RawSample` and `WaveFile` must
be imported from `audiocore`, not `audioio`.
Dan Halbert
Scott Shawcroft
brentru
Jeff Epler
jepler
wallarug
Keith Packard
sommersoft
Scott Shawcroft