libatrac3plus picks the codec parameter from the frame size and the
header's joint stereo flag, and the channel count plays no part. We
guessed joint stereo from the frame size and channel count instead, so
LocoRoco 2's MuiMui house music never started: the game writes a 2-channel
normal-stereo header for every track it streams, and that 0xC0 track holds
one mono sound unit per frame. Taken as joint stereo, its first frame failed
during setup, and the game retried forever.
Now the joint stereo flag comes from the track header, and the decoder's
channel count from the parameter it maps to, so that track decodes as mono
into both output channels, as on hardware. Low-level decoding, which has
no header, still goes by the frame size. Atrac2 saves the flag; older
states fall back to the guess.
Fixes#8647.
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
Setting data decodes and throws away the frames before the first sample,
so on hardware it costs a decoder setup plus that decode, with the caller
waiting: ~900us for mono Atrac3 and ~3.5ms for stereo Atrac3+, whatever the
buffer size (pspautotests threads/scheduling/callcosts). It was charged
100us.
Decoding a frame now costs what the same frame costs through
sceAudiocodecDecode, through the shared ME queue, instead of a flat
2300us. That's about the same for stereo Atrac3+ and less for Atrac3
(685us mono, ~1100us stereo). The first Atrac3+ frames after setup still
come out ~500us short.
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
Measured on a PSP (pspautotests video/mp4/mp4timing, audio/audiocodec/timing):
- sceVideocodec Open, GetEDRAM, GetVersion and ReleaseEDRAM take ~70-150us,
Init ~26.6ms (sceMpegCreate is 27-28ms), Delete ~21ms (was 2ms), and
Stop 132us with nothing held back. All go through the ME queue now.
- Decodes that return no picture take as long as those that do; they
were free.
- Open reports the EDRAM the decoder needs (0x3c2c) at ctx+0x18, which
mpeg.prx passes on to GetEDRAM.
- sceAudiocodec: failed decodes (214/142/169us) and mono Atrac3+ init (524us).
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
Checked against pspautotests audio/audiocodec, recorded on a PSP.
- Atrac3+: at3Related selects headered (mpeg.prx) or raw (libatrac3plus)
frames, instead of sniffing for the sync word. The header's size field
is 10 bits, as the context's. Header errors 0x211/0x213, bad frames
0x20a, all returning SCE_AVCODEC_ERROR_INVALID_DATA with nothing read.
- The first successfully decoded Atrac3+ frame, and the first two AAC
frames, produce no output. Checked sample-for-sample against hardware.
- Atrac3: the parameter at 0x28 selects the frame layout, as
libatrac3plus.prx's table maps it. We used to read its low bit as a
joint-stereo flag, which decoded mono (0x0F) streams as stereo garbage.
AtracCtx2 had the table's fields swapped the same way.
- at3_standalone's Atrac3 output was inverted relative to the PSP's
(sceAtrac too). Negate the IMDCT scale.
- CheckNeedMem sizes (AAC is 0x658c), codec 0x1004/0x1005, Init
validation (AAC sample rate, Atrac3 parameter, Atrac3+ channels), and
ReleaseEDRAM clearing edramAddr.
- Every call that reaches the ME now blocks for its measured time, and
decode time is modelled per codec and frame size.
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
Missing sections (videocodec, audiocodec, aac, mp3) and old-version
branches (impose, io, umd, gps, mic, display, font) left the session
before the load in place.
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
They were recreated without block size or extradata, which Atrac3 needs,
so it stayed silent after a load. Also drop the old decoders when the
state has none, and don't overflow on v1 states.
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
The SAS mix estimate was a guess capped at 1200us. Measured on a PSP
(pspautotests audio/timing/sastiming), a mix costs 110us plus 0.49us per grain
sample, plus per voice and sample 0.445us + 0.0675us per unit of pitch ratio
(VAG; PCM and noise slightly less), plus 0.64us per sample with a reverb type
set. Linear to 1% across 64-2048 samples and 0-32 voices: 32 VAG voices at 512
samples take 8.7ms, not 1.2.
The mix runs on the Media Engine, as do video and audio decoding, so they now
queue behind each other there (MEScheduleJob). A game that keeps SAS running
during a movie - Star Wars: Lethal Alliance - decodes more slowly for it, like
on hardware.
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
Measured on a PSP (pspautotests gpu/timing/blittiming), a full-screen blit
from an unswizzled texture costs what the texture fetch costs: 16-bit formats
half of 32-bit, VRAM a fifth of RAM, and rectangles wider than ~128 texels
~7.5x as much as narrow strips, from texture cache thrashing. Framebuffer
format, filtering and blending don't matter. Ys I & II draws its movie as one
full-width sprite from a 565 texture in RAM, which takes 33ms - that, not the
decode, is what holds it to 30 fps.
All of the ME and GE costs speed up with the clock (2/3 as long at 333/166),
since the whole system runs from the one PLL.
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
sceMp4AacDecode of an AAC-LC stereo frame takes about 1.7ms on a PSP, measured
with pspautotests video/mp4/mp4timing.
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
Movie players like the one in Star Wars: Lethal Alliance present every decoded
frame after a single vblank wait, with no clock or timestamp check, so the
frame rate depends on decode, CSC, ATRAC decode and the GE blit adding up to
more than a vblank. We charged nearly nothing for any of them, so such movies
ran at 60 fps until the ringbuffer's slack ran out.
Costs measured on a PSP with a copy of that player (pspautotests
video/mpeg/playertiming), for a 480x272 frame:
- sceVideocodecDecode: 3.4ms (sceMpegAvcDecode 5.8ms less sceMpegAvcCsc 2.4ms)
- sceMpegBaseCscAvc: 2.4ms, was a flat 4ms
- sceAudiocodecDecode, ATRAC3+ only: 2.5ms per frame
- GE: 9.7ms for a through-mode rectangle blit from a decoded video frame,
charged by area, only for textures in the buffer a decoder last wrote.
GE time also now carries across stall address updates. Before, a list sent
in stalled chunks only had its last chunk's time counted, so sceGeDrawSync
returned 39us after a blit that takes 9.7ms. This affects every game that
builds its lists incrementally, so GE-timing-sensitive games need checking.
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
--disable-hle had no counterpart, which made "is this our fault or the game's?"
awkward to answer: the only ways to put our HLE back were a per-game config or
hiding the firmware, and neither works from a script - the setting is per-game
and the firmware gets found anyway. --force-hle takes the same bitmask and runs
our HLE for those libraries even where the real module is now the default, so
the same repro can be run both ways and the logs diffed.
Used it on the warnings left over in Tekken 6 under the real mpeg.prx. Three of
them appear identically with --force-hle=16, so they are the game's own and
match what the hardware answers: sceKernelChangeThreadPriority(-1) eight times
in a row (pspautotests/threads/threads/change says hardware returns
UNKNOWN_THID for -1 too), sceAtracAddStreamData on a released id with a zero
byte count, and a sceKernelDeleteMutex on a garbage id.
The fourth only happens under the real module and is ours. mpeg.prx sizes its
allocation through a scratch context in its own bss and calls
sceAudiocodecReleaseEDRAM on that one, while decoding through a different
context that never gets released - so the next movie's sceAudiocodecInit finds
a live decoder and replaces it. That is once per video on every game running
the real module, and it was a WARN_LOG_REPORT, so it would have reported from
everyone's machine. It is bounded - removeDecoder deletes the old one and Init
makes exactly one more - so it is an INFO_LOG now.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Both of these fire once per video in Tekken 6, and neither is a fault.
sceAudiocodecReleaseEDRAM warned "failed to remove decoder" whenever there was
no decoder to remove. There usually isn't: mpeg.prx calls CheckNeedMem and
GetEDRAM to size the allocation, and only creates a decoder if the stream turns
out to need one, so releasing without ever having made one is the normal path.
Demoted to debug.
While there, its signature was one argument too long. audiocodec_260.prx's own
sceAudiocodecReleaseEDRAM (080007c0) reads only a0 and sets up a1 through a3
itself, so the "id" we took was whatever the caller happened to leave in the
register - which is how the log came to show an sceMpeg error code as the
second parameter of an audio call.
sceUtilityLoadModule logged MODULE_ALREADY_LOADED at error level. It is a
normal answer that games rely on: Tekken 6 asks for av_avcodec three times and
never unloads it, ignoring the result each time. Only that one code is demoted;
everything else from a module load is still an error.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
The field at 0x24 is a byte count, like srcBytesRead next to it, and
sceAudiocodecGetOutputBytes describes the same quantity the same way (0x1200
for MPEG1 MP3). We were putting the sample count there, a quarter of the value,
and libmp3.prx takes it as the length of the PCM to pass on. Renamed to
dstBytesWritten so it reads like what it is.
Nothing on our side consumed the field, so this only changes what the firmware
modules see. mpeg.prx ignores it, which is why Atrac3+ playback was unaffected
either way, but libatrac3plus.prx does read it.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
sceAudiocodecInit puts 9999 in the version field to mean "not known yet", and
filling it in is what this call is for - libmp3.prx reads it straight back out.
We wrote every other MP3 field and left that one alone, so the real libmp3.prx
got as far as GetInfo and then stopped without ever asking for a decode.
While here, read the fields off the frame rather than claiming 128kbps 44.1kHz
stereo unconditionally, which is what the hardware does with them. They are the
raw MPEG header fields apart from the version index, which has its own
numbering. The old fixed values stay as the fallback for when there is no
readable frame to look at.
Also carries a CheckNeedMem log tweak that was already in the tree.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
sceMpeg and sceAudiocodec only cleared their context maps on shutdown, while
sceMpegbase and sceVideocodec clear theirs on init. Both maps are keyed on an
address the game chooses, and getMpegCtx reads its key straight out of game
memory, so anything left behind can be handed to the next game we run in the
same session. Clear them on init as well. sceVideocodec's init cleared its map
without deleting the decoders in it; use ClearContexts for that.
Headless never loads a config file, so every g_Config field it doesn't set
keeps the zero-initialized value rather than the ConfigSetting default.
bFuncReplacements is one of those, so headless was the only build running games
without function replacements - which is why a crash in Jak and Daxter's
memcpy_jak wouldn't reproduce there.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
sceAudiocodecCheckNeedMem set neededMem for every codec except AAC, where it
was left at whatever was in the context. Set it to 0x18f20 like the others; our
faked ME memory meant this never blocked, but a game that validates it could.
Also name the two hash-named sceVideocodec exports from their firmware
behaviour: 0x893B32B1 configures the codec during sceMpegCreate in mode 1
(SetMode), and 0xD95C24D5 copies a decoded YCbCr frame between buffers via the
ME (CopyYCbCr), the videocodec-level counterpart of sceMpegBaseYCrCbCopy. Both
are still stubs - only mpeg.prx calls them, on paths nothing we run reaches -
but they are now documented for whoever implements them.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
CalculateInputBytesAndChannelsAt3Plus only set the frame size for the four
bitrates it had a table entry for and left it at 0 otherwise, which fails the
decode - the same shape of bug the AAC path just had. formatByte2 * 8 + 8 is
the size for all four known bitrates, so use it for the rest too; the firmware
never returns 0 here. The common PSMF path is unaffected: it takes the size
from the frame's own header before reaching this.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
The AAC decode path read the frame size from srcBytesRead, which is an output
field the decoder writes - it's 0 on the first call, so the decoder was handed
0 readable bytes and audio never started. avcodec.prx's decodeUtility sizes the
AAC input from the byte at 0x2c instead: 0x609 when nonzero, 0x600 when zero.
Investigated after report by sum2012 in #16238. Not actually tested yet.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
For a frame that still has its PSMF header, the length comes out of the header
itself, so it's only as trustworthy as the stream - up to 2816 bytes read from a
pointer where only the first four had been checked. Validate the span, and use
IsValidRange rather than a range accessor, which raises a memory exception
instead of returning null.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Three bugs stacked on top of each other, all of them silent - the decoder
happily returned 2048 samples of digital silence 878 times per movie.
sceMpegBasePESpacketCopy gathered the scatter-gather blocks but never performed
the copy. That was fine for video, whose destination is Media Engine memory we
can't write anyway and which we intercept instead, but audio is copied into
main memory and mpeg.prx then hands that same address to sceAudiocodecDecode as
its input. It was reading a buffer nothing had written.
With real data arriving, the Atrac3+ frames turned out to still carry their
8-byte PSMF header - libatrac3plus.prx strips it before calling us, mpeg.prx
leaves it on for the hardware to parse. Detect the 0x0FD0 sync word and step
over it, taking the frame size from the header the way MpegDemux already does
on the HLE path.
Finally, rebuild the decoder if the frame size only becomes known at the first
decode: the context has no size in it at init time, and a decoder built for a
zero-byte frame decodes nothing.
Also corrects a comment claiming mpeg.prx passes zeroed Atrac3+ format bytes.
It doesn't - they were zero because of the missing copy above.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
avcodec.prx's sceAudiocodecCheckNeedMem validates the codec id and the pointer,
sets the magic and forwards to the ME. It never looks at the format bytes, and
the caller isn't obliged to have filled them in yet - the real mpeg.prx calls it
with both still zero, and our invented check stopped its audio dead with
SCE_AVCODEC_ERROR_INVALID_DATA.
Now just a warning when they aren't the pair libatrac3plus writes, which is
still worth knowing about.
Found by running the real mpeg.prx against our sceAudiocodec, which is exactly
what that reference is for.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
me_wrapper.prx's dispatch table gives 0x1004 a handler that returns -1, so it
is plumbed through avcodec.prx but not implemented on 6.61 - not the real
sixth codec the earlier comment claimed.
Also records the bound that matters for the Atrac3 frame-size question: the ME
is handed a context whose first 0x68 bytes are the only ones made coherent, so
nothing outside that can be reaching it.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Atrac3 no longer hardcodes 384 bytes per frame. The context only carries the
joint-stereo flag for Atrac3 - libatrac3plus.prx writes nothing else there, and
AtracCtx2 already mirrors that - but exactly one of the five supported frame
sizes is joint stereo (66kbps stereo, 0xC0 bytes), so that flag identifies it
on its own. Everything else keeps the old 132kbps assumption, now via the
existing at3HeaderMap rather than a magic number.
MP3 was passing srcBytesRead as the input length, which is an output field
holding what the *previous* call consumed - zero on the first frame. Use the
bound at 0x28 instead, which is what the hardware uses and which the caller
guarantees is readable at inBuf, since it does a cache writeback over exactly
that range. Channels and sample rate now come from the context's channel
configuration and its version/sample-rate index pair, using the same table
avcodec.prx indexes, rather than being assumed stereo 44100.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
The first 0x28 bytes of the context are the same for every codec - and for
sceVideocodec's own context, which annotates the same fields - so this is one
ME codec-context ABI. Everything after that is per-codec, with each library
writing a different set of fields, so it becomes a union.
Also documents that 0x28 is not a frame size for MP3: the hardware only uses it as a
cache-writeback length, so it is an upper bound - which is why the firmware
never bothers computing an exact one anywhere.
Adds codec id 0x1004, which the hardware accepts and handles much like MP3.
Unidentified, but the range check really does accept six codecs.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
* Rename LogType to Log
* Explicitly use the Log:: enum when logging. Allows for autocomplete when editing.
* Mac/ARM64 buildfix
* Do the same with the hle result log macros
* Rename the log names to mixed case while at it.
* iOS buildfix
* Qt buildfix attempt, ARM32 buildfix
Henrik RydgårdandClaude Opus 5.5
Henrik RydgårdandClaude Opus 5
Herman Semenov
fp64