Audio refactor #457
Audio refactor #457
Conversation
Not yet tested.
There was a problem hiding this comment.
Would uBit.audio need a method to change the ADC sampling rate? Or is that located somewhere else?
Not yet tested.
|
@finneyj See sample below. Testing by recording silence for 0.1s and looking at the data dumped by serial streamer When an analogue pin is being read, StreamRecording sometimes waits forever Recording with button A hangs after analogue reading is enabled with P0 (cap touch). Recording with button B activates the mic first, and doesn’t hang. A works after a B recording. I think... When activateMic calls NRF52ADC::activateChannel it doesn’t do anything because the channel has been marked as enabled via dataWanted. NRF52ADC::IsEnabled() is just a flag. It does not mean the channel is actively being checked by an ADC task (one of the enabledChannels count). deactivateMic doesn’t deactivate the mic ADC channel, but other things might (like starting or stopping the analogue reading). Then the enabled/active difference matters again. There seems to be a variable amount of junk at the beginning of a recording With trace added, I have seen activateMic seemingly called after the first buffer demux and pull. I cannot repeat that right now - maybe something to do with trace? Calling setStartDelay in activateMic may be too late, and I think the delay needs to be more than one buffer. Button B recording seems to get better results by calling activateMic() then setStartDelay(4 or 5) before each recording. The start delay required is really a time, so the number of buffers depends on sample rate, and number of other channels. The first buffer of the first recording after reset is weird because the normalizer is not initialised. StreamRecording::play() always sends an empty buffer after the recorded buffers. StreamRecording::play() into SerialStreamer dumps the data but then hangs. Everything happens inside the playAsync call to pullRequest, so StreamRecording notifies playLock, before playAsync exits and playLock.wait is called. The sample uses playAsync, which works like play should! Sample hex MICROBIT.zip Sample code in microbit-v2-samples "audio-refactor" branch I created mw-audio-refactor-merge branches by branching from master, then merging audio-refactor, then branched again to mw-audio-refactor-test to add trace and debug code. e.g. |
|
I noticed commit Increase start up delay to 3 frames, to avoid occasional clicks. And wondered why I saw 1 It was changed in Reduce sensitivity of microphone to permit detection of 35db |
Not ready to merge. Raising this PR for review only.