Hi, spent the evening testing out the sdk and in particular the microphone callback using this function:
void playdate->sound->setMicCallback(AudioInputFunction* callback, void* context, int forceInternal)
I was testing using a known oscillator source and seems a bit random if the given data buffer in the callback function returns good expected values or sometimes about half of every other buffer filled with zeros. It seems that once you've managed to initialise it and it behaves well, it continues to behave well until you either lock the screen or go home and open up the app again. After that it usually starts returning mostly 0. But as I said, it is probably 50/50 if it returns good values from the start.
Simulator on Mac seems to handle the input better, however it crashes the simulator when going home.
Another issue I am having is getting the current headphone state. I've tried both supplying pointers or callback but the app never seems to detect when there is a headphone change. Whatever the app is initialised with that is the values it has throughout the session when detaching and attaching my headphones.
Do I need to call anything before calling?
void playdate->sound->getHeadphoneState(int* headphone, int* mic, int (*changeCallback)(int headphone, int mic))
From the doc it seems like it should be it, if I understand it correct.
I've been trying to reproduce your problems and haven't had much luck, though I've found a few other issues that might be related. Here's the test I'm using, with both Lua and C variants. Can you give these a try and see if they behave any better?
miccheck.zip (15.6 KB)
Cheers. That example seems to work fine, but I think it could maybe be related to this recording being so short. I start recording on the app opening and stop on it closing. I am happy to send my test project code to a private email if that would help. My main issues are:
Input buffers with large sections of zero values.
No change event when headphones are plugged in and out.
Unreliable detection of line input connected.
If you want an idea of what I'm trying to achieve, I uploaded a little video to youtube.
Thanks I really appreciate it!
I'd love to check it out, looks really cool! If you don't want to DM me here, you can email me at email@example.com. I haven't seen any problem with the headphone state change callback, though I have one device that reports a microphone on headphones that don't have them. It's an older device that's seen plenty of abuse, so I haven't looked too closely at that.
So is the audio on your YT vid straight out of the Playdate? And you have the OP-Z going direct to the mic pin, or do you have a DC-blocking capacitor there? I've wanted to try using Playdate as an effects box for a long time but never got around to it. I'm really excited to see someone else do it!
Also, did you know that your OP-Z and your Playdate were built right next door to each other at the factory in Malaysia?
Thanks, I’ll send you a DM, that’s perfect. I connected it to the playdate with one of these 4 pole splitters. Sorry about the Swedish there but you can see the image. Do you think I could have hurt my circuits if I sent in a bad signal testing it?
One observation with the line in, when it works it works great but sometimes I can hear both the microphone input and the line in, but the input callback only picks up the microphone signal. Not sure what that means but it happens occasionally.
I just realised something, I do get the headphone change event coming through, when I press and release the right arrow key. But nothing on the other buttons. Maybe there is something wrong with my unit?! Could there be a short on some of the pins perhaps?!
oh! I completely forgot about that bug. We fixed that 4 months ago but haven't been able to get an update out, for various reasons. We're just about ready, finally, but we're waiting until after the holidays when we're back in the office to push it. But at least now we know what's going on there.
I remembered today that I had made a mic->effects->speaker demo a while back, finally found where that was hiding. I'd planned to add that to the SDK, not sure why it's not in there yet. I haven't had a chance to look at your code yet, but here's this fwiw: SoundCheck.zip (8.0 KB)
Cheers for the example, it is very similar to my code, only yours doesn’t take into account for when the input buffer is a different size than the output buffer. This happens in the simulator at least where you get 512 in followed by two 256 out.
Your example though it is very clear that not the whole input buffer is filled with microphone data. A large chunk of it is always zero, see the image below.
Thanks, looking forward to some updates.
After looking at the code I see that the section at the end is expected from the way it is drawing the curve. However the sound behaves the same way as my code, missing sections of the input buffer resulting in audio glitches every other time you restart the app. Your example creates an interesting tone also after going to the lock screen and back.