TRS (phone jack) plugged + Speaker sound output possible?

[Raphael]

I've got a question to the ones that have a better insight into the firmwares/hardwares functionality.
Currently, as soon as the headphones or another device gets plugged in the sound output of the PSP gets forwarded to the TRS and the PSP is silenced if that device is not a speaker/headphone.
What I'd like to know is if there is any possibility of preventing this in software or if this is completely a hardware circuitry that is responsible.

Thanks in advance.

[BenHur]

I don't have insight into firmware/hardware functionality, but know of this thread:
http://forums.ps2dev.org/viewtopic.php?t=8732

Hope it helps, BenHur

[Raphael]

Thanks, somehow I missed that thread when searching. Seems that adrahil failed when trying to provide a software solution and chopping off the Tip of the phone jack is the easy hardware solution.
That could work out, though I'd have preferred a software solution (gonna ask adrahil when I see him).

[gambiting]

Thanks, somehow I missed that thread when searching. Seems that adrahil failed when trying to provide a software solution and chopping off the Tip of the phone jack is the easy hardware solution.
That could work out, though I'd have preferred a software solution (gonna ask adrahil when I see him).

There was such thread on this forum,someone had a working code to check if earphones were plugged in,if yes then he routed sound to speakers.I can't find it now,but I'm 10000% sure that's possible using software.

[deniska]

check the latest (0.520) version of MapThis.. it does it if ran on 3.xx firmware..
The source code is included with the release..

[KickinAezz]

check the latest (0.520) version of MapThis.. it does it if ran on 3.xx firmware..
The source code is included with the release..

I got a problem. FW Reference: 3.71M33.

I use sioInit(510416 or any baudrate); It allows us to USE SPEAKERS even if anything is plugged into a Remote port/headphone port. Good.

BUT
After the Sio is initialized and Speakers are still enabled

pspDebugSioPutchar(0x31 suppose);
sioReadChar(); These fail to work even if device is plugged in.

However,
I am able to read the SIO data if any sio device is plugged in before sioInit(baudrate); has initialized.

Any ideas? and I'm refering to the Neo Motion Kit.

On which FW has Mapthis been tested?

[KickinAezz]

[CONTINUED, add to HOWEVER sentence above] but Speakers are disabled.

[deniska]

I have not tried to write to sio - have no need for that..
Reading seems to work ok though.. I have no problems plugging in/out the gps receiver on my M33 - 3.71-2 slim psp..
You can probably detect whether the plug is in/out and re-init the port if that status changes..

[Raphael]

deniska: As I see it, the code in mapthis works by overriding the interrupt handler *before* something is plugged into the jack, hence speaker sound output isn't overridden, correct? Well, the problem in my case is, that I cannot just override the interrupt handler as I need to stay compatible with sceHprm, so I cannot shutdown the hprm driver but rather need to work around it. Do you by any chance know the exact event (state?) that handles the sound routing?

I also tried handling the audio output with sceAudioRouting from sceImpose, but that doesn't seem to be the right thing. Anyone knows it's purpose?

[KickinAezz]

I have not tried to write to sio - have no need for that..
Reading seems to work ok though.. I have no problems plugging in/out the gps receiver on my M33 - 3.71-2 slim psp..
You can probably detect whether the plug is in/out and re-init the port if that status changes..

I have tried re-sioInit(baudrate)ing... but nuh-in :(

Any ideas?
--
One more important thing to notice: Re-initializing seems to work with "REGULAR" "Speaker Disabled" method but not with this...

[adrahil]

Thanks, somehow I missed that thread when searching. Seems that adrahil failed when trying to provide a software solution and chopping off the Tip of the phone jack is the easy hardware solution.
That could work out, though I'd have preferred a software solution (gonna ask adrahil when I see him).

Yeah, mea culpa maxima ;) I didn't find a correct way to make the sceAudioRoutingSetMode function work. However I am 100% sure it is the one which allows audio to be output from the speakers while the jack is plugged in. If you want to try and poke it around, it's in sceImpose

[Raphael]

Thanks, somehow I missed that thread when searching. Seems that adrahil failed when trying to provide a software solution and chopping off the Tip of the phone jack is the easy hardware solution.
That could work out, though I'd have preferred a software solution (gonna ask adrahil when I see him).

Yeah, mea culpa maxima ;) I didn't find a correct way to make the sceAudioRoutingSetMode function work. However I am 100% sure it is the one which allows audio to be output from the speakers while the jack is plugged in. If you want to try and poke it around, it's in sceImpose

I already poked around there and went disassembling the code for the audio routing functions. However, as stated, they didn't seem to have any effect, neither does the normal firmware seem to change the audio routing mode (either that or the firmware denies me getting the correct result from sceAudioRoutingGetMode - maybe I should add K1 set/reset around the function calls?).

Code: Select all

int sub_000044B8( int a0 )
{
	v0 = 0x802C0000;
	v1 = &#40;a0<2?1&#58;0&#41;;
	s4 = 0x10000;
	s3 = a0;
	s1 = v0 | 0x01FE;
	if &#40;!v0&#41;
		goto loc_00004534;

	a1 = _lw&#40;s4-4040&#41;;
	s1 = a0;
	a0 = _lw&#40;a1+72&#41;;
	v0 = s1;
	if &#40;a0==s3&#41;
		goto loc_00004538;

	s2 = k1;
	k1 >>= 16;
	v0 = sceKernelCpuSuspendIntr&#40;&#41;; //InterruptManagerForKernel_092968F4&#40;&#41;;
	v1 = _lw&#40;s4-4040&#41;;
	s0 = v0;
	a0 = 32;
	s1 = _lw&#40;v1+72&#41;;
	_sw&#40;s3,v1+72&#41;;
	sub_00000000&#40;&#41;;
	a0 = s0;
	sceKernelCpuResumeIntr&#40;a0&#41;; //InterruptManagerForKernel_5F10D406&#40;&#41;;
	k1 = s2;

loc_00004534&#58;
	v0 = s1;

loc_00004538&#58;
	return v0;
&#125;

// sceAudioRoutingSetMode
int sceAudioRouting_36fd8aa9&#40; int a0 &#41;
&#123;
	return sub_000044B8&#40; a0 &#41;;
&#125;

// sceAudioRoutingGetMode&#40;&#41;
int sceAudioRouting_39240E7D&#40;&#41;
&#123;
	a0 = _lw&#40;0x10000-4040&#41;;
	return _lw&#40;a0+72&#41;;
&#125;

I didn't go further on cleaning up the register usage to common C code and disassembling sub_00000000 after it seemed my guess about those functions was wrong. Now since you however strongened my believes I might go on in this direction and try to dig deeper.

[adrahil]

Well, you can just see.... The audiorouting setmode function just sets a 0x20 event flag in sub_00000000 and passes some params. This would not be suspicious if the HPRM connect handler in impose.prx didn't do the same ;) So I think something is wrong in the way it is called - maybe it doesn't like us or something like that. However, tracing it into the only sceKernelWaitEventFlag-using function, you get some calls to sceVaudio and sceCodec :) (I didn't get into detail, as I believe something CAN be done with sceAudioRouting...)


P.S. Better version of code:

Code: Select all

#define routing_mode *(*(0x10000-4040)+72)

int sub_000044B8(int mode){
  if (mode >= 2) return 0x802c01fe;
  if (routing_mode==mode) return mode;

  old_k1 = pspSetK1(pspGetK1()>>16);
  old_intr = sceKernelCpuSuspendIntr();
  
  //save old mode for return value and set
  //the new value which will be updated at
  //event flag handling.
  old_routing_mode = routing_mode;
  routing_mode = mode;

  //send the routing mode change event.
  sub_00000000(0x20);

  sceKernelCpuResumeIntr(old_intr);
  pspSetK1(old_k1);

  return old_routing_mode;
} 

[Raphael]

Well, you can just see.... The audiorouting setmode function just sets a 0x20 event flag in sub_00000000 and passes some params. This would not be suspicious if the HPRM connect handler in impose.prx didn't do the same ;) So I think something is wrong in the way it is called - maybe it doesn't like us or something like that. However, tracing it into the only sceKernelWaitEventFlag-using function, you get some calls to sceVaudio and sceCodec :) (I didn't get into detail, as I believe something CAN be done with sceAudioRouting...)


P.S. Better version of code:

Code: Select all

#define routing_mode *(*(0x10000-4040)+72)

int sub_000044B8(int mode){
  if (mode >= 2) return 0x802c01fe;
  if (routing_mode==mode) return mode;

  old_k1 = pspSetK1(pspGetK1()>>16);
  old_intr = sceKernelCpuSuspendIntr();
  
  //save old mode for return value and set
  //the new value which will be updated at
  //event flag handling.
  old_routing_mode = routing_mode;
  routing_mode = mode;

  //send the routing mode change event.
  sub_00000000(0x20);

  sceKernelCpuResumeIntr(old_intr);
  pspSetK1(old_k1);

  return old_routing_mode;
} 

Yeah, that code is much cleaner :) As said, I didn't care too much after my initial intention failed and it would have taken me much longer to clean up than you anyway.

After checking out the sce_Codec functions following the WaitEventFlag, the first one just sets the Output volume of the WM audio chip, however, the following sce_Vaudio function is still unknown in purpose (no name). It's probably just another volume setting function though, seeing how Vaudio is only responsible for handling audio playback within videos (wrapper for generic sceAudio probably).
The second sce_Codec function however, sceCodecOutputEnable, sounds interesting. It obviously enables sound output, meaning there could be an option to also set the output direction (sceCodecOutputEnable doesn't take any parameters though and sceCodecOutputDisable is never called either).
The only other import from sce_Codec is sceCodec_driver_20C61103 (another unknown function) and gets called within sceImposeSetParam. Could there be a sceImpose parameter that is responsible for the actual routing?

[KickinAezz]

ooh. some progress :)

Wish I were more into hardware stuff.

[crazyc]

The wm8973 datasheet is a good place to look for info. It looks like the speaker (fat psp) is connected to the L/ROUT2 pins of the codec and the headphone is connected to L/ROUT1. By that nid 6D945509 is sceCodecSetHeadphoneVolume and nid 40D5C897 is sceCodecSetSpeakerVolume.

[Raphael]

The wm8973 datasheet is a good place to look for info. It looks like the speaker (fat psp) is connected to the L/ROUT2 pins of the codec and the headphone is connected to L/ROUT1. By that nid 6D945509 is sceCodecSetHeadphoneVolume and nid 40D5C897 is sceCodecSetSpeakerVolume.

Don't know about the second function, but silverspring.lan.st says:
0x6D945509 sceCodecNotifyAvcKick

I'm gonna check out 40D5C897 though :)

[KickinAezz]

The wm8973 datasheet is a good place to look for info. It looks like the speaker (fat psp) is connected to the L/ROUT2 pins of the codec and the headphone is connected to L/ROUT1. By that nid 6D945509 is sceCodecSetHeadphoneVolume and nid 40D5C897 is sceCodecSetSpeakerVolume.

Don't know about the second function, but silverspring.lan.st says:
0x6D945509 sceCodecNotifyAvcKick

I'm gonna check out 40D5C897 though :)

I donot see such a nid in any libdocs. link?

---
Time to add my findings:

Killing the SceAudio EventFlag disables Audio totally. So SceAudio event flag is something very important!

[crazyc]

Don't know about the second function, but silverspring.lan.st says:
0x6D945509 sceCodecNotifyAvcKick

That nid isn't right. The function definitely sets the LOUT1 and ROUT1 volume registers in the codec. It looks like the outputs are enabled and disabled in sceCodecOutputEnable. The prototype appears to be:

int sceCodecOutputEnable(int enable_headphone, int enable_speaker);

I think i know what the rest of the nid's do but not what they are called.

3064C53D, sets the automatic level control for the mic
56494D70, sets the bass level
4515AE04, transforms it's parameters and calls 56494D70
20C61103, toggles mute (maybe?)

[KickinAezz]

Don't know about the second function, but silverspring.lan.st says:
0x6D945509 sceCodecNotifyAvcKick

That nid isn't right. The function definitely sets the LOUT1 and ROUT1 volume registers in the codec. It looks like the outputs are enabled and disabled in sceCodecOutputEnable. The prototype appears to be:

int sceCodecOutputEnable(int enable_headphone, int enable_speaker);

I think i know what the rest of the nid's do but not what they are called.

3064C53D, sets the automatic level control for the mic
56494D70, sets the bass level
4515AE04, transforms it's parameters and calls 56494D70
20C61103, toggles mute (maybe?)

Man you are genius.. CodecOutputEnable works! [atleast in vsh; will try sio asap]
Thaanks!

[Raphael]

Don't know about the second function, but silverspring.lan.st says:
0x6D945509 sceCodecNotifyAvcKick

That nid isn't right. The function definitely sets the LOUT1 and ROUT1 volume registers in the codec. It looks like the outputs are enabled and disabled in sceCodecOutputEnable. The prototype appears to be:

int sceCodecOutputEnable(int enable_headphone, int enable_speaker);

I think i know what the rest of the nid's do but not what they are called.

3064C53D, sets the automatic level control for the mic
56494D70, sets the bass level
4515AE04, transforms it's parameters and calls 56494D70
20C61103, toggles mute (maybe?)

Thanks crazyc, the sceCodecOutputEnable really does it's job. However, the firmware seems not to be able to override the settings itself later on (ie nothing is changed when a real headphone is plugged in and sceCodecOutputEnable isn't called). It's not a problem as that can be solved by adding my own headphone output enable call, but makes me wonder what the firmware does if not use that function :)
Again, thanks a lot crazyc and adrahil, you helped a lot.

[SilverSpring]

0x6d945509 sceCodecSetHeadphoneVolume
0x40d5c897 sceCodecSetSpeakerVolume

Also yea Ive tried to remove as many false positives from the site, but there of course will still be a few (usually dont want to remove it until it's confirmed to be false).

EDIT:
*oops nvm*
it seems crazyc already posted them above:

0x20c61103 could be sceCodecSelectVolumeTable