VoIP/OpenVPN
Hi, in OS2008, it still seems that VoIP with the bundled comms software doesen't know how to use TUN interfaces (OpenVPN). Any ongoing work on that? MikaM ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: VoIP/OpenVPN
Haudidudi, in OS2008, it still seems that VoIP with the bundled comms software doesen't know how to use TUN interfaces (OpenVPN). Any ongoing work on that? Not currently, but the trick I have been using with OpenVPN has been to enforce the traffic to the tun interface via iptables. Haven't tried on N800, but on one lower scale embedded system running on a 100MHz Cris processor. Should not make a difference, thanks to the abstraction Linux networking system gives us. The down side is of course that you would have to compile net filter support into kernel. On the other hand, this trick will work on any application both current and future. I did even consider to write a support to OpenVPN for the user space queue interface introduced by net filter. Then I could just user firewall rules to send packets to the VPN and would not have to have a separate interface/addressing for the VPN traffic. This was like 5 years ago so I hope that world has developed into a better place since then :-) Br, Sampo ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Frequencies scaling with OS2008
Hi, On Sun, 2007-12-30 at 17:16 +0100, ext Krischan Keitsch wrote: Hi, I read an interesting thread about overclocking the n800 [1]. Based on that I started experimenting with the n800 running OS2008. The OS scales the cpu frequency nicely from 165MHz up to 400MHz. The current cpu scaling can be checked with cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq So far so good. I noticed that during playback of mp3 files the cpu is scaled to 330MHz. Stressing the cpu during mp3 playback will not change the scaling - the cpu will not scale up to 400MHz. According to a presentation Nokia Internet Tablet Power Managemen [2] the dsp runs at 220MHz when the cpu is set to 330MHz. (This is the default setting in OS2007, by the way.) I was wondering if the device really needs to run at 300MHz (220MHz dsp) for mp3 playback? Is the max dsp power needed for such a task? Or would 220MHz (177MHz dsp) or 165MHz (85MHz dsp) be sufficient? Would a lower dsp scaling save even more battery? The issues are: - doing dvfs while ther is audio playback will generate audible ticks because of problems with the dsp dma - the dsp is always set to support even the weirdest cases, therefore there is a lot of spare DSP horsepower that could be cut off if you knew that your mpu load is not going to change too much and it will be low Practically speaking: if you remove the constraint of fixed [EMAIL PROTECTED] [EMAIL PROTECTED] when there is a dsp task active, you might end up in a situation where you are listening to MP3 @ low OMAP clock, then start the browser, therefore causing the OMAP clock to change rapidly and get lots of garbage on the audio out. -- Cheers, Igor Igor Stoppa [EMAIL PROTECTED] (Nokia Multimedia - CP - OSSO / Helsinki, Finland) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Frequencies scaling with OS2008
On 30 December 2007, Frantisek Dufka wrote: Krischan Keitsch wrote: I was wondering if the device really needs to run at 300MHz (220MHz dsp) for mp3 playback? Is the max dsp power needed for such a task? Or would 220MHz (177MHz dsp) or 165MHz (85MHz dsp) be sufficient? Would a lower dsp scaling save even more battery? Well, yes it looks a bit simplistic now. Even if you play audio decoded by ARM cpu (ogg, real audio) it seems to lock ARM core to 330 and dsp to 220Mhz. I suppose it is because you need pcm dsp task running for audio output and any active dsp task locks it to 220Mhz (and thus cpu to 330). I wonder if it is just simple implementation that can be tuned in next firmwares or there is some fundamental problem (like changing dsp clock of already running dsp task may break it so it is hardcoded to 220). ARM cpu frequency is apparently not locked at 330MHz when using pcm dsp task. That's why it is faster to do MP3 decoding on ARM core with the current OS2008 firmware. Extra 70MHz of ARM core frequency are more than enough to handle MP3 and there are even some resources left to speed up video decoding. It is interesting if it is possible to lock ARM/DSP frequency at 400/166 instead of 330/220 when playing video. That would probably improve built-in player performance on some heavy bitrate/resolution videos. Also it is interesting to know what is the difference in power consumption between 400/166 and 330/220 modes? ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Frequencies scaling with OS2008
On Mon, 2007-12-31 at 12:40 +0200, ext Siarhei Siamashka wrote: On 30 December 2007, Frantisek Dufka wrote: Krischan Keitsch wrote: I was wondering if the device really needs to run at 300MHz (220MHz dsp) for mp3 playback? Is the max dsp power needed for such a task? Or would 220MHz (177MHz dsp) or 165MHz (85MHz dsp) be sufficient? Would a lower dsp scaling save even more battery? Well, yes it looks a bit simplistic now. Even if you play audio decoded by ARM cpu (ogg, real audio) it seems to lock ARM core to 330 and dsp to 220Mhz. I suppose it is because you need pcm dsp task running for audio output and any active dsp task locks it to 220Mhz (and thus cpu to 330). I wonder if it is just simple implementation that can be tuned in next firmwares or there is some fundamental problem (like changing dsp clock of already running dsp task may break it so it is hardcoded to 220). ARM cpu frequency is apparently not locked at 330MHz when using pcm dsp task. That's why it is faster to do MP3 decoding on ARM core with the current OS2008 firmware. Extra 70MHz of ARM core frequency are more than enough to handle MP3 and there are even some resources left to speed up video decoding. It is interesting if it is possible to lock ARM/DSP frequency at 400/166 instead of 330/220 when playing video. That would probably improve built-in player performance on some heavy bitrate/resolution videos. Also it is interesting to know what is the difference in power consumption between 400/166 and 330/220 modes? Sadly, because of DSP sw issues, little power saving is possible when the DSP is running (ARM can still go to idle and most of the processor can have its clock gated, but it's not possible to reach OMAP retention). It would be nice to have the DSP able to sleep between frames; the time taken to decode an mp3 frame is significantly shorter than the related playback. However the voltage used @330MHz is the same used @400MHz and the associated DSP clock is actually lower, therefore it _might_ be that the power consumption is the same or lower. If anybody has time and the means to measure it (*), it would certainly be interesting to do a comparison. * a clock is enough if one is sufficiently patient: fully charge the battery and measure how many hours of playback can be achieved in each mode before the battery goes flat this requires _exclusive_ utilization of the system by the player, therefore one has to give up doing anything while the test is ongoing Also, note that for the test to be reliable, it should be executed on a freshly flashed unit with stock sw (apart from the modified kernel) and no extras whatsoever -- Cheers, Igor Igor Stoppa [EMAIL PROTECTED] (Nokia Multimedia - CP - OSSO / Helsinki, Finland) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Is my head off center?
On Mon, 2007-12-24 at 13:08 -0500, ext Michael R. Head wrote: Curious: where is it being marketed as a phone? I haven't seen any advertising suggesting that. Go to the Nokia Web site and go to find products. There's a dropdown that says Select a phone. When you open it, it lists the N810 thereunder. Unhealthy... Gabriel ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Is my head off center?
On Mon, 2007-12-24 at 04:45 -0800, ext mitcheloc wrote: Okay, I'm not sure if this is already in the code or not but it would be great for 3rd party apps to be able to access the XMPP layer in the device. This will let app developers send and receive data safely and securely from other devices allowing cool peer to peer programs to be developed (like two-player chess). Well, Pidgin and Avahi are available from Maemo extras for OS2008. Pidgin will allow you to do link-local chat via Bonjour and Avahi will allow you to write other link-local-aware programs. Another package that will allow you to perform link-local chat is the RTcom package that includes telepathy-haze and telepathy-salut[0][1]. Gabriel [0] The home page: http://rtcomm.garage.maemo.org/ [1] The .install file for the repository: http://gronmayer.com/it/dl.php?id=167 ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Frequencies scaling with OS2008
It is interesting if it is possible to lock ARM/DSP frequency at 400/166 instead of 330/220 when playing video. That would probably improve built-in player performance on some heavy bitrate/resolution videos. Would this be possible then? What knocks the CPU speed down when the DSP is used (or rather when a music file is played)? The media player presumably? Assuming it is the media player that makes the change, I presume that mplayer should run at 400MHz all the time? Sadly, because of DSP sw issues, little power saving is possible when the DSP is running (ARM can still go to idle and most of the processor can have its clock gated, but it's not possible to reach OMAP retention). It would be nice to have the DSP able to sleep between frames; the time taken to decode an mp3 frame is significantly shorter than the related playback. Presumably the background IDL thread implements power saving functions and is present in the dsp kernel? What actually prevents the DSP from sleeping between frames? If the mp3 task is written using semaphores around the data transfer/notification functions, shouldn't the task yield to the background thread after it has decoded a frame and DMA'd it to the audio codec hardware? Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Frequencies scaling with OS2008
On Mon, 2007-12-31 at 12:52 +, ext Simon Pickering wrote: It is interesting if it is possible to lock ARM/DSP frequency at 400/166 instead of 330/220 when playing video. That would probably improve built-in player performance on some heavy bitrate/resolution videos. Would this be possible then? What knocks the CPU speed down when the DSP is used (or rather when a music file is played)? A dsp task loaded changes the cpufreq policy, so that the only allowed frequency for ARM is 330 Having the audio path open, but no dsp tack loaded (arm audio) sets the clock to 400MHz. The media player presumably? Assuming it is the media player that makes the change, I presume that mplayer should run at 400MHz all the time? If mplayer is not using any dsp codec, it should already be in such case. Sadly, because of DSP sw issues, little power saving is possible when the DSP is running (ARM can still go to idle and most of the processor can have its clock gated, but it's not possible to reach OMAP retention). It would be nice to have the DSP able to sleep between frames; the time taken to decode an mp3 frame is significantly shorter than the related playback. Presumably the background IDL thread implements power saving functions and is present in the dsp kernel? What actually prevents the DSP from sleeping between frames? Far from optimal design. In other word there has not been enough commitment to push the sw envelope so that it could actually leverage what the hw can do. The current architecture met the (relatively relaxed) time requirement that were set and therefore it didn't receive any further improvement. If the mp3 task is written using semaphores around the data transfer/notification functions, shouldn't the task yield to the background thread after it has decoded a frame and DMA'd it to the audio codec hardware? The mixer is still running and it has a significant timeout, iirc. Also, 'm not so sure that the tasks are actually behaving so nicely. I'm not really into audio, but if you try to decode some mp3 that requires a lot of dsp time vs one that requires very little (silence?), I'm almost certain that there will be no sigificant difference in terms of power consumption. It should be easy to verify with a large enough SD and some mp3 handcrafting skills (several copy paste of the right type of data should be enough). -- Cheers, Igor Igor Stoppa [EMAIL PROTECTED] (Nokia Multimedia - CP - OSSO / Helsinki, Finland) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: maemo SDK+ ALPHA-1 development environment released
Hi, Please, uncomment the lines ending with 'gutsy universe' or 'gutsy multiverse' in your /etc/apt/sources.list and rerun the 'sudo apt-get update'. Then you should be able to install the dependencies of those two packages that otherwise will not be installed. Regards, J-P -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ext Fred Sent: 28 December, 2007 16:42 To: Luostarinen Mika (Nokia-M/Helsinki) Cc: maemo-developers@maemo.org Subject: Re: maemo SDK+ ALPHA-1 development environment released Hi and Thanks, I tried it but no luck ! The following packages have unmet dependencies: maemo-sdk: Depends: sb2-qemu-arm but it is not going to be installed Depends: scratchbox2 (= 1.99.0.22) but it is not going to be installed Depends: maemo-buildenv (= 0.1.3) but it is not going to be installed E: Broken packages Have you any idea what I did wrong ? Thanks Fred Luostarinen Mika (Nokia-M/Helsinki) a écrit : Dear all, We are happy to announce maemo SDK+ Alpha-1 development environment for maemo developers. Release information --- Project:maemo SDK+ Version:ALPHA-1 Baseline: baseline neutral Date: 2007-12-20 What is maemo SDK+ ? Maemo SDK+ ALPHA-1 provides an alternative way to do maemo application development. Unlike all previous maemo SDKs this SDK is based on Scratchbox 2 (SB2) cross-compilation engine. The previous maemo SDKs were all based on Scratchbox 1 (SB1). There are some differences between maemo SDK+ and other maemo SDKs. For example maemo SDK+ is not a closed development environment. You are working and developing in your native Linux PC (you could develop your maemo application under your ~/src/ directory if you like). In addition you can basically use any normal Linux tool or utility (as such) without the need to port it inside SB1 like in older releases. This release is baseline neutral which means that this maemo SDK+ is not targeted for any specific Internet Tablet or OS200X release. Maemo SDK+ can coexist with an existing maemo SDK environment, such as scratchbox 1.0.8 'apophis' with maemo 4.0 'chinook' or maemo 3.X 'bora'. Release contents This release consists of the following Debian packages: - maemo-sdk * metapackage with core utilities - maemo-buildenv * manage maemo SDK+ build environments - maemo-libtool * libtool source which is compiled with target setup - sbrsh * run binaries on target device with automated mounting - sb2-qemu-arm * Qemu ARM CPU emulator 0.8.2 (with some patches) - scratchbox2 * cross compilation environment - arm-gcc-gnu-linux-armel * GCC armel cross-compiler 4.2.1 (with some patches) We also provide Anjuta IDE plugin for maemo SDK+. It can be downloaded from the following location: http://anjuta-maemo.garage.maemo.org/ Do I need to upgrade ? -- No, you do not need to upgrade. But if you want to test drive maemo SDK+ then there is no need to change (or remove) your existing scratchbox 1 based maemo SDK environment(s). Installing maemo SDK+ will not conflict with your existing maemo SDK installations. Before installing read the Installation Guide document and Release Notes (links are in the end of this text). How do I get started ? -- maemo SDK+ and the related documentation is available in the garage.maemo.org. Point your browser to: Project Home Page: http://maemo-sdk.garage.maemo.org/ Garage Home Page: https://garage.maemo.org/projects/maemo-sdk Release Notes: http://maemo-sdk.garage.maemo.org/release-notes.txt Installation Guide: http://maemo-sdk.garage.maemo.org/install.txt Anjuta IDE maemo Plugin: http://anjuta-maemo.garage.maemo.org/ Happy Hacking ! - the maemo SDK+ team ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Using available DSP tasks
Thanks for your explanation. np After having read the basic Gstreamer documentation, I understand better the sink pad concept of the mp3 task. In the application I am thinking about now, I don't need to look at the raw audio data decoded by the MP3 task as long as I can mix with it an other raw audio stream. I fact I need to mix a MP3 stream and a G711|G729|ILBC|AMR stream. You can see it as a kind of karaoke: mixing music (MP3) and voice (low bandwidth codec). The result should simply be available on the output jack. Did you think it is already doable now ? Yes, this is certainly doable already. I don't have any G7.11 data to hand, but have tried it by mixing ogg and mp3 data (ogg using Tuomas Kulve's gstreamer plugin which uses the pcm dsp sink). E.g. These two commands can be run is separate terminal windows and are mixed: gst-launch-0.10 filesrc location=20-16000HzExp5sec.mp3 ! dspmp3sink gst-launch-0.10 filesrc location=opensource.ogg ! application/ogg ! tremor ! dsppcmsink So this uses the mp3 sink and the pcm sink simultaneously. I imagine it must be possible to start two separate sources in a single gstreamer pipeline and then send them to separate sinks (i.e. as I've done in the above example but all in one command). Anyone know how to do this? Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: python2.5 - unnecessary multiple processes forked
On 12/30/07, Jayesh Salvi [EMAIL PROTECTED] wrote: Hi, I am porting a pygtk application to maemo. It works alright, but I noticed that it was consuming lot of memory, preventing me from opening other applications. When I investigated, I found that my python application was forking 4 more instances of itself, each one identical in memory footprint. Thus they consumed nearly 60-70% of my memory. So I ran my application using pdb and narrowed down to a code segment that was leading to multiple instances of the process. It turned out that when I call run() on hildon.fileChooserDialog object, the dialog opens and at that moment in the top I see 4 more instances being forked. I fail to understand this behavior. I replaced the hildon widgets by pure gtk widgets and I see similar behavior, except that 2 more instances get forked. Also when using gtk.FileChooserDialog, these new instances get created in the instantiation of the dialog object, rather than call to run(). (code included below) So to further explore the problem, I ran same application on my desktop with gtk widgets. But I verified that when fileChooserDialog's run is called, there are no additional instances of python. I am running this code on n770, with 2007 HE and python2.5 runtime. My application code is pure python and not using any additional libraries. In fact following would be a simpler version of it to reproduce the problem: ... Do you have any tips, as to what might be going wrong? With the following C code[1] the same problem happens. [1] http://pastebin.com/m2d7c9783 -- Lauro Moura INdT - Instituto Nokia de Tecnologia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: python2.5 - unnecessary multiple processes forked
I recommend using the garbage collector module manually to override the defaults. Python for some reason doesn't reclaim memory fast. So if you put in your code: import gc gc.collect() (at the right spots, probably after the file chooser dialog and after some memory intensive tasks). You should notice a lot of memory being free'd up. -Alex On Sunday 30 December 2007 05:20:34 pm Jayesh Salvi wrote: Hi, I am porting a pygtk application to maemo. It works alright, but I noticed that it was consuming lot of memory, preventing me from opening other applications. When I investigated, I found that my python application was forking 4 more instances of itself, each one identical in memory footprint. Thus they consumed nearly 60-70% of my memory. So I ran my application using pdb and narrowed down to a code segment that was leading to multiple instances of the process. It turned out that when I call run() on hildon.fileChooserDialog object, the dialog opens and at that moment in the top I see 4 more instances being forked. I fail to understand this behavior. I replaced the hildon widgets by pure gtk widgets and I see similar behavior, except that 2 more instances get forked. Also when using gtk.FileChooserDialog, these new instances get created in the instantiation of the dialog object, rather than call to run(). (code included below) So to further explore the problem, I ran same application on my desktop with gtk widgets. But I verified that when fileChooserDialog's run is called, there are no additional instances of python. I am running this code on n770, with 2007 HE and python2.5 runtime. My application code is pure python and not using any additional libraries. In fact following would be a simpler version of it to reproduce the problem: import gtk import hildon #window = gtk.Window(gtk.WINDOW_TOPLEVEL) #fileChooser = gtk.FileChooserDialog( # title=Choose a photo to publish, # buttons=(gtk.STOCK_CANCEL, gtk.RESPONSE_CANCEL, # gtk.STOCK_OK, gtk.RESPONSE_OK)) fileChooser = hildon.FileChooserDialog( window,gtk.FILE_CHOOSER_ACTION_OPEN) result = fileChooser.run() if result == gtk.RESPONSE_OK: print fileChooser.get_filename() Do you have any tips, as to what might be going wrong? This problem is fatal at least on n770 - it will trigger low memory message when other applications are used on the side. Any help will be useful. Thanks, ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Using available DSP tasks
Hi, See the merged pipeline below On Dec 31, 2007 7:49 AM, Simon Pickering [EMAIL PROTECTED] wrote: Thanks for your explanation. np After having read the basic Gstreamer documentation, I understand better the sink pad concept of the mp3 task. In the application I am thinking about now, I don't need to look at the raw audio data decoded by the MP3 task as long as I can mix with it an other raw audio stream. I fact I need to mix a MP3 stream and a G711|G729|ILBC|AMR stream. You can see it as a kind of karaoke: mixing music (MP3) and voice (low bandwidth codec). The result should simply be available on the output jack. Did you think it is already doable now ? Yes, this is certainly doable already. I don't have any G7.11 data to hand, but have tried it by mixing ogg and mp3 data (ogg using Tuomas Kulve's gstreamer plugin which uses the pcm dsp sink). E.g. These two commands can be run is separate terminal windows and are mixed: gst-launch-0.10 filesrc location=20-16000HzExp5sec.mp3 ! dspmp3sink gst-launch-0.10 filesrc location=opensource.ogg ! application/ogg ! tremor ! dsppcmsink gst-launch-0.10 filesrc location=20-16000HzExp5sec.mp3 ! dspmp3sink \ filesrc location=opensource.ogg ! application/ogg ! tremor ! dsppcmsink This way you can be sure that both pipelines are running on a single process. I'm not certain it is going to work as expected due to constraints with two audio streams running at the same time, but you can write as many source-filter-sink pipelines in a single gst-launch as you want. Thanks, Daniel. So this uses the mp3 sink and the pcm sink simultaneously. I imagine it must be possible to start two separate sources in a single gstreamer pipeline and then send them to separate sinks (i.e. as I've done in the above example but all in one command). Anyone know how to do this? Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: python2.5 - unnecessary multiple processes forked
Especially make use of gc.collect() after you have worked with gdk.Pixbuf objects. They won't free their memory otherwise. It's a good habit to free unused Pixbufs with del and run the garbage collector afterwards. And be aware that if a class overrides the __del__ method (some sort of destructor), it won't be freed by the garbage collector at all. Cheers, Martin 2007/12/31, Alex Iliadis [EMAIL PROTECTED]: I recommend using the garbage collector module manually to override the defaults. Python for some reason doesn't reclaim memory fast. So if you put in your code: import gc gc.collect() (at the right spots, probably after the file chooser dialog and after some memory intensive tasks). You should notice a lot of memory being free'd up. -Alex On Sunday 30 December 2007 05:20:34 pm Jayesh Salvi wrote: Hi, I am porting a pygtk application to maemo. It works alright, but I noticed that it was consuming lot of memory, preventing me from opening other applications. When I investigated, I found that my python application was forking 4 more instances of itself, each one identical in memory footprint. Thus they consumed nearly 60-70% of my memory. So I ran my application using pdb and narrowed down to a code segment that was leading to multiple instances of the process. It turned out that when I call run() on hildon.fileChooserDialog object, the dialog opens and at that moment in the top I see 4 more instances being forked. I fail to understand this behavior. I replaced the hildon widgets by pure gtk widgets and I see similar behavior, except that 2 more instances get forked. Also when using gtk.FileChooserDialog, these new instances get created in the instantiation of the dialog object, rather than call to run(). (code included below) So to further explore the problem, I ran same application on my desktop with gtk widgets. But I verified that when fileChooserDialog's run is called, there are no additional instances of python. I am running this code on n770, with 2007 HE and python2.5 runtime. My application code is pure python and not using any additional libraries. In fact following would be a simpler version of it to reproduce the problem: import gtk import hildon #window = gtk.Window(gtk.WINDOW_TOPLEVEL) #fileChooser = gtk.FileChooserDialog( # title=Choose a photo to publish, # buttons=(gtk.STOCK_CANCEL, gtk.RESPONSE_CANCEL, # gtk.STOCK_OK, gtk.RESPONSE_OK)) fileChooser = hildon.FileChooserDialog( window,gtk.FILE_CHOOSER_ACTION_OPEN) result = fileChooser.run() if result == gtk.RESPONSE_OK: print fileChooser.get_filename() Do you have any tips, as to what might be going wrong? This problem is fatal at least on n770 - it will trigger low memory message when other applications are used on the side. Any help will be useful. Thanks, ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Frequencies scaling with OS2008
Igor Stoppa wrote: Having the audio path open, but no dsp tack loaded (arm audio) sets the clock to 400MHz. Interesting, so, umm, there is way to play audio from ARM side directly? What I tried is to play BBC radio in home screen applet which activated only pcm2 task and arm clock dropped from 400 to 330. That lead me to conclusion that there is no way to output audio with arm clock at 400Mhz. Why there are pcm tasks (used when streaming internet radio) if we could output audio from arm side without limiting ARM clock? Siarhei apparently used a way to output audio without activating DSP from mplayer, how? Indeed there is something in arch/arm/mach-omap2/board-n800-audio.c arch/arm/mach-omap2/board-n800-dsp.c that looks like there is a way to (partly?) power up dsp, do not run any task and send audio from arm side? As for the policy I had a look at arch/arm/mach-omap2/board-n800-dvfs.c and there are four states defined OP_0 to OP_3 and two additional ones OP_DSP_H (H=high?) and OP_CPU_H as aliases to OP_1 (330/220) and OP_0 (400/133). So one could probably redefine OP_DSP_H to different OP_X to try running dsp at different clock and see which dsp tasks are not fast enough. Also I wonder what happens when I set DSP_CLK_KHZ in OP_0 state to 266000, can I damage the hardware or will the DSP just crash (leaving rest of the system relatively OK)? Some comments would be nice there like e.g. which clocks in the table are tied together or which combinations (dsp vs mpu vs other) are allowed. BTW, are you forbidden to put any meaningful comments about the hardware there? If yes then how come you are allowed to publish the code itself? Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: python2.5 - unnecessary multiple processes forked
I tried Lauro's C example in scratchbox environment and see that it's indeed forking 4 more processes. So this is not a python problem. This problem's root cause seems to reside in the widget library. I can't imagine any valid reason for gtk/hildon to fork more processes just to show a GUI dialog. Does anyone know? On 12/31/07, Martin Grimme [EMAIL PROTECTED] wrote: Especially make use of gc.collect() after you have worked with gdk.Pixbuf objects. They won't free their memory otherwise. It's a good habit to free unused Pixbufs with del and run the garbage collector afterwards. And be aware that if a class overrides the __del__ method (some sort of destructor), it won't be freed by the garbage collector at all. Cheers, Martin 2007/12/31, Alex Iliadis [EMAIL PROTECTED]: I recommend using the garbage collector module manually to override the defaults. Python for some reason doesn't reclaim memory fast. So if you put in your code: import gc gc.collect() (at the right spots, probably after the file chooser dialog and after some memory intensive tasks). You should notice a lot of memory being free'd up. -Alex On Sunday 30 December 2007 05:20:34 pm Jayesh Salvi wrote: Hi, I am porting a pygtk application to maemo. It works alright, but I noticed that it was consuming lot of memory, preventing me from opening other applications. When I investigated, I found that my python application was forking 4 more instances of itself, each one identical in memory footprint. Thus they consumed nearly 60-70% of my memory. So I ran my application using pdb and narrowed down to a code segment that was leading to multiple instances of the process. It turned out that when I call run() on hildon.fileChooserDialog object, the dialog opens and at that moment in the top I see 4 more instances being forked. I fail to understand this behavior. I replaced the hildon widgets by pure gtk widgets and I see similar behavior, except that 2 more instances get forked. Also when using gtk.FileChooserDialog, these new instances get created in the instantiation of the dialog object, rather than call to run(). (code included below) So to further explore the problem, I ran same application on my desktop with gtk widgets. But I verified that when fileChooserDialog's run is called, there are no additional instances of python. I am running this code on n770, with 2007 HE and python2.5 runtime. My application code is pure python and not using any additional libraries. In fact following would be a simpler version of it to reproduce the problem: import gtk import hildon #window = gtk.Window(gtk.WINDOW_TOPLEVEL) #fileChooser = gtk.FileChooserDialog( # title=Choose a photo to publish, # buttons=(gtk.STOCK_CANCEL, gtk.RESPONSE_CANCEL, # gtk.STOCK_OK, gtk.RESPONSE_OK)) fileChooser = hildon.FileChooserDialog( window,gtk.FILE_CHOOSER_ACTION_OPEN) result = fileChooser.run() if result == gtk.RESPONSE_OK: print fileChooser.get_filename() Do you have any tips, as to what might be going wrong? This problem is fatal at least on n770 - it will trigger low memory message when other applications are used on the side. Any help will be useful. Thanks, ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers -- --- Jayesh ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: python2.5 - unnecessary multiple processes forked
Jayesh Salvi wrote: I can't imagine any valid reason for gtk/hildon to fork more processes just to show a GUI dialog. Does anyone know? I'm not sure but think it is because of gnome-vfs. Don't know proper terminology but maybe each vfs 'provider' in the dialog (like mmc, phone etc.) starts new process or something like that. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: python2.5 - unnecessary multiple processes forked
I'm not sure but think it is because of gnome-vfs. Don't know proper terminology but maybe each vfs 'provider' in the dialog (like mmc, phone etc.) starts new process or something like that. That sounds correct. I experimented with other dialogs that do no involve filesystem access (NamePasswordDialog, SortDialog), and they do not fork any extra processes. So this behavior seems valid for FileChooserDialog. But then I should be able to cleanup those extra processes when I am done with the FileChooserDialog. I called destroy() on the dialog object, but that doesn't help. -- --- Jayesh ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: 3.2007.10-7 - Detailed change log?
Quim Gil wrote: About fixed bugs reported in the public bugzilla, we know we owe to the users and developers reporting those bugs a better response. The progress done in the last 6 months is remarkable but we are still not there. We tried but we couldn't have an updated report in the last release. We are still working in our processes. Being conservative I expect the Chinook release to have a partial collection of fixed bugs and get into good quality standards by Diablo. Hi Quim - resurrecting this old chestnut once again. :) Any chance of an update regarding a change log for Chinook, if not a full and detailed change log then at the very least a cross reference with the public bugzilla? Happy New Year to everyone at maemo.org and the mailing list! :) Neil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: python2.5 - unnecessary multiple processes forked
On 12/31/07, Jayesh Salvi [EMAIL PROTECTED] wrote: I'm not sure but think it is because of gnome-vfs. Don't know proper terminology but maybe each vfs 'provider' in the dialog (like mmc, phone etc.) starts new process or something like that. That sounds correct. I experimented with other dialogs that do no involve filesystem access (NamePasswordDialog, SortDialog), and they do not fork any extra processes. So this behavior seems valid for FileChooserDialog. But then I should be able to cleanup those extra processes when I am done with the FileChooserDialog. I called destroy() on the dialog object, but that doesn't help. I guess there isn't much to do - for an app programmer at least. I found the same behavior with osso_pdfviewer. It also uses hildon's FileChooserDialog. But even before that dialog is invoked, multiple processes are forked. ... and they do not disappear until their parent exits. They keep occupying the same amount of memory as their parent. This is really taxing on my n770. If this is the default behavior of gnome-vfs based GTK apps, then I hope it gets improved for embedded devices. -- --- Jayesh -- --- Jayesh ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: python2.5 - unnecessary multiple processes forked
Jayesh Salvi wrote: I guess there isn't much to do - for an app programmer at least. I found the same behavior with osso_pdfviewer. It also uses hildon's FileChooserDialog. But even before that dialog is invoked, multiple processes are forked. ... and they do not disappear until their parent exits. I think once they are initialized they don't go away since you may actually need them if user clicks some file in the dialog which is 'provided' by them. They keep occupying the same amount of memory as their parent. This is really taxing on my n770. If this is the default behavior of gnome-vfs based GTK apps, then I hope it gets improved for embedded devices. BTW, are you sure the memory situation is really worse because of this? If yes then maybe this is specific to python. In C forked process does not add much memory overhead because memory pages in childs are shared with the parent until they are modified. So I guess when programming in C this is not a big issue so nobody cared so far. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Frequencies scaling with OS2008
On 31 December 2007, Frantisek Dufka wrote: Igor Stoppa wrote: Having the audio path open, but no dsp tack loaded (arm audio) sets the clock to 400MHz. Interesting, so, umm, there is way to play audio from ARM side directly? What I tried is to play BBC radio in home screen applet which activated only pcm2 task and arm clock dropped from 400 to 330. That lead me to conclusion that there is no way to output audio with arm clock at 400Mhz. Why there are pcm tasks (used when streaming internet radio) if we could output audio from arm side without limiting ARM clock? Siarhei apparently used a way to output audio without activating DSP from mplayer, how? I did not do anything special. ARM clock frequency just remains at 400MHz when using esd or sdl for audio output. I did some benchmarks and it became clear that it is now faster not to touch dsp mp3 task and just do all the decoding on ARM core. In addition, my hack which used dspmp3sink from MPlayer, now has problems with audio/video synchronization in OS2008. So looks like it is a good time to drop it. Using DSP for MP3 audio was a useful trick on Nokia 770 and OS2006, but right now everything is reversed for N800/N810 and OS2008. Anyway, my guess also was that pcm dsp task is used in osso-esd, maybe it makes sense to check its sources more thoroughfully. Looks like we will have a lot of new discoveries with OS2008 :) As ARM core is quite fast in N8x0, probably it would make sense to try keeping DSP out of the way whenever possible (restrict it to 133MHz only, keep DSP tasks which are fast enough to run at this frequency, port all the other DSP tasks to ARM)? That is unless improvements to support more intelligent DSP clock frequency selection are still possible. But for those interested in C55x development, Nokia 770 is still a very interesting device as it runs DSP at full speed. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: python2.5 - unnecessary multiple processes forked
forgot to cc the list. On 12/31/07, Jayesh Salvi [EMAIL PROTECTED] wrote: BTW, are you sure the memory situation is really worse because of this? What I see is, in 'top' all these processes show same percentage of memory utilization under %MEM column (17% or so for each of them). I am not sure if this is virtual memory or physical memory. My application logic flow goes like this: It gets the filename from the user (hence FileChooserDialog) and after some processing it has to open a URL in the browser. It sends an RPC request to the browser. What I am observing is, the browser takes a long time to open that URL and by the time it has opened it, my app gets killed without any error message. Once I had seen a low memory message during this process, but now my parent app gets killed without any such message. I am still trying to establish if the above behavior is only because of memory over consumption. I will update as I make progress. -- --- Jayesh -- --- Jayesh ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Happy new year 2008
Happy new year 2008, happy hacking from Spain :) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
