ducalex / retro-go

Retro emulation for the ODROID-GO and other ESP32 devices
GNU General Public License v2.0
489 stars 114 forks source link

Audio driver for buzzer #123

Closed tomvanbraeckel closed 1 day ago

tomvanbraeckel commented 1 week ago

Here's my audio driver for the piezoelectric buzzer of the Fri3D Camp 2022 badge!

There is quite some code so I opted to put it in separate files, to keep rg_audio.c manageable.

The general working principle is described in rg_audio_buzzer.c

Audio quality is not too bad, for a buzzer.

There might be some tweaks or brilliant methods of improving the quality further, but I think this simple driver is a good baseline, with sensible, understandable parameters.

ducalex commented 6 days ago

Could you rename rg_audio_buzzer.[ch] to drivers/buzzer.[ch]? I think I'd prefer to keep only the main public library in the root folder. Over time we could split some more stuff to drivers too.

tomvanbraeckel commented 6 days ago

Could you rename rg_audio_buzzer.[ch] to drivers/buzzer.[ch]? I think I'd prefer to keep only the main public library in the root folder. Over time we could split some more stuff to drivers too.

Done!

ducalex commented 3 days ago

One last change I would request is that the entire buzzer.c be fenced by an #if RG_AUDIO_USE_BUZZER_PIN, so that it's not parsed/compiled if not needed/supported. I realize that the correct way would be to instruct the build system to take care of that, but for now adding those two lines seem easier than fighting cmake...

ducalex commented 3 days ago

Well actually if you prefer to do it the cmake way, that's fine by me. I just don't want to have to think about it myself, really.

tomvanbraeckel commented 2 days ago

Sure, pushed it!

ducalex commented 1 day ago

Sure, pushed it!

Thanks!

tomvanbraeckel commented 1 day ago

Sweet!!!

ducalex commented 11 hours ago

I'm working on refactoring the drivers. I had to make small changes to your driver, could you review and give me feedback as to whether I broke something or you think the design is bad or anything else before I merge it?

https://github.com/ducalex/retro-go/commits/audio-drivers-refactor/

tomvanbraeckel commented 3 hours ago

Looks good, although I should run it to know for sure :-) I can test it to confirm whenever you give me a heads up.

Reminds me of Linux device driver framework. Ideally this retro-go driver framework would be so similar to the Linux one that the drivers can easily be ported over. I guess this is a first step in that direction. Very cool!

From my brief scroll through, I noticed that the set_sample_rate() isn't working yet. I suspect you'll add some warning like "this is not supported" or better, a generic framework-level fallback to deinit() and re-init() with the new sample rate if no driver-specific set_sample_rate() is provided.