[maemo-developers] [maemo-developers] problem with dspmp3sink (was: problem with gstreamer and dsppcm)

From: Charles 'Buck' Krasic krasic at cs.ubc.ca
Date: Mon Aug 21 18:34:04 EEST 2006

Just in case you have not done it already, enabling swap in your device
can help a lot to prevent out-of-memory errors.    Maybe this will help
with mplayer/gstreamer stability.

I personally suspect  a design flaw in the current Linux VM subsystem.  
I've observed that if an application allocates memory rapidly,  the
kernel may fail to reclaim pages quickly enough from the page and buffer
caches (they are only caches after all), so it actually denies the
allocation request.     For example, with zero swap, on a machine with
1G of ram, and >500M of it pseudo-free (used by caches), I've seen
moderate allocations fail--like when starting an application like
firefox.    Enabling even a small amount of swap seems to dramatically
change this behaviour.

-- Buck

Eero Tamminen wrote:

>>Also I noticed that gstreamer is not very reliable, at least when using
>>it from mplayer. It can freeze or reboot the device sometimes. That's not
>>something that should be expected from high level API. If I detect some
>>reliable pattern in reproducing these bugs, I'll report it to bugzilla
>>for sure. But right now just using mplayer and lots of seeking in video
>>can cause these bugs reasonably fast.
>First I would recommend using just "top" to see whether mplayer
>is either:
>- Leaking memory
>- Otherwise using too much memory
>Either by itself or forcing gstreamer to do that.
>If that is the case, the bug is in the mplayer (or gstreamer (plugin))
>and it needs to be fixed.  For debugging the leaks, I would recommend
>using Valgrind on x86.
>	- Eero
>PS. The applications in the device have been done so that they integrate
>into the the device memory management framework; if they have dynamic
>or large memory usage, before doing large allocs, they check whether
>system has enough memory for those, they react to system low memory
>notifications etc.
>If an application forces the kernel to the OOM (out of memory)
>situation, it will by default kill the application requesting
>memory.  However, if mplayer is run as root, its killing is
>avoided (note most of the framework processes are run as normal
>user).  Also, if you're using Desktop while mplayer triggers
>device OOM, it's Desktop using memory and kernel might kill it
>(which reboots the device).
>FYI: Only way to handle OOM correctly is to avoid triggering it,
>trying something "fancy" (in kernel) in that situation is AFAIK
>wraught with deadlocks.
>maemo-developers mailing list
>maemo-developers at maemo.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: krasic.vcf
Type: text/x-vcard
Size: 389 bytes
Desc: not available
Url : http://lists.maemo.org/pipermail/maemo-developers/attachments/20060821/60e995e4/attachment.vcf 
More information about the maemo-developers mailing list