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?
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.
I'd love to check it out, looks really cool! If you don't want to DM me here, you can email me at dave@panic.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.
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.
Yey, I finally got the new firmware update. The good news is that headphone detection issue seems to be fixed in 1.13.0, which I am very thankful for. However, it seems performance have changed from 1.12.3 to 1.13.0 drastically and even with the beta 2 resulting in new glitches for me. Not sure if the priorities on some threads have changed maybe, I know we discussed it at some point.
I don't know I might give up this endeavour now, it was fun. I got close.
I thought I would write a little update of where we are with the issues raised in this thread. I got to play with the 1.13.2 beta, which showed no improvement in performance for me in the audio thread. That led me to look at my code more in the profiler, where I manage to make quite a few good optimisations and improvements. The end result is that 1.13.2 works great for me and in the future I know not to make my loops too big.
So, issue 2 and 3 are solved but issue 1 is still there.
1. Input buffers with large sections of zero values.
2. No change event when headphones are plugged in and out.
3. Unreliable detection of line input connected.
Many thanks for the update, it's a tremendous help not having to go back and figure out where things stand. I'll take a look at this now! My first guess is we're somehow getting out of sync with the circular DMA. We'll see..
oh man. I can't believe it took me all morning to track this down, but I finally got it. (Okay, sure, a lot of that was just goofing around with EKOEkoeko..) There's a bug in the pointer arithmetic when we're clearing the output buffer before rendering audio, causing it to run into the input buffer for the mic. If the input and output DMAs wind up timed wrong, that happens between when the data is received and it's sent out to your code. Once I figured out that it really was the input buffer data where the glitch was happening (very hard to debug because the DMA keeps running and overwriting the data even when the debugger is paused) all I had to do was set a watchpoint to see what was writing into the buffer.
Do you want me to put a build up on memfault for you to test out?
Done! I included this fix, also the one where we skip a frame instead of hanging when the audio task gets overloaded. Let me know if System Update doesn't see it, or if you have any problems with it. Thanks so much for your help!
Genius! Got it, restarted it 10-20 times before rushing off to my morning train and it seems rock solid now.
Thank you so much for this fix, but also thank you everyone involved in making this tiny machine. It has been really inspiring to play with, think about and design for a crank input.
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.
