magiclantern-devel Mailing List for The Magic Lantern - Palm OS Media Player

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

I have not been able to connect to the subversion server recently. Can
anyone confirm it is down or know when it will be back up?

Joshua,

1) The most likely cause of problems in the callback would generally be 
incorrect use of globals or cross section calls.  In a regular compile I 
don't think you'll see much of that, but something may have slipped through.  
If you compile with TML_DEBUG the call to TRACE could end up crashing it (If 
it uses any globals in turn or is compiled into another section).  However my 
saving/restoring of R10 should hopefully get around the global problems in 
the purearm version.

The other possible problem in the callback is in my implementation of mutexes.  
If you look in the sourcecode in main/mutex.* then you'll see that my wait 
loops contain a call to SysTaskDelay which fixed some crashing problems on my 
Tungsten E (when I did the original m68k version at least, I haven't touched 
that code in purearm).  Feel free to find a better way of mutual exclusion, 
or just fiddle with the code I've got there.

I know that turning on tracing generally slows down the system a little or a 
lot and can thus give rise to extra problems that you don't normally see.

There could be other problems in the callback, but given the number of asserts 
and checks and the small overall size there shouldn't be many other causes of 
crashes.  I suppose there could be other synchronisation issues though.

2) For testing the format handling code you should find it much easier in the 
purearm version.  Since I've centralised all the ARM/m68k glue functions I 
was able to provide a test harness to compile all the backend code natively 
on your local computer where your have full access to normal debugging tools.

Using the debugger as well as other tools such as valgrind I was able to track 
down some memory leaks and such.  If you think the buffer overrun is within 
the backend code, then this is a good way to test it.  If the problem is 
elsewhere then good luck :P

However I haven't had many problems with the avi parsing code itself for a 
while (at least not when it used to be built for m68k).  But if there's 
buffer problems elsewhere then anything could happen.

Obviously you'll want to narrow down which codecs/formats are causing the 
problems.  You should still be able to play a raw PCM/RGB avi file, an avi 
file with no sound, and (maybe) an avi with only sound.  These should help 
narrow down which case is causing the problem.  I know OGG files are still 
majorly broken - they only work if they're mono - stereo files produce random 
noise and crashes.

3) The code under glue is something I wrote entirely myself for this project.  
It does seem to be working reasonably well at the moment, but there could be 
subtle bugs remaining in it.  I did find out after the fact that I got some 
of the type definition summaries wrong, so there could be some more things 
wrong along those lines.  If you prefer you could look at what other 
open-source code is available to provide palm APIs from ARM, I must admit I 
didn't really look much before writing my own.

Nicholas

On Thursday 30 June 2005 11:41, Joshua P. Luben wrote:
> I've spent much of the last week trying to track down instability-causing
> bugs. I think I've found at least two areas that are causing problems.
> Because I'm new here, I seek any collective knowledge that you may have in
> further locating these problem areas and solving them.
>
> 1. Sound streaming callback from Palm OS seems to intermittently crash
> on Tungstens. I have an E2 and I would say it crashes within the callback
> about 50% of the time.
> 2. I think there is an AVI parsing bug, this might be coupled with what
> looks like a buffer overrun problem that is corrupting memory.
>
>
>
> Any ideas?

I've spent much of the last week trying to track down instability-causing
bugs. I think I've found at least two areas that are causing problems.
Because I'm new here, I seek any collective knowledge that you may have in
further locating these problem areas and solving them.

1.	Sound streaming callback from Palm OS seems to intermittently crash
on Tungstens. I have an E2 and I would say it crashes within the callback
about 50% of the time.
2.	I think there is an AVI parsing bug, this might be coupled with what
looks like a buffer overrun problem that is corrupting memory.

Any ideas? 

In the past couple of days I started using the simulators on desktop. Without 
them it would have been impossible for me to add that much user interface stuff
in a short period of time to TCPMP. As far as I know you are a linux user
so I'am not sure how usefull is it for you, but I'am very familiar with Visual
Studio 6 and because all my code is in "ARM" space (x86 with the simulator)
debugging is so much easier. Using the debug version of the simulators gives
extra warnings about problems I couldn't have found by my own. For me 
development got a lot more easier for Palm OS.

