Commit Graph

22 Commits

Author SHA1 Message Date
microDev
a52eb88031
run code formatting script 2021-03-15 19:27:36 +05:30
Jeff Epler
eb876e21c3 nrf: code style 2020-05-13 10:40:41 -05:00
Jeff Epler
011acf41c0 nrf: Ensure ticks enabled while playing audio 2020-05-13 10:40:36 -05:00
Scott Shawcroft
affd3fcc2a
Clear the pending IRQ in the NVIC as well. 2020-03-13 11:16:38 -07:00
Scott Shawcroft
ed5cdd7e09
Hopefully fix flash flush and hopefully audio as well. 2020-03-13 11:12:31 -07:00
Dan Halbert
8435935429 update uses of assert_pin_free; remove redundant checks 2020-02-29 15:37:32 -05:00
Scott Shawcroft
e5dd78d393
Merge pull request #2324 from jepler/nrf-i2s-channels-widths
nrf: assign channel width and count correctly
2019-11-25 16:59:08 -08:00
Scott Shawcroft
2653455ded
Merge pull request #2321 from jepler/nrf-i2s-buglets
Nrf i2s buglets
2019-11-25 16:11:43 -08:00
Jeff Epler
1ee35fd6fd nrf: i2sout: move register settings closer together
.. just for consistency's sake
2019-11-25 11:43:51 -06:00
Jeff Epler
47a6eaa297 nrf: i2sout: Assign SWIDTH
The sample width register was never set, so all samples were played
as though they were 16 bit.

After this change, 8-bit samples no longer produce audio on the MAX 98357A
BOB, because only 16-, 24-, and 32-bit samples are supported by the
hardware.  This will be addressed by a future change to pad samples to
16 bits; see #2323 and the 98357A datasheet page 6.
2019-11-25 11:43:29 -06:00
Jeff Epler
8f4bab2d24 i2sout: Correctly retrieve channel_count
The meaning of the "single channel" parameter is not well-documented,
but in fact it seems that "true" must be passed or else the returned
channel_count is always 1.  This caused stereo samples to be played
incorrectly.
2019-11-25 10:59:59 -06:00
Jeff Epler
c9946dfd63 nrf: i2sout: Use <, not !=, for loop condition
This is good C style, h/t @danh
2019-11-25 09:35:57 -06:00
Jeff Epler
19d122e546 nrf: i2sout: Fix double-increment when copying samples
This caused two problems when playing unsigned samples:
 * When an even number of samples were present, it "worked" but only
   every other sample was copied into the output, changing the waveform
 * When an odd number of samples were present, the copy continued beyond
   the end of the buffers and caused a hard fault
2019-11-25 09:07:20 -06:00
Jeff Epler
1c6c9a3e1f nrf: i2sout: Ensure hardware I2S is stopped at deinit
.. otherwise, it may be possible under some scenario, for the background
task to continue and overwrite unrelated memory.
2019-11-22 14:15:07 -06:00
Jeff Epler
aabb56c840 nrf: i2sout: Only update hold_value when appropriate
If we put no samples into the buffer, then there is no last
sample to fill out hold_value with.  (and, in fact, the expression such
as *(uint32_t*)(buffer-4) is outside an allocated region)

Detect this condition, and leave the prior value in place.

This improves clicks heard when pausing and resuming a waveform.
2019-11-22 13:54:37 -06:00
jepler
7b9dfc9952 nrf: i2s: tune audio buffering
.. based on some tasks I found that caused stuttering:

 # Test SD and printing
 while True: os.listdir('.')

 # Test bulk I/O
 while True: len(open('somefile.wav', 'rb').read())

Each of these tasks *WAS* worse and I am improving them in a separate
PR by adding RUN_BACKGROUND_TASKS to them.
2019-09-09 20:13:12 -05:00
jepler
c66f5a8536 nrf: i2s: rewrite without 'goto' 2019-09-09 19:26:18 -05:00
jepler
fe9605a6a3 nrf: i2s: Comment this slightly tricksy code 2019-09-09 19:25:52 -05:00
jepler
ccf08aa3df nrf: I2SOut: deal more gracefully with errors from the sample 2019-09-08 21:59:07 -05:00
jepler
f38ee42874 nrf: Add i2s audio output
Testing performed: I used a Particle Xenon with a HDA1334 I2S DAC.
I played a variety of mono 16-bit samples at 11025 and 22050Hz nominal
bit rates.  With this setup, all the 11025Hz samples sound good.
I tested play, pause,  and loop functionality.

During some runs with 22050Hz samples, there were glitches.  However,
these may have only occurred during runs where I had set breakpoints
and watchpoints in gdb.

I also tested with a MAX98357A I2S amplifier.  On this device, everything
sounded "scratchy".  I was powering it from 5V and the 5V rail seemed
steady, so I don't have an explanation for this.  However, I haven't
tried it with a SAMD board.
2019-09-08 16:46:35 -05:00
Jeff Epler
912fd7759d nrf: PDMIn: Implement
So far, this supports only 16kHz and 16-bit samples with a fixed gain.
This is enough to support the basic functionality of e.g., sensing
ambient audio levels.
2019-08-18 15:58:04 -05:00
Jeff Epler
79f8a85786 nrf: stub out audiobusio.PDMIn, audiobusio.I2SOut 2019-08-18 15:55:57 -05:00