If your guitar needs more distortion, lower audio fidelity, or another musical effect, you can always shell out some money to get a dedicated piece of hardware. For a less conventional route, though, you could follow [Brek Martin]’s example and reprogram a handheld game console as a digital effects processor.
[Brek] started with a Sony PSP 3000 handheld, with which he had some prior programming experience, having previously written a GPS maps program and an audio recorder for it. The PSP has a microphone input as part of the connector for a headset and remote, though [Brek] found that a Sony remote’s PCB had to be plugged in before the PSP would recognize the microphone. To make things a bit easier to work with, he made a circuit board that connected the remote’s hardware to a microphone jack and an output plug.
[Brek] implemented three effects: a flanger, bitcrusher, and crossover distortion. Crossover distortion distorts the signal as it crosses zero, the bitcrusher reduces sample rate to make the signal choppier, and the flanger mixes the current signal with its variably-delayed copy. [Brek] would have liked to implement more effects, but the program’s lag would have made it impractical. He notes that the program could run more quickly if there were a way to reduce the sample chunk size from 1024 samples, but if there is a way to do so, he has yet to find it.
If you’d like a more dedicated digital audio processor, you can also build one, perhaps using some techniques to reduce lag.
I would suggest a randomize all parameters button for chaotic exploration. Is JUCE, or puredata being used for the audio API? I could write this in C, but real-time audio is above my understanding currently. I can do nonrealtime processing of course
Tell me more.
Hi, Being a Playstation, there are SDK libraries for audio in and out. It depends what you call real time for the processing, you get 1024 samples at a time to deal with (the problem with lag is that I wish it could be less). I explained a couple of the effects as best as I could in the video without paper, and the source is linked in the description. ChatGPT was actually a big help with ideas an explaining things. I just haven’t had much luck with it in terms of getting it to create working code examples. It usually makes some silly mistakes a Human wouldn’t even look for. I’ve done a guitar tuner for the PSP since this, and given the lag of the effects, the tuner is probably more practically useful.
I’ve just taken a look at your code, but it looks like you’re requesting 1024 samples. You’ve renamed it to FRAME_SIZE, but it looks like the number of frames at a time that you’re asking for when you call pspAudioInputBlocking.
I’ve not got a PSP that I can test code on… and I’ve never written code for a PSP, but the library looks similar to other audio libraries that I have coded for.
Hi, FRAME_SIZE, is an alias for PSP_NUM_AUDIO_SAMPLES defined in the audio input library. That can actually be changed, but it would be out of step with the audio output buffer. PSP_NUM_AUDIO_SAMPLES is defined in pspaudiolib.h, part of the SDK.. .not in this distribution, but that define can be changed, but for me, changing it has no effect on the audio library behaviour for audio output, at least for me here. It still calls the audio output callback expecting 1024 samples to fill the audio buffer. If the audio input is is reconfigured for 512 sample chunks, then I get very fast buzzing/stuttering.
Ah yes, you’re so right. If I were you I’d modify the sdk so that you can pass a struct into the *pdata parameter of pspAudioSetChannelCallback with a customised number of frames. I expect that was the original intention for that pointer but it looks like they got by without implementing it.
How do you get the Guitar-in? Last I looked the PSP only had 3.5mm Headphone Out.
You’ll have to watch the video for that one, but the short version: There’s an audio input signal in the tiny edge connector next to the headphone socket.