bye, Picard

----- Original Message ----- 
From: "Nicholas Hardy" <nic...@er...>
To: <mag...@li...>
Sent: Tuesday, April 05, 2005 12:50 PM
Subject: Re: [Magiclantern-devel] Great work with the player! Does this list work?

> I agree about moving to pure ARM code.  As I've gone, I've tried to make sure 
> I made few assumptions about the processor type in most of the code (where I 
> didn't have to).  I probably couldn't have started off with doing pure-arm, 
> but I'm a bit more familiar with the tools now so I'll probably make the move 
> as the next major stage of development.
...
> Nicholas
> 
> 

In order to get the PalmChars.h file and the PalmNavigator.h file, you must
be a member of the palmOne Plugged In program. What you can do is comment
out the line:

CFLAGS
+= -I/palmdev/palmone-sdk/ -I/home/nicholas/palm/sdks/PalmSG_SDK_2.0/Incs/ -
DHAVE_PALMONE_SDK

Those files are not required to get TML to work, only to get 5-way support.

Regards,
Donald Kirker

----- Original Message -----
From: <mag...@li...>
To: <mag...@li...>
Sent: Thursday, April 14, 2005 8:19 PM
Subject: Magiclantern-devel digest, Vol 1 #3 - 1 msg

> Send Magiclantern-devel mailing list submissions to
> mag...@li...
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.sourceforge.net/lists/listinfo/magiclantern-devel
> or, via email, send a message with subject or body 'help' to
> mag...@li...
>
> You can reach the person managing the list at
> mag...@li...
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Magiclantern-devel digest..."
>
>
> Today's Topics:
>
>    1. hi all (Reynaldo H. Verdejo Pinochet)
>
> --__--__--
>
> Message: 1
> Date: Thu, 14 Apr 2005 16:52:41 -0400
> To: mag...@li...
> From: "Reynaldo H. Verdejo Pinochet" <rey...@op...>
> Subject: [Magiclantern-devel] hi all
>
>
> --raC6veAxrt5nqIoY
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
>
> Wonderful idea :-)
>
> just checked out the svn repository, tryied to compile, cant do ;(
> lots of harcoded references to PalmNavigator.h and PalmChars.h
> wich i dont have. Edited the Makefile to reflect my sdk location (sdk5r3)=
> =20
> with no different results.=20
>
> I Have close 0 experience compiling for PalmOS, is there something
> im doing wrong?
>
> Best regards
>
>    Reynaldo
>
> --raC6veAxrt5nqIoY
> Content-Type: application/pgp-signature; name="signature.asc"
> Content-Description: Digital signature
> Content-Disposition: inline
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.0 (GNU/Linux)
>
> iD8DBQFCXtgZwY4HfzEURSoRAvBgAJ0cx6trnzuaI+sqza1oZzBQY0BENwCdGcIk
> qlba6X2MQ2egWrJrlS/jP9A=
> =2FpW
> -----END PGP SIGNATURE-----
>
> --raC6veAxrt5nqIoY--
>
>
>
> --__--__--
>
> _______________________________________________
> Magiclantern-devel mailing list
> Mag...@li...
> https://lists.sourceforge.net/lists/listinfo/magiclantern-devel
>
>
> End of Magiclantern-devel Digest

Wonderful idea :-)

