Re: [maemo-developers] problem with dspmp3sink (was: problem with gstreamer and dsppcm)
On Monday 21 August 2006 18:34, Charles 'Buck' Krasic wrote: > 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. Thanks for the information, this is interesting. I tried swap a long time ago on IT2005, that was done in order to make gcc work on Nokia 770 to try compiling something before I installed scratchbox :) Anyway, I did not like the stability as gcc started to fail with internal compiler errors. So I decided not to use swap as long as it is enough memory for what I need. Also there was some swap related report about the problem with mplayer: http://www.internettablettalk.com/forums/showpost.php?p=20068&postcount=96 But maybe I should give swap another try on IT2006 and see if it helps to improve stability. By the way, I already asked this question in the mailing list long time ago, but are there any tools for hardware diagnostics on Nokia 770? Something like memtest86 could probably be very useful. Though availablility of hardware diagnostics tools could probably result in more devices getting returned for replacement with otherwise undetected problems and have negative impact on Nokia profit (just joking). ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] problem with dspmp3sink (was: problem with gstreamer and dsppcm)
On Friday 18 August 2006 22:16, you wrote: > As the gstreamer got some attention in the mailing list, I think it is a > good chance to remind that I'm still having problems with it too: > http://maemo.org/pipermail/maemo-developers/2006-August/005060.html > > I need to know exact audio playing position when using dspmp3sink in order > to properly synchronize video with it in mplayer (for '-ao -gst -ac dspmp3' > options): https://garage.maemo.org/projects/mplayer/ > > So far I did not succeed. Probably I'm missing something trivial and the > help from somebody else or some kind of brainstorming could solve this > problem very fast. Well, that was really something trivial. It was just needed to set 'sync' property to TRUE for dspmp3sink element and gst_element_query position() function starts working! :-) Well, I was almost sure that I tried this 'sync' property at an early stage of experimenting so it took so long to try it again and figure out that it actually works. I wish somebody with more gstreamer knowledge could provide me with some hint, that would save really a lot of my time doing some silly experiments trying to find a reliable way to estimate this sound delay :-) On a positive side, mplayer with a better gstreamer sound output support with proper audio/video sync will be available really soon. ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] problem with dspmp3sink (was: problem with gstreamer and dsppcm)
Siarhei, 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: >Hi, > > > >>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@maemo.org >https://maemo.org/mailman/listinfo/maemo-developers > > begin:vcard fn:Charles 'Buck' Krasic n:Krasic;Charles 'Buck' org:University of British Columbia;Department of Computer Science adr:;;201-2366 Main Mall;Vancouver;B.C.;V6T 1Z4;Canada email;internet:[EMAIL PROTECTED] title:Assistant Professor tel;work:(604) 822-5628 tel;fax:(604) 822-5485 tel;cell:(604) 313-9429 x-mozilla-html:FALSE url:http://www.cs.ubc.ca/~krasic/ version:2.1 end:vcard ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] problem with dspmp3sink (was: problem with gstreamer and dsppcm)
Hi, > 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@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] problem with dspmp3sink (was: problem with gstreamer and dsppcm)
On Friday 18 August 2006 11:21, Zeeshan Ali wrote: > > - The licens of dsppcmsrc/sink is LGPL, can I find the source anywhere > > - instead of raw data, it would be even better to use dspilbc. > >Is there a way to store the captured data to a file, in a way it can > >be played back again (some wrapper)? > >Eeh! just looked into the plugin and really does say LGPL. I am > quite sure, this is a mistake on the developer's behalf since the > plugin is definitly not LGPL (atleast yet) or even under any free/open > license. As the gstreamer got some attention in the mailing list, I think it is a good chance to remind that I'm still having problems with it too: http://maemo.org/pipermail/maemo-developers/2006-August/005060.html I need to know exact audio playing position when using dspmp3sink in order to properly synchronize video with it in mplayer (for '-ao -gst -ac dspmp3' options): https://garage.maemo.org/projects/mplayer/ So far I did not succeed. Probably I'm missing something trivial and the help from somebody else or some kind of brainstorming could solve this problem very fast. 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. Absence of the sources for dspmp3sink does not help for sure, it makes you feel helpless with no source to get additional information and no chance to fix the bugs that may reside in these closed source components. Maybe it is possible to have some description of using mp3 decoder dsp task without gstreamer at all? It probably can reduce the number of intermediate layers and improve reliability if the only thing that we need is just decoding of mp3 data using DSP core. ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
