Re: Using available DSP tasks
Jean-Christian de Rivaz wrote: g729_dec was runnings. I wonder if this was a limitation from the DSP or from the Linux applications (e.g. Media Player and Skype trying to use the same device). I think the device stops all other audio when a VOIP call is made, but I think this is how it's designed, not a technical limitation. I'm mostly guessing here though. You should be able to test that quite easily by running couple gst-launch instances from the command line. -- Tuomas signature.asc Description: OpenPGP digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
service is temporarily unavailable
Hi, When apt-getting maemo-sdk-dev (chinook_x86), I get following errors: ... Get:36 http://repository.maemo.org chinook/free libosso-help0 2.1.2-3 [4242B] Fetched 36B in 10s (4B/s) Failed to fetch http://repository.maemo.org/pool/maemo4.0/free/libx/libxdmcp/libxdmcp-dev_1.0.2-2osso1_i386.deb Size mismatch Failed to fetch http://repository.maemo.org/pool/maemo4.0/free/x/x11proto-kb/x11proto-kb-dev_1.0.3-2_all.deb Size mismatch ... I can look at directory http://repository.maemo.org/pool/maemo4.0/free/libx/libxdmcp/ however, when trying to download libxdmcp-dev_1.0.2-2osso1_i386.deb I get error: The service is temporarily unavailable. We are very sorry for the inconvinience it may cause. other files from the directory seem to download OK. Is this a known issue, should I change repositories? Regards, Hans. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: service is temporarily unavailable
En/na Hans Diels ha escrit: I can look at directory http://repository.maemo.org/pool/maemo4.0/free/libx/libxdmcp/ however, when trying to download libxdmcp-dev_1.0.2-2osso1_i386.deb I get error: The service is temporarily unavailable. We are very sorry for the inconvinience it may cause. other files from the directory seem to download OK. Is this a known issue, should I change repositories? This is an issue that's been affecting everyone trying to install software on the tablet for the last 10 days. It's unknown if it is a nokia or an akamai screw-up, but you can try stage.maemo.org instead of repository.maemo.org. Bye -- Luca ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: service is temporarily unavailable
Hi, This is not an official explanation, but it is what I think is happening... Apparently, the maemo server was taken down for maintenance and stupid Akamai cached this state. Now that the maemo server is back online, Akamai still serves the error pages. This could be because the maemo error page did not return an HTTP error code, but looks like a valid HTML page (status code 200). If this is the case, how should Akamai know that it's caching bogus? If you access maemo.org with any prefix other than the Akamai-cached repository, you can circumvent the Akamai cache and get to the real server. If too many people did this, we might experience server outage again... Cheers, Martin 2007/12/30, Luca Olivetti [EMAIL PROTECTED]: En/na Hans Diels ha escrit: I can look at directory http://repository.maemo.org/pool/maemo4.0/free/libx/libxdmcp/ however, when trying to download libxdmcp-dev_1.0.2-2osso1_i386.deb I get error: The service is temporarily unavailable. We are very sorry for the inconvinience it may cause. other files from the directory seem to download OK. Is this a known issue, should I change repositories? This is an issue that's been affecting everyone trying to install software on the tablet for the last 10 days. It's unknown if it is a nokia or an akamai screw-up, but you can try stage.maemo.org instead of repository.maemo.org. Bye -- Luca ___ 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: maemo SDK+ ALPHA-1 development environment released
We are happy to announce maemo SDK+ Alpha-1 development environment for maemo developers. Thank you very much for this! After a long upgrade of my machine to gutsy, I got maemo SDK+ running and I can say I definitely like it a lot better than scratchbox 1. I can now compile directly from within emacs and development is just much more pleasant. I couldn't find any problems with it and everything is compiling and running great! ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Using available DSP tasks
If the DSP in not the limitation, then the N800 could be used for a funny project I have now in my head. I there any documentation on how to program a Linux application to use some existing DSP tasks available on the N800? I am interesting about the MP3 decoder and a pair of low bandwidth coder/decoder like G711, G729 or ILBC. There is source available for the ARM-side part of the gstreamer sinks (http://repository.maemo.org/pool/chinook/free/source/g/gst-plugins-dsp0.10/). That should show you how to use the dsp tasks. There's a fundamental problem though, the mp3 dsp task sends its data directly to the audio codec (hardware) on the DSP-side, therefore you're probably not going to be able to access the raw data to reencode it as something else (unless it is also exposed in a buffer in shared memory). I am debugging an mp3 dsptask at the moment, so you may yet have something to play with at some point in the near future if you can't get the built-in tasks to work as you wish. Cheers, Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Frequencies scaling with OS2008
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? Has anyone managed to successfully change the settings manually? Best regards Krischan [1] http://internettablettalk.com/forums/showthread.php?t=10681highlight=overclocking [2] http://maemo.org/news/announcements/view/1184097560.html Nokia Internet Tablet Power Management by Klaus K Pedersen, Igor Stoppa ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Using available DSP tasks
Simon Pickering wrote: There is source available for the ARM-side part of the gstreamer sinks (http://repository.maemo.org/pool/chinook/free/source/g/gst-plugins-dsp0.10/). That should show you how to use the dsp tasks. Source that is non-compilable: https://bugs.maemo.org/show_bug.cgi?id=2271 -- Tuomas signature.asc Description: OpenPGP digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Frequencies scaling with OS2008
Krischan Keitsch wrote: 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 Seems that it's also 330MHz with ogg playback even though oggs are decoded on the ARM side and according to the top it takes 20% of the cpu. -- Tuomas signature.asc Description: OpenPGP digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Frequencies scaling with OS2008
Am Sonntag, 30. Dezember 2007 schrieben Sie: Krischan Keitsch wrote: 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 Seems that it's also 330MHz with ogg playback even though oggs are decoded on the ARM side and according to the top it takes 20% of the cpu. And mplayer takes 400MHz for video and ogg playback. It shouldn't use 400MHz for ogg when 5% cpu is used. Room for optimization? Krischan ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Using available DSP tasks
Tuomas Kulve a écrit : Jean-Christian de Rivaz wrote: g729_dec was runnings. I wonder if this was a limitation from the DSP or from the Linux applications (e.g. Media Player and Skype trying to use the same device). I think the device stops all other audio when a VOIP call is made, but I think this is how it's designed, not a technical limitation. I'm mostly guessing here though. You should be able to test that quite easily by running couple gst-launch instances from the command line. Thanks for the gst-launch hint. I didn't know Gstreamer, so I will have to learn a bit before doing useful experiment. Seem to be a very nice open source framework. Regards, -- Jean-Christian de Rivaz ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Using available DSP tasks
Simon Pickering a écrit : If the DSP in not the limitation, then the N800 could be used for a funny project I have now in my head. I there any documentation on how to program a Linux application to use some existing DSP tasks available on the N800? I am interesting about the MP3 decoder and a pair of low bandwidth coder/decoder like G711, G729 or ILBC. There is source available for the ARM-side part of the gstreamer sinks (http://repository.maemo.org/pool/chinook/free/source/g/gst-plugins-dsp0.10/). That should show you how to use the dsp tasks. There's a fundamental problem though, the mp3 dsp task sends its data directly to the audio codec (hardware) on the DSP-side, therefore you're probably not going to be able to access the raw data to reencode it as something else (unless it is also exposed in a buffer in shared memory). I am debugging an mp3 dsptask at the moment, so you may yet have something to play with at some point in the near future if you can't get the built-in tasks to work as you wish. Cheers, Hi Simon, Thanks for your explanation. 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 ? Best Regards, -- Jean-Christian de Rivaz ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Frequencies scaling with OS2008
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). Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
python2.5 - unnecessary multiple processes forked
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, -- --- Jayesh ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
