The following warnings occurred:
Warning [2] Undefined property: MyLanguage::$archive_pages - Line: 2 - File: printthread.php(287) : eval()'d code PHP 8.2.26 (Linux)
File Line Function
/inc/class_error.php 153 errorHandler->error
/printthread.php(287) : eval()'d code 2 errorHandler->error_callback
/printthread.php 287 eval
/printthread.php 117 printthread_multipage



EmuNewz Network
xuggle atrac3 audio support - Printable Version

+- EmuNewz Network (https://www.emunewz.net/forum)
+-- Forum: PSP Emulation (https://www.emunewz.net/forum/forumdisplay.php?fid=191)
+--- Forum: JPCSP Official Forum (https://www.emunewz.net/forum/forumdisplay.php?fid=51)
+---- Forum: svn trunk discussion (https://www.emunewz.net/forum/forumdisplay.php?fid=56)
+---- Thread: xuggle atrac3 audio support (/showthread.php?tid=1834)

Pages: 1 2

RE: xuggle atrac3 audio support - Hykem - 08-24-2010

(08-24-2010, 12:53 AM)yann Wrote: Just tested the r1745 build. When presented with a functioning xuggle, it behaves as my patch did with Disgaea - the first few notes play, but no more. We still need to figure out what the HalfwayBuffer interface does to feed the codec more data. Other games might use AtracAddStreamData though, which is the currently supported variant.
Would you have any ideas where to look for the sceAtrac3plus API?

Exactly. At least for "Disgaea" this appears to be a persisting issue. Sad
I checked the output results and there seems to be more free space allocated then produced samples. This means the game is not adding more data properly.
As far as I know, the HalfwayBuffer sends two sizes, one is the full data size, but the other is the minimum data required to start playback decoding.
Perhaps, towards the last couple of samples, it could be sending this ammount and overwriting it imediately after, since we are only decoding at sceAtracDecodeData.

@hyakki: Thanks for testing! I had no idea those games used AT3 at all. Big Grin

RE: xuggle atrac3 audio support - yann - 08-24-2010

(08-24-2010, 02:43 PM)Hykem Wrote: Exactly. At least for "Disgaea" this appears to be a persisting issue. Sad
I checked the output results and there seems to be more free space allocated then produced samples. This means the game is not adding more data properly.
As far as I know, the HalfwayBuffer sends two sizes, one is the full data size, but the other is the minimum data required to start playback decoding.
Perhaps, towards the last couple of samples, it could be sending this ammount and overwriting it imediately after, since we are only decoding at sceAtracDecodeData.
I suspect it might be filling the new data in on demand, but that the HalfwayBuffer should be read automatically. I.e. HalfwayBuffer would set up a permanent ring buffer, such that it doesn't need to point out where the new data is. Could we track if it writes to that memory again? It could be triggered by different remaining frames values from sceAtracDecodeData.

RE: xuggle atrac3 audio support - Hykem - 08-24-2010

(08-24-2010, 03:56 PM)yann Wrote:
(08-24-2010, 02:43 PM)Hykem Wrote: Exactly. At least for "Disgaea" this appears to be a persisting issue. Sad
I checked the output results and there seems to be more free space allocated then produced samples. This means the game is not adding more data properly.
As far as I know, the HalfwayBuffer sends two sizes, one is the full data size, but the other is the minimum data required to start playback decoding.
Perhaps, towards the last couple of samples, it could be sending this ammount and overwriting it imediately after, since we are only decoding at sceAtracDecodeData.
I suspect it might be filling the new data in on demand, but that the HalfwayBuffer should be read automatically. I.e. HalfwayBuffer would set up a permanent ring buffer, such that it doesn't need to point out where the new data is. Could we track if it writes to that memory again? It could be triggered by different remaining frames values from sceAtracDecodeData.

Yes, it's quite possible. Maybe it distinguishes when non loop data is being read, so it can prepare the next chunk of data.
Also, we can track those writes with JPCSP's memory breakpoint feature. Make a file called "Memory.mbrk" on JPCSP's root folder and inside write the following:
Code:
[R, W or RW][Start Address]-[End Address]
In that line, you can specify if you want the emulator to pause on memory reads, writes or both for a specific range address.

RE: xuggle atrac3 audio support - Abelus - 10-13-2012

In r2748 there is indicated the following: "Implemented __sceSasSetVoiceATRAC3 and __sceSasUnsetATRAC3: now (atrac3) sound should be produced by these functions."
Does that mean that JPCSP can play atrac3 sound from now on? I tried some games with atrac3, but it still doesn't play.

RE: xuggle atrac3 audio support - serio - 10-13-2012

it could play regular atrac3 and stereo atrac3+ for a long while, the text just mentions it can now play the files using more functions, so more games that were completely silent before should be able to partially play sound now.

you're thinking of mono atrac3+, which can't be decoded yet. hykem supposedly had some good progress in decoding the encryption for at3+ files (so they could be implemented into the emulator without the need for sonicstage, and play both stereo and mono at3+ files), but he disappeared few months ago again.