[Addition] Separate Audio channels for Headset and Speaker

Recently been experimenting on audio data transmission and discovered I am unable to force unique audio separately from speaker or headset. They will play the same audio.

My request for the SDK is to have a toggle between Duplicate Audio or Separate Audio for Speaker and Headset. That way for example you can have two sound sources while listening to music. UI sound effects for the system speaker and the music playing through the headset / audio jack. (Media Player).

I would like to do this for my recent development on Link Cable games for Playdate using old fashioned DSL.

I also would like forced volume as an option too since even volume is controlled entirely by the system os.

Much love to Panic for keeping up the amazing updates. :playdate_heart:

1 Like

Is this a hardware limitation? It's a really cool idea, but I would have assumed that the headphone jack and speaker circuits are both simply connected to audio master out, and the SDK just exposes muting for each circuit.

I guess you could play different audio at the s/w level depending on whether headphones jack has something plugged in, or you could give the player the ability to switch back and forth between both speakers to listen to different audio for some game purpose, which could be fun. But I wonder if separate, simultaneous output between jack and speaker is possible.

For the record, if it is possible, then I would also love this feature.

1 Like

As further research suggests, it turns out that the chip responsible for audio does infact not separate the audio.
Which means it is entirely impossible to request what I am requesting even if it is panning the audio on both speaker / headset. Which completely destroyed my plans for my project.

1 Like

Nice find. That's unfortunate, though...

I wonder if the Playdate is fully interfaced with the USB-C port? I guess it's a stretch, but if the API someday allows us to interact with devices connected to the USB port, then we could in theory have access to additional speakers, microphones, and even displays. But I don't have any intuition of the overhead for running those devices.

On the other hand, for all I know the Playdate might only be capable of using the USB port for charging and COM ports.

EDIT: I noticed your other, long-running thread about data transmission via the headphone jack, and I think I understand your goals a little better now (although I didn't read the whole thing). If the goal is data rather than audio, I wonder if the USB port could just be leveraged for this instead (COM ports). Was there a certain reason that the data absolutely must be fed through the audio circuits, or were you only looking for a way to achieve a game-link type of connection?

1 Like

Yes, the plan was to send any sort of data / communication to another Playdate without the need of a internet server. I was originally making a bunch of games based around not knowing what your friend is playing or doing while you do the same. GameBoy Link Cable came to mind when starting work on my own Playdate projects way back then. Unfortunately, Panic has yet to implement any sort of communication to another system that can be achieved via software thats not on Catalog. (Highscores basically). My hope is that the audio could be the closest to an official link cable and while that is very true... Having the system mute during the entirety of the game just sucks. Either someone is able to change the panning of both the system speaker and headset or Panic implements it to the OS. I would then consider to continue along with my projects It isn't worth doing them now (and funnily enough when I was on the Developer Preview) or 2 years ago.

Apparently, at one point, audio playback through the speaker only used the left channel. See Internal speaker is left audio only - #3 by GuyPerfect for details. I think it'd be possible to use the left channel for music and the right channel for data if Panic added an option to disable the stereo to dual mono mixing.

You should be able to test this behavior by rebooting into recovery mode. As far as I can tell, the recovery firmware is version 1.11, whereas the mixing was added on 1.13.