You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We've been tinkering with audio on PicoSystem and in the case of at least PWM audio, take_audio_buffer never seems to return null, and never seems to stall for any length of time.
In instances where we're naively calling an "audio_update" function at an arbitrary speed (too quickly in our case) this results in the audio engine getting clocked at some multiple it's intended speed, since we're relying upon take_audio_buffer to give us a buffer if and only if there is an consumed buffer in the pool.
For example, our update_audio function might look something like this:
yeah that PWM code assumes 48Mhz clock and 22058Hz audio (I think it says that somewhere)... so of limited use (unless you can set your CPU frequency and PIO clock divider accordingly).
we are working on a new audio API (with parity across all audio types - i.e. run whatever freq you want) which will make its way into SDK at some point - somewhat of a replacement for these APIs.
Frankly on PicoSystem you can just use PWM and DMA to that (to get 8 bit audio).
We've been tinkering with audio on PicoSystem and in the case of at least PWM audio,
take_audio_buffer
never seems to return null, and never seems to stall for any length of time.In instances where we're naively calling an "audio_update" function at an arbitrary speed (too quickly in our case) this results in the audio engine getting clocked at some multiple it's intended speed, since we're relying upon
take_audio_buffer
to give us a buffer if and only if there is an consumed buffer in the pool.For example, our
update_audio
function might look something like this:And this would be called continuously in the main loop.
No matter how fast we run this,
if(buffer)
is always true.The text was updated successfully, but these errors were encountered: