Closed tomvanbraeckel closed 1 day 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.
Could you rename
rg_audio_buzzer.[ch]
todrivers/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 todrivers
too.
Done!
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...
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.
Sure, pushed it!
Sure, pushed it!
Thanks!
Sweet!!!
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/
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.
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.