Sound Problems on LJP 0.8

[Mauritus]

i noticed no one has comented that there is a sound problem occuring for the Clie. i have posted this error on the NX80 posts, but no one seems to know why
yoyofr.proboards44.com/index.cgi?board=general&action=display&thread=1107552105
so i wanted to know if somebody has had this problem
on their non clie palms

are there any ways on correcting this problem? and how will it be addressed on version 0.9?

thx in Adv

God Bless

[Mauritus]

I am still having this problem, and i have this
LJP_LJPM_appl_a68k by FileZ it is a LJPM type file

also i have this LJP_LJPP_appl_a68k that i deleted and cannot do this with the other.

might this be the source of my sound problem??

[Mauritus]

i don't want to appear like i am in any case dissrespectful, but why don't i get feedback from any body?

am i the only NX80 user around?
i am seriously want to play with the emulator and i want to make it work
but seems no one even tries to comunicate, even giving out their opinion.

please, if someone knows how can i fix this problem, it will be greatly appreciated if some one helped.

[bigglesworth]

These boards do not have as much traffic as the ones at zodiacgamer.com. I suggest you post there under the emulation section. Good luck. I wish I could help you but I have a Z2 and my sound works fine.

[Tinnus]

Hm, I know the Clie's have some weird things, but besides your problem being very odd I don't have a Clie and have not even seen one. Not to mention you're running over MCA, right? This adds another layer of possible problems to happen

Sorry for not being able to help.

[Mauritus]

the other day i did a research on my problem and i tried contacting cliePet. and so i asked:


"hi, i am an nx80 user that uses your great apportation to this clie, MCA.

it works with many programs out there. there is one that has given me
some trouble. it is Little John Palm. you might already know that it
is a multi plataform emulator for the consoles and handhelds form the
16bit era and down. i am looking to make it work but i am still having
problems with the sound part of the emulation. i have MCA 2.05
installed and still have some trouble with the GBc, GB part of the
emulation. having a snapping continous sound mixed with the real sound
emulation of the games."


and i got this response form him:




"Most emulators don't call the system fast enough - hence the clicking

If they wrote an ARM callback it wouldn't have a problem.

As a user, the best you can do is try the "Deep Buffering" option of MCA
(see the Prefs panel)

For developers, there are tips here:
www.aibohack.com/clie/mca2_dev.htm

Developer Rule #2 is the important one

--CliePet"



See below for the best solution to the problem, using ARM callbacks. MCA2 uses defered broadcast messages to glue between the MCA2 magic (ARM code) and your 68K buffer callback. This can cause problems. If the PDA is not calling EvtGetEvent often enough. There are some system case which your program can't do much about (like when apps are being launched, or when the user has the pen captured on a menu or scrollbar). This is hopefully only an annoyance when the music stops for a few seconds until the pen is released, and buffer The user can turn on "deep buffering" to reduce the annoyance factor.

However, there is a more serious problem. Some apps will hang because if they are expecting callbacks to be called. This is typically used for synchronous playback inside the app (ie. the app does not have a stop button to stop the playback prematurely).
Code that looks something like this:
SndStreamRef stream;
...SndStreamCreate(&stream, ..., MyCallback, &callback_data, buffsize, false);
SndStreamStart(stream);

while (!callback_data.done)
// assumes the callback will set the
// flag after data is exhausted
;

SndStreamStop(stream);
SndStreamDelete(stream);

That will hang because there is no EvtGetEvent between the Start and Stop. The 68K callback will never be called.

You should the middle loop to:
while (!callback_data.done)
{
EventType event;
EvtGetEvent(&event, 10); // or evtWaitForever
SysHandleEvent(&event);
}

Then the callback will be called, and everything will work like the official Palm 5.2 implementation.


--------------------------------------------------------------------------------

Suggestion #1 - "use ARM callbacks"
The callback for filling an output sound buffer for playing (or processing an input sound buffer after recording) can be written as a 68K or ARM callback. The last parameter to SndStreamCreate or SndStreamCreateExtended decides which kind of callback you are using. An ARM callback can not call back to 68K.

If you can use an ARM callback, the MCA2 emulation is much better. There is no latency related to the 68K PACE emulator, and buffer exhaustion should not be a problem (ie. the problem described in RULE2 does not happen with ARM callbacks).

[Tinnus]

AFAIK LJP uses an ARM callback.

[Mauritus]

sorry but what is AFAIK??

and does all modules use the ARM call back
because i thought it only was the SNES and Gen that used it.....

and if they do use this callbacks why does this keeps happening???

[s19locke]

AFIAK= As far as I know
and to answer your other question I have no idea

[Tinnus]

Yes, all of the modules use not only an ARM callback, but all of their code is ARM.

Note: ASM (not equal to) ARM

ASM is a programming language while ARM is a CPU architeture, used by devices with Palm OS 5 and up.

[JJesusfreak01]

Tinnus said:

Yes, all of the modules use not only an ARM callback, but all of their code is ARM.

Note: ASM (not equal to) ARM

ASM is a programming language while ARM is a CPU architeture, used by devices with Palm OS 5 and up.

Could the actual emulator code be written to native arm code, and if so, would it be alot faster?

[Tinnus]

That's what I said, the emulators themselves (the modules) are compiled to native ARM already.