just checked out the svn repository, tryied to compile, cant do ;(
lots of harcoded references to PalmNavigator.h and PalmChars.h
wich i dont have. Edited the Makefile to reflect my sdk location (sdk5r3)=
=20
with no different results.=20

I Have close 0 experience compiling for PalmOS, is there something
im doing wrong?

Best regards

   Reynaldo

> In that case we'll probably find you surpassing TML quickly :)
> Feel free to reuse anything I've written in TML for your port - but I don't 
> know how much you'd find useful anyway.

Thanks. I'am checking out poggpl and tml sources about PalmOS 
user interface stuff. I'am currently releasing my first PalmOS program :)
A sample application using my player engine. Hopefully in few weeks it will get stable
on various devices and in the mean time I can create a combined user interface for
different platforms with skin etc...

http://picard.exceed.hu/tcpmp

> Sounds like a good idea.  When I say I'm a bit more familiar now, I haven't 
> actually thought about what I'm going to do next - I'm just more aware of the 
> issues involved; such as use of PIC registers, etc.  I haven't had any 
> experience with optimising video decoding, but is a compiler upgrade and 1 
> extra register really going to make a significant boost to performance?  I'm 
> sure you'd get slightly better optimisation of some of the code, but is that 
> going to translate into more than a few percent of decoding time?

Unfortunatelly it didn't help much :(

bye, Picard

On Tuesday 05 April 2005 23:57, Gábor Kovács wrote:
> > Maybe we could do better by trying to port BetaPlayer
>
> You don't have to. It's already underway :)

In that case we'll probably find you surpassing TML quickly :)

Feel free to reuse anything I've written in TML for your port - but I don't 
know how much you'd find useful anyway.

> > I agree about moving to pure ARM code.  As I've gone, I've tried to make
> > sure I made few assumptions about the processor type in most of the code
> > (where I didn't have to).  I probably couldn't have started off with
> > doing pure-arm, but I'm a bit more familiar with the tools now so I'll
> > probably make the move as the next major stage of development.
>
> Btw what do you know about prc-tools development? It seems the latest 2.3
> version is very old. I'am currently compiling  new modified gcc cross
> compiler for myself using gcc 3.4.3 with making the R9 ARM register free
> for use (and restoring it manually before every OS callback). Loosing two
> ARM registers (R9,R10) with the default armlet system on PalmOS is kinda
> too much for me :)

Sounds like a good idea.  When I say I'm a bit more familiar now, I haven't 
actually thought about what I'm going to do next - I'm just more aware of the 
issues involved; such as use of PIC registers, etc.  I haven't had any 
experience with optimising video decoding, but is a compiler upgrade and 1 
extra register really going to make a significant boost to performance?  I'm 
sure you'd get slightly better optimisation of some of the code, but is that 
going to translate into more than a few percent of decoding time?

I'm actually still on prc-tools 2.2.  Still haven't gotten around to upgrading 
yet.

Nicholas

From: "Nicholas Hardy" <nic...@er...>
> Maybe we could do better by trying to port BetaPlayer

You don't have to. It's already underway :)

> I haven't done any real performance testing yet, so I haven't observed where 
> the time is being spent.  The video display is extra inefficient in that it's 
> actually currently doing YUV->RGB24->RGB16.
> 
> You wouldn't happen to have some nice ARM assembly I could just drop in lying 
> around or anything like that? :)

It's kinda integrated into BetaPlayer. It's not just separate assembly file, I uses 
dynamically generated ARM code.

> I agree about moving to pure ARM code.  As I've gone, I've tried to make sure 
> I made few assumptions about the processor type in most of the code (where I 
> didn't have to).  I probably couldn't have started off with doing pure-arm, 
> but I'm a bit more familiar with the tools now so I'll probably make the move 
> as the next major stage of development.

Btw what do you know about prc-tools development? It seems the latest 2.3 version
is very old. I'am currently compiling  new modified gcc cross compiler for myself
using gcc 3.4.3 with making the R9 ARM register free for use (and restoring it 
manually before every OS callback). Loosing two ARM registers (R9,R10) with 
the default armlet system on PalmOS is kinda too much for me :)

bye, Picard

On Tuesday 05 April 2005 19:26, Gábor Kovács wrote:
> Hi everybody!
>
> I just wanted acknowledge the great the work you guys are doing. You
> started quite a large project doing all the non codecs parts from sketch.
> There's plenty of work ahead with many challenges and fun. As a first time
> media player developer I've been there :)

