This forum uses cookies
This forum makes use of cookies to store your login information if you are registered, and your last visit if you are not. Cookies are small text documents stored on your computer; the cookies set by this forum can only be used on this website and pose no security risk. Cookies on this forum also track the specific topics you have read and when you last read them. Please confirm whether you accept or reject these cookies being set.

A cookie will be stored in your browser regardless of choice to prevent you being asked this question again. You will be able to change your cookie settings at any time using the link in the footer.

Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
xuggle atrac3 audio support
#11
(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
Reply
#12
(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.
Reply
#13
(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.
Reply
#14
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.
Reply
#15
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.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)