-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Prevent clicks at the beginning or end of audio play #5136
Comments
We have been looking at the output from PWMAudio with a scope, and it seems that PWMAudioOut is adding a blip of audio unrelated to the actual sample into the first 4ms of the playback. The blip is consistent when using the default buffer size and a buffer of bytearray(512), and changes to something different but consistent with other buffer sizes. Here are some scope pictures where you can see what's happening: The waveform in Audacity. The sample is mono, 44.1khz, 16 bit. The waveform as output on RP2040, with the audio circuit as recommended in the RP2040 datasheet: The relevant bits of code are
Hope this helps find the ploppy bug! PS That first 1ms all negative blip could be the length of the first buffer? |
Update: using playback via the AudioMixer ( So when using PWM Audio, It's possible that the audio_dma_setup_playback called from common_hal_audiopwmio_pwmaudioout_play blocks the pwm being written long enough to cause the pop. All this is on an RP2040 board. |
I've recently been playing with For reference I have a number of instrumental mp3 files encoded at 8kbps / 8Khz / mono. I've attached one here.
I get a click at before the first track, and again in between each track. I haven't tried the AudioMixer workaround mentioned above just yet... I've been hunting through the C code for these modules and trying a bunch of things relating to buffers, decoding, chasing data from the mp3 files through decoder, dma and pwm trying to narrow down the source of the click. Finally stumbled on:
I found that removing This suggests that the idle value at the start & end of the MP3 track / buffer is different to the quiescent level. The MP3 looks centred around the "zero" level in audacity, but I'm not sure what the translates to in the uint16_t buffer here, might have to log a few buffer levels to compare. Interestingly though, removing the mp3 decoding and playing just a sine wave a few times over instead of mp3 doesn't cause any clicks. If I then re-add the MP3 after the tone, it clicks when the MP3 starts playing.
|
I've a similar problem. We are using a i2S Adafruit microphone to acquire sound for a Raspi4B. We use arecord sentences according to the following link https://learn.adafruit.com/adafruit-i2s ... iring-test We acquire audio signal every 3 seconds for instance, that is saves as a wavfile. The popping/clicking audio happens every start of the signal and sometimes also at the end. I found some clues related with PWM of Raspi https://www.lightbluetouchpaper.org/201 ... pberry-pi/ There are also other similar post reporting the same instance https://raspberrypi.stackexchange.com/q ... 985#147985 Can anyone help me with that? |
Currently for some ports and some audio play mechanisms, there can be clicks at the beginning and/or the end of a sample due to sudden level shifts. We have support for quiescent values but these are often sample-file dependent.
Some ports ramp the amplitude up and down, but this prevents gapless playback and lengthens playing short samples (#3626).
We have also recommended in the past that users add ramping to their own audio files.
We should look at how this problem is solved in the real world, and try to emulate that. In many cases it may be done by speaker or amplifier disabling, which allows for a "soft" settling. Perhaps an audio enable/disable pin can be passed optionally to the audio play objects or methods.
The text was updated successfully, but these errors were encountered: