AnyPS5/docs/dev/debt/libSceAudioOut.md

libSceAudioOut technical debt

Unknown function info

• sceAudioOut2ContextAdvance and sceAudioOut2ContextPush (libSceAudioOut) - with an SDL device, Advance snapshots each port's PCM and gain; Push consumes completed grains in order and a blocking Push waits for Advance when none is ready. Inferred from PPSA26358, which rewrites the same 512-frame, 12-channel float buffer on a producer thread and pushes on another thread. Console buffer ownership, snapshot timing and empty-queue errors are unverified. Completed grains remain queued until Push consumes them, so memory use grows with an unconsumed PCM backlog. The console backlog limit is unverified. A nonblocking Push without a completed grain throws; this is a runtime restriction, not a console measurement. Context destruction concurrent with active calls remains unsupported. Without an SDL device the existing wall-clock path remains.

• sceAudioOut2UserGetSupportedAttributes (libSceAudioOut) - the user handle and two uint32 output pointers follow SharpProspero and KytyPS5, not a console measurement. The masks describe this runtime: no context attributes and port attributes PCM (bit 0) and gain (bit 1). Null outputs and unknown or destroyed user handles throw; console validation order and error values are unknown. Users are tracked for this query, but port ownership and busy-user destruction are not implemented. The other PPSA23566 imports remain declared without parameters, with unknown signatures: sceConvertKeycodeGetCharacterFromKeyboardData, sce::Json::MemAllocator::notifyError, sceProprietaryVoiceChatHelper{Initialize,Terminate,SetVoiceChatState,GetVoiceChatUsageState}, sceVoice{GetResourceInfo,ResetPort,EnableChat,DisableChat}. Names from the shadPS4 aerolib NID list

• sceAudioOutExOpen, sceAudioOutExConfigureOutput, sceAudioOutExClose (libSceAudioOut) - the HDMI bitstream calls follow PS5-Audio-Passthrough-Research, which disassembles firmware 12.70's libSceAudioOut and logs the calls on a console. sceAudioOutExOpen(user, mode) returns 0x80260015 for a mode above 10 or outside mask 0x61F; otherwise it opens a port of internal type 6 in S16 stereo, 256 frames at 48000 Hz for modes 0, 1, 2 and 9 and 1024 frames at 192000 Hz for modes 3, 4 and 10. sceAudioOutExConfigureOutput(control, flags, mode, target, option) returns 0x80268009 when control is not 0, takes modes 0 to 10 and 0xFF and targets 1 to 3 and 0xFF, and returned 0 on the console; sceAudioOutExClose returned 0. The argument registers match Jelly5 and PPSA99051's bitstream_out.cpp. Audio reaches the host through SDL as PCM and the host has no HDMI bitstream output, so an Ex port has no host device: sceAudioOutOutput paces it at its own rate and drops its IEC 61937 bursts, and sceAudioOutExConfigureOutput changes nothing. Nonzero flags or option, other modes or targets, sceAudioOutExClose of a handle that is not an Ex port, and sceAudioOutGetPortState on an Ex port throw, since the console's answers are unknown

• sceAudioOutExGetMonitorInfo (libSceAudioOut) reports a sink without audio descriptors: it zeroes the buffer and returns 0, as sceAudioOutSysGetHdmiMonitorInfo does, since audio reaches the host through SDL as PCM and there is no EDID to describe. The arguments (0, 0, info, size) and the descriptor count as a 32-bit value at +0x98, with 8-byte descriptors from +0xA0, follow Jelly5 (PPSA99505), which passes a 0x400-byte buffer and read that layout from one TV; with no descriptor listed it decodes the audio itself instead of opening a bitstream port. The meaning of the first two arguments and the structure's size are unknown: nonzero first or second arguments and sizes below 0xA0, which cannot hold the count, throw, and every byte of the declared size is written as 0. A null buffer returns 0x80260004 like the other AudioOut calls; the console's code is not measured

• sceAudioOut2Set3DLatency (libSceAudioOut) - assumed to take (user_id, output): KytyPS5 reads (user_id, output, latency_us), but the known calls set just edi and esi. The validation follows KytyPS5: an output above 2 returns 0x80268001 and every user id is accepted, where before only (0xFF, 2) (PPSA26344) and (0xFF, 1) (PPSA14632) were; the latency value of the three-argument reading is never received, and there is no 3D rendering stage to apply anything to

• sceAudioOut2MasteringInit (libSceAudioOut) - flag values unknown; only 0 is accepted. Whether the console reports an error for a repeated sceAudioOut2MasteringInit or for sceAudioOut2MasteringTerm without a matching initialization is unknown; both return 0. PPSA01289 creates the audio device of its next world before it destroys the previous one, so it calls Init twice before Term twice, and only logs a non-zero result

• sceAudioOut2MasteringGetState and sceAudioOut2MasteringSetParam (libSceAudioOut) - the state layout, the states ids 1 (default) and 2 (V2), the descriptor ids 0x01010001, 0x01020001 and 0x01010003 and the errors 0x80268201 and 0x80268204 follow KytyPS5, not a console measurement. GetState zeroes the states and writes the two descriptors; with no mastering stage the compressor and limiter values stay zero. SetParam accepts any parameter set and records nothing, as KytyPS5 does; a null parameter returns 0x80268201, the mastering invalid-API-parameter error KytyPS5 returns for a null state, which is an inference rather than a measurement. The meaning of output and user is unknown and both are ignored

• sceAudioOut2SetSystemDebugState (libSceAudioOut) - records the debug state id in the trace and returns 0, as KytyPS5 does; the host has no system mix to apply it to. The debug state ids are unknown, so every id is accepted, and a null param returns 0x80260502 like the other AudioOut2 calls. Not measured on a console

• sceAudioOut2GetSpeakerArrayCoefficients (libSceAudioOut) - validates the handle and the coefficient count like the ambisonics call, then writes the front pair at full gain and silence for every other speaker, ignoring the position, spread, height awareness and downmix spread radius: KytyPS5 and prosper both return that pair. The console's VBAP gains over the array's directions are not measured

• sceAudioOutSetMixLevelPadSpk (libSceAudioOut) - effect of a negative mix level unknown; only 0 to 32768 (0 dB) is accepted

• sceAudioOutSetMixLevelPadSpk (libSceAudioOut) - no source applies the level (shadPS4 only stores it); it is assumed to be a linear gain on the port's own output, and the -9 dB default (11626) is applied to every pad speaker port, including those of titles that never call the function

• sceAudioOutGetLastOutputTime (libSceAudioOut) - signature and behaviour taken from the shadPS4 and fpPS4 reimplementations of the PS4 library, not confirmed on a PS5 title: the time is the process time at which sceAudioOutOutput or sceAudioOutOutputs accepted the port's last block, not the time the block reached the device

• sceAudioOutSysOpen, sceAudioOutSysConfigureOutput, sceAudioOutSysClose (libSceAudioOut) - imported by PPSA99051 and PPSA99997, which fail to load without them; the signatures follow EVO-PLAYER-PS5, whose audio code both titles share, and are not confirmed on a console. sceAudioOutSysOpen(user, mode) opens a port only for mode 5, the TrueHD MAT route: the same project's carrier table, read from sceAudioOutExOpen's own tables in firmware 12.70, describes it as a 768 kHz port of 1024 S16 8-channel frames whose 16-byte frames are consumed at 192 kHz; every other mode throws. Audio reaches the host through SDL as PCM and the host has no HDMI bitstream output, so like an Ex port a Sys port has no host device: sceAudioOutOutput paces it at its own rate and drops the MAT bursts. sceAudioOutSysConfigureOutput(type, flags, mode, target, option) accepts only the observed (1, 0, 5, 1, 0) HDMI MAT switch and changes nothing; other arguments throw. sceAudioOutSysClose closes a Sys port and throws for any other handle. The restore path EVO-PLAYER-PS5 takes after a Sys port calls sceAudioOutExConfigureOutput(0, 0, 0xFF, 0xFF, 0), so no Sys reset combination is known

• sceAudioOut2PortCreate (libSceAudioOut) - MAIN (type 0) format validation follows PS5 firmware 13.60 measurements: bits 8-11 accept 1, 2, 8 or 12, bits 0-6 accept 0 or 1, bit 7 requires 8 channels, and bits 12-31 do not affect validation. The sample types are still read as float and int16; bit 7's layout, the PCM effect of bits 12-31 and the port flags are unverified. Other port types retain unverified format validation, including 6 channels and rejection of bits 12-31

• sceAudioOut2PortCreate (libSceAudioOut) - 12 channels are assumed to be L R C LFE Ls Rs Lb Rb Ltf Rtf Ltb Rtb as in KytyPS5's 12-to-8 fold, and 6 and 8 channels to be its first 6 and 8; no title or SDK header confirms the order

• sceAudioOut2PortCreate (libSceAudioOut) - the stereo fold is assumed, not the console's downmix: C at -3 dB into both sides, Ls/Rs, Lb/Rb and Ltf/Rtf at -3 dB and Ltb/Rtb at -6 dB into their own side, LFE dropped

• sceAudioOut2PortSetAttributes (libSceAudioOut) - each PCM buffer set (attribute 0) is taken as one grain: buffers set between two pushes are queued and played one per grain, at most 16 queued. A grain with no new buffer repeats the last one only when the port has always been given that same buffer (rewritten in place); a port whose buffers move on plays silence instead. Inferred from PPSA12544, whose object port (type 6) is given one grain of a 64-grain ring per set, often two or three between pushes and then none for a few; the console behaviour for several sets per push and for a push without a new buffer is not documented

• sceAudioOutDeviceIdOpen (libSceAudioOut) - imported by PPSA01317, which fails to load without it; declared without parameters, signature unknown. It opens a port on a given audio device; which device ids exist and how they map to host outputs is unknown, so it throws

• sceAudioOut2PortGetState and sceAudioOut2GetSpeakerInfo (libSceAudioOut) - the port state reports the channel count of the port's data format, output main, volume 127 and a zero reroute counter and flags; the speaker info reports a stereo front pair at -30 and +30 degrees. Taking the channel count from the data format follows SharpEmu, another emulator, and no console measurement exists for either call: the output of a pad port, the volume after sceAudioOut2PortSetAttributes and the reroute counter on a device change are unverified, as are the speaker types other than stereo. ASTRO BOT and ASTRO's PLAYROOM reportedly stop on an assertion that depends on these values (#4317), but which field matters has not been isolated

Functional

• sceAudioOut2EnableChat (libSceAudioOut) takes no arguments and returns 0, as declared by SharpProspero ("Allows chat audio alongside the application's own"). The host mixes no chat audio and AudioOut2 has no chat port, so the call only records that chat audio is allowed. Whether the console fails it without a chat session, when repeated or before sceAudioOut2Initialize is unknown. sceAudioOut2DisableChat is the counterpart, imported by PPSA18216: it takes no arguments, returns 0 and records that chat audio is no longer allowed; its signature is not confirmed by a console measurement, and whether the console fails it without a chat session or when repeated is unknown.
• sceAudioOut2Set3DLatency and sceAudioOut2MasteringInit, sceAudioOut2MasteringTerm and sceAudioOut2MasteringSetParam (libSceAudioOut) have no effect: there is no 3D rendering or mastering stage. SetParam accepts the parameter set, and SetSystemDebugState records the debug state id, without anything to apply them to.
• AudioOut2 contexts (libSceAudioOut) with an SDL device and no sceAudioOut2ContextAdvance calls read a grain's port buffers at the next push, at least 100 us after the grain was pushed, and play the mix behind a 40 ms cushion that the queue level leaves out. When the hardware reads the buffers is not known. The timing follows a title whose mixer fills a buffer after pushing it, reuses it two pushes later, and may still be writing it when the next push follows within microseconds. The last grain pushed before a title stops pushing is never read or played.
• sceAudioOut2ContextGetQueueLevel (libSceAudioOut) with an SDL device counts the grains that sceAudioOut2ContextAdvance completed and no push has consumed as queued, together with the pushed grains beyond the 40 ms cushion, up to queue_depth. Whether the console counts them is unknown. Pushes that fill the cushion leave the level at 0, so a title that renders as many grains as the level leaves room for and pushes them on another thread rendered a full queue again after each of those pushes: PPSA23226's Wwise sink passes the available count to the sound engine as the number of frames to render, advances once per frame and pushes on a separate thread, and exceeded 16 completed grains. Counted, the completed grains keep such a title at most queue_depth grains ahead of its pushes.
• sceAudioOutSysGetHdmiMonitorInfo (libSceAudioOut) reports an HDMI sink without a monitor name or audio descriptors: it zeroes the 0x180 bytes and returns 0, since audio reaches the host through SDL as PCM and there is no EDID to describe. The arguments (type, info, size), the required size 0x180 and the fields titles read (monitor name at +0x0B, 13 bytes; descriptor count as a 32-bit value at +0x94; 8-byte descriptors [coding type, channels, rate mask, 0, extra, 0, 0, 0] from +0x98) come from PS5-Audio-Passthrough-Research (firmware 12.70, one monitor). What a console without an HDMI audio sink returns, an error or no descriptors, is unknown. The other bytes, among them the header at +0x90 (01 09 4f 00 on that monitor), have no known meaning and are written as 0. No LPCM descriptor is reported for the host device, as the rate mask and extra byte of one are not known. A null buffer returns 0x80260004 like the other AudioOut calls; the console's code is not measured. Monitor type 0x10, which the console also accepts, other types and sizes other than 0x180 throw: their results and error codes are unknown.