Maybe we could do better by trying to port BetaPlayer or something else to 
palm, but well...that's not what we're doing right now. :)  Having lots of 
fun right now.  Rarely get the chance to just code, and to hack my way 
through interesting challenges like this. :)

> If possible be as general from the begining as possible. Example don't
> limit the format information about a media just as a combined one video and
> one audio format structure. Be prepaired for multiple streams.
>
> Use some sort of virtual function tables for objects with common interface
> but different functionality (like io, format splitter or codecs). Using a
> switch statments in every function is much more difficult the manage and is
> slower.

I've had that in mind, but went ahead with hard-coding avi support for the 
first stage.  I have generally been careful that the data structure for each 
component is generally only accessed within the one file.  Of course I ended 
up making an exception for the format structure, but even that that's only 
accessed from one other 'class'.  I've had in mind to do something like the 
virtual function table idea and I suppose I should have another look at it 
soon.

> Make your own optimized YUV color space displaying code. On today devices
> without hardware overlay support just displaying the YUV frames is about
> 50% of the cpu time of the hole video decoding. It's very important that
> this part of the code is very optimized. I would suggest to combine your
> own color space converter rigth into the displaying code (using XviD with
> just YUV output)

I haven't done any real performance testing yet, so I haven't observed where 
the time is being spent.  The video display is extra inefficient in that it's 
actually currently doing YUV->RGB24->RGB16.  

You wouldn't happen to have some nice ARM assembly I could just drop in lying 
around or anything like that? :)

> I'am not an expert PalmOS developer, but I read on many forums that
> switch between m68k and ARM mode is slow (flushing CPU instruction cache).
> I would say go with an ARM only player, but this makes debugging much
> harder. Still in longterm I see no other options. It would help a lot to
> create a desktop test version of the player (for me it was easy with WinCE
> and desktop Win32, but I think it would help in this case too at least with
> the codecs and general player functions)

I agree about moving to pure ARM code.  As I've gone, I've tried to make sure 
I made few assumptions about the processor type in most of the code (where I 
didn't have to).  I probably couldn't have started off with doing pure-arm, 
but I'm a bit more familiar with the tools now so I'll probably make the move 
as the next major stage of development.

I have already sometimes run some of the backend code on the desktop - 
especially the format decoder, to facilitate debugging of some bits.  Making 
more of a test harness in the future would probably be a good idea.  But 
probably won't do a full working version or anything like that.

> Btw does this list work? :)
> I subscribed to it early, but didn't receive any mails yet...

Yep it seems like it works.  You're the first to use it.

Nicholas

Hi everybody!

I just wanted acknowledge the great the work you guys are doing. You started 
quite a large project doing all the non codecs parts from sketch. There's plenty
of work ahead with many challenges and fun. As a first time media player 
developer I've been there :)

Few thoughts that come to my mind:

If possible be as general from the begining as possible. Example don't limit the format
information about a media just as a combined one video and one audio format structure. 
Be prepaired for multiple streams.

Use some sort of virtual function tables for objects with common interface but 
different functionality (like io, format splitter or codecs). Using a switch statments in 
every function is much more difficult the manage and is slower.

Make your own optimized YUV color space displaying code. On today devices 
without hardware overlay support just displaying the YUV frames is about 50%
of the cpu time of the hole video decoding. It's very important that this part
of the code is very optimized. I would suggest to combine your own color space 
converter rigth into the displaying code (using XviD with just YUV output)

I'am not an expert PalmOS developer, but I read on many forums that
switch between m68k and ARM mode is slow (flushing CPU instruction cache).
I would say go with an ARM only player, but this makes debugging much harder.
Still in longterm I see no other options. It would help a lot to create a desktop 
test version of the player (for me it was easy with WinCE and desktop Win32, 
but I think it would help in this case too at least with the codecs and general 
player functions)

Btw does this list work? :)
I subscribed to it early, but didn't receive any mails yet...

bye, Picard
BetaPlayer developer