Thomas Fletcher
|
Re: Memory allocation with mme_getphoto()
|
Thomas Fletcher
04/08/2009 7:41 AM
post26328
|
Re: Memory allocation with mme_getphoto()
Dan Cardamore wrote:
> In 1.1 the art from MP3 files is fetched directly with MMF since the
> MME is linked against MMF for just artwork. This means you would
> need to look through the top layer of the MME (devctl.c and photo.c)
> to trace if there are leaks there. Failing that my guess is that the
> issue is in MMF, in which case you may want to try with different
> types of container formats to see if it is an MP3 or MPEG4 issue for
> example.
We've seen the problem on repositories with just aac files as well as on
mixed repositories with aac, wma, mp3 and wav files.
Part of the problem is that I have _no_ album art and the memory usage
is shooting up just because of the API call being made.
Is the release product tagged in the repository so that I could go back
and look at the code that is close to what I'm using to see if I can help
you guys narrow this down? As far as I can tell the project was created
post 1.1 release and doesn't contain the 1.1 code as it was for the release.
Otherwise, I guess this will have to go the route of priority support to get
a patch made for 1.1 since this additional memory allocation will quickly
overflow our configuration.
I'll also take this opportunity to comment that the new history/sync
mechanism
is kind of gross. Every single revision log looks like:
Original-Revision: r216491
Original-Date: 2009-03-25T13:23:45.320812Z
Original-Author: groy@qnx.com
Original-LogMsg: PR:64241
CI:dcardamore
- Rename this file
Ugh ...
> The next release that we're working towards is 1.2. mme_getphoto( )
> replaced with a much more robust image framework that offers the
> following features: * Metatadata for images. Find out how many
> images there are and other details such as their size and dimensions.
> * load images on demand. mme_getphoto( ) could only load the first
> image, 1.2 can load any image in a file that was looked up previously
> * large image support. 1.1 only supported images smaller than 64kb
> * image profiles and conversion so that you can have thumbnails
> created, or have all your images in JPEG format. Configurable and
> built on top of QNX's libimg library * image caching so that
> subsequent lookups don't have to go back to the device or parse the
> image
While the head branch is interesting, I need to work with released
product =;-(
I'm also slightly concerned that version 1.2 (a minor version change) would
actually drop a public API. Am I mis-understanding what you are saying?
From what I see in the repository, there is no cover function for the
mme_getphoto() client call, though there is still an (unused?) header in
main.h
indicating that there should be a server side call.
Thanks,
Thomas
|
|
|