`AudioFrame` size from constructor vs `microphone.record()`

[microbit-carlos]

Using the latest version (at the time of writing) of the recording & playback branch: 0b06914
Hex: https://github.com/microbit-foundation/micropython-microbit-v2/actions/runs/8416237764?pr=163

Does microphone.record(1000) return an AudioFrame that is not 32-byte rounded?
Or does len() not return the full size of the AudioFrame?

>>> b = microphone.record(100)
>>> len(b)
781
>>> len(b) / 32
24.40625

>>> a = audio.AudioFrame(100)
>>> len(a)
800

>>> a = audio.AudioFrame(100)
>>> microphone.record_into(a, wait=False); sleep(10); microphone.stop_recording()
>>> len(a)
800

[dpgeorge]

Now fixed, microphone.record() always allocates a new AudioFrame that's a multiple of 32 bytes.

Note that rounding up to the nearest 32 bytes is done to simplify the playback: the audio play subsystem breaks the audio data into 32-byte chunks and passes them down to CODAL. It would be possible to lift the 32-byte alignment restriction by filling in the remaining bytes on the last packet with a value of 128.

[microbit-carlos]

Assuming it doesn't have a significant impact on performance, I'm starting to think it might be worth lifting the 32 byte alignment, as it can be unexpected when creating an AudioFrame and then checking its length.

[dpgeorge]

I'm starting to think it might be worth lifting the 32 byte alignment, as it can be unexpected when creating an AudioFrame and then checking its length.

I agree.

It was a pretty simple change actually, and I've now implemented it.

Now, for example, you get:

>>> len(microphone.record(1000))
7812

Which is exactly the default rate (prior to this change you would get a length rounded up to 32).

[microbit-carlos]

Great, thanks Damien!