Re: Finding the mmc cards
I'm interested to hear thatanything outside of the SD cardhas a choice in the matter. There was a time when hardware write-protection of this kind was exactly that: harware-enforced write-protection. I would have expected that, if I put the switch on an SD card into the "write-protected" position, the card itself would disable or ignore write operations (by, for example, disabling whatever line/signal is used to perform the write operation). David Hazel On 8/29/07, David Hazel [EMAIL PROTECTED] wrote: - whether write protected (yes, you can write-protect an SD card) Yes, but the Nokia's do not support or honor that switch. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Finding the mmc cards
Hi, MMC_MOUNTPOINT variable was present on 770 already and the device had one (external) mmc slot only. N800 added a second memory card slot (the internal one) and respective variable... -Markku- David Hazel wrote: You can also use the environment variables MMC_MOUNTPOINT and INTERNAL_MMC_MOUNTPOINT, but then you have to make sure that they are always set correctly in your environment. (I don't think using environment variables for this kind of system information is a good idea.) Those environment variables seem oddly inconsistent to an ex-VMS man like me. Why not EXTERNAL_MMC_MOUNTPOINT and INTERNAL_MMC_MOUNTPOINT? Otherwise it's necessary to remember which one the unqualified MMC_MOUNTPOINT refers to (e.g. by remembering that the other one starts with INTERNAL rather than EXTERNAL - which itself is counter-intuitive, as I would expect the internal one to be the more important and therefore the unqualified one). ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Python and GStreamer
Austin Che wrote: Jesse Guardiani [EMAIL PROTECTED] wrote: And no, before you ask, I don't think it's not Nokia's fault. gstreamer is just unexpectedly buggy. Too bad ALSA doesn't support inline mp3 decoders... life would be easier for all of us... I've been wondering: what is the performance hit for not going through gstreamer? So based on my understanding, going through gstreamer, the mp3 is decoded on the DSP. Supposing it was decoded on the cpu and sent out through alsa, which of the following is likely to be true: - The CPU wouldn't be able to handle it (playback would skip) No, not even close. It doesn't use anywhere near that much CPU. Even with a separate process running transcoding the decoded mp3 into SBC packets (think a2dpd from the bluetooth-alsa package) we still don't get skipping, though doing other things at the same time will cause skipping sometimes. - The CPU could handle it just as well as the DSP but the rest of the system might be less usable - The battery life would decrease (how much?) Yes, mostly it's a battery life issue. But decoding mp3 in software does take a bit of available CPU, so you can't do quite as much simultaneously. - some other reason this wouldn't work well? Nah. Battery and multi-tasking. Those are the primary concerns, I think. And the related question is: given an existing program that sends stuff out to ALSA and doesn't use gstreamer, how difficult is it generally to port it so that it works properly? No porting necessary, really. mplayer comes with a decoder called libmp3. It's not optimized for ARM or anything, and it compiles without any problems. We don't use it in Kagu for A2DP though because there is another decoder out there called ffmp3 which doesn't use floating point math, so it's a little more efficient on ARM. By this, I'm thinking of a typical C program that plays mp3 files. Would it likely require a complete rework of the code structure or is it probably a trivial replacement of function calls? Trivial. You could always optimize it by re-writing it to do everything with fixed point math, but it's not strictly necessary, at least on the n800. -- Jesse Guardiani Programmer/Sys Admin [EMAIL PROTECTED] ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Python and GStreamer
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jesse Guardiani schreef: And the related question is: given an existing program that sends stuff out to ALSA and doesn't use gstreamer, how difficult is it generally to port it so that it works properly? No porting necessary, really. mplayer comes with a decoder called libmp3. It's not optimized for ARM or anything, and it compiles without any problems. We don't use it in Kagu for A2DP though because there is another decoder out there called ffmp3 which doesn't use floating point math, so it's a little more efficient on ARM. use libmad (-ac mad), that works great on arm and x86. regards, Koen -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iD8DBQFG1sERMkyGM64RGpERAsWdAJ4+hsMXCDH8eiyMDPVbJfjBknDLMACbBvuf qoDtnZ5HfdOlgxxZommHfNc= =5/O8 -END PGP SIGNATURE- ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Python and GStreamer
Koen Kooi wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jesse Guardiani schreef: And the related question is: given an existing program that sends stuff out to ALSA and doesn't use gstreamer, how difficult is it generally to port it so that it works properly? No porting necessary, really. mplayer comes with a decoder called libmp3. It's not optimized for ARM or anything, and it compiles without any problems. We don't use it in Kagu for A2DP though because there is another decoder out there called ffmp3 which doesn't use floating point math, so it's a little more efficient on ARM. use libmad (-ac mad), that works great on arm and x86. Any cpu savings over ffmp3? The mplayer maintainers tell me that ffmp3 is the best choice on ARM. -- Jesse Guardiani Programmer/Sys Admin [EMAIL PROTECTED] ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Python and GStreamer
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jesse Guardiani schreef: Koen Kooi wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jesse Guardiani schreef: And the related question is: given an existing program that sends stuff out to ALSA and doesn't use gstreamer, how difficult is it generally to port it so that it works properly? No porting necessary, really. mplayer comes with a decoder called libmp3. It's not optimized for ARM or anything, and it compiles without any problems. We don't use it in Kagu for A2DP though because there is another decoder out there called ffmp3 which doesn't use floating point math, so it's a little more efficient on ARM. use libmad (-ac mad), that works great on arm and x86. Any cpu savings over ffmp3? The mplayer maintainers tell me that ffmp3 is the best choice on ARM. No idea on that, but I'm wary of anything starting with 'ff' that pretends to be a shared lib. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iD8DBQFG1sOIMkyGM64RGpERAle/AKCUUMw9FYl0qjbSSuPKI3pYb9MqDgCgj/pC ulYpOJKsqKpSvGgoJlOYLo8= =JzqT -END PGP SIGNATURE- ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Python and GStreamer
Koen Kooi wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jesse Guardiani schreef: Koen Kooi wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jesse Guardiani schreef: And the related question is: given an existing program that sends stuff out to ALSA and doesn't use gstreamer, how difficult is it generally to port it so that it works properly? No porting necessary, really. mplayer comes with a decoder called libmp3. It's not optimized for ARM or anything, and it compiles without any problems. We don't use it in Kagu for A2DP though because there is another decoder out there called ffmp3 which doesn't use floating point math, so it's a little more efficient on ARM. use libmad (-ac mad), that works great on arm and x86. Any cpu savings over ffmp3? The mplayer maintainers tell me that ffmp3 is the best choice on ARM. No idea on that, but I'm wary of anything starting with 'ff' that pretends to be a shared lib. OK I don't follow your logic there. -- Jesse Guardiani Programmer/Sys Admin [EMAIL PROTECTED] ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Feature request tabbed desktop.
Hi George - I think that what you're describing would be more fiddly than just opening the relevant application! It would maybe have been valid on the 770, with its (IIRC) slower memory operations and less RAM, but IMHO the n800 is fast enough to start applications that the extra UI complexity just wouldn't be justified by the ability to view more applets that /little/ bit quicker :-) Cheers! Jonathan On 8/24/07, George Farris [EMAIL PROTECTED] wrote: With the limited amount of screen space available on the N800 and friends I'm finding I want more home applets running than I have space for. Would it be possible to have a tabbed desktop so one could have Home and User desktops and be able to switch them in the top Home menu. That would be totally awesome. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers -- Jonathan Matthews-Levine|[EMAIL PROTECTED]|07790 195 895 That sounds vaguely obscene, and if there's one thing I cannot *stand*, it's vagueness. -- Dean Grennell ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Feature request tabbed desktop.
On 8/24/07, George Farris [EMAIL PROTECTED] wrote: With the limited amount of screen space available on the N800 and friends I'm finding I want more home applets running than I have space for. Would it be possible to have a tabbed desktop so one could have Home and User desktops and be able to switch them in the top Home menu. Hi George - I think that what you're describing would be more fiddly than just opening the relevant application! It would maybe have been valid on the 770, with its (IIRC) slower memory operations and less RAM, but IMHO the n800 is fast enough to start applications that the extra UI complexity wouldn't be justified by the ability to view more applets that /little/ bit quicker :-) Cheers! Jonathan -- Jonathan Matthews-Levine|[EMAIL PROTECTED] That sounds vaguely obscene, and if there's one thing I cannot *stand*, it's vagueness. -- Dean Grennell ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Treeview multiple selection mode
I have enabled multiple selection mode for a treeview. On the desktop, I am able to make multiple selections by holding down the ctrl key while clicking on items in the treeview. On the N800, there is no ctrl key. To perform a multiple selection, the Nokia user guide says that I should place the stylus on a non-highlighted item, and drag the stylus over the items. When I follow these directions, only the first item gets selected. I tried calling the treeview method set_rubber_banding(), but it doesn't exist on maemo. How do I get the behavior described in the user guide? -- Jeffrey Barish ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Finding the mmc cards
On 8/30/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I'm interested to hear that anything outside of the SD card has a choice in the matter. There was a time when hardware write-protection of this kind was exactly that: harware-enforced write-protection. I would have expected that, if I put the switch on an SD card into the write-protected position, the card itself would disable or ignore write operations (by, for example, disabling whatever line/signal is used to perform the write operation). Nope, the specs leave it up to the device to implement, kind of like the old notch on floppies ;-) From the Nokia n800 user manual: This device does not support the write protection feature of SD cards. I don't believe the write protection switch was part of the original MMC card design specs was it? I'm not in the loop but it's only recently I started seeing cards with the switch. I'm assuming it sets some bit somewhere to tell the hardware Hey, leave me alone which Maemo promptly ignores. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
latest rtcomm beta b0rked my add account button.
Just an FYI. I can no longer click the add account button successfully after an rtcomm update. I tried uninstalling and reinstalling rtcomm to no avail. It's totally b0rken. The error I get is a little pop-up stating Internal error. Application 'Internet call' closed. I'm running rtcomm beta 1.3-1. -- Jesse Guardiani Programmer/Sys Admin [EMAIL PROTECTED] ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Python and GStreamer
Koen Kooi [EMAIL PROTECTED] wrote: Jesse Guardiani schreef: And the related question is: given an existing program that sends stuff out to ALSA and doesn't use gstreamer, how difficult is it generally to port it so that it works properly? No porting necessary, really. mplayer comes with a decoder called libmp3. It's not optimized for ARM or anything, and it compiles without any problems. We don't use it in Kagu for A2DP though because there is another decoder out there called ffmp3 which doesn't use floating point math, so it's a little more efficient on ARM. use libmad (-ac mad), that works great on arm and x86. Ok thanks. So I went ahead and ported mpd and mpg321 to maemo. In case anyone else wants these packages as I couldn't find them already out there: http://austin.mit.edu/maemo mpd uses about 10% of the cpu and mpg321 uses about 20% of the CPU even though they should be both using libmad. mpg321 seems to skip a bit just switching apps but renicing it a bit appeared to get rid of the skipping. I'm not sure why mpd seemed to do better in general. Also, for some reason, using alsa output with mpd didn't work (apparently segfaults) while libao output worked fine. I'll try using mpd with glurp, mmpc, or some other client for a bit and see if I can get a feel for whether the battery usage is substantially worse than using canola. But so far, this setup with mpd is more like how I want my music player to be and fixes some of the annoyances I've had with all the other music players I've tried: no unnecessary scanning for new songs and no unexplainable errors that stop or freeze the playing of the music some of the time. All that is needed is a good client. glurp seems a bit unresponsive but mmpc isn't too bad. If anyone knows of any other good mpd client (there is a ridiculously large number of clients http://mpd.wikia.com/wiki/Clients) or one that could be easily ported, please let me know. I was looking at the sonata client which requires pygtk 2.6 and gtk 2.6 but I'm not sure if maemo supports these versions as I couldn't get it to install: http://mpd.wikia.com/wiki/Client:Sonata ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Python and GStreamer
On 30 August 2007, Jesse Guardiani wrote: Koen Kooi wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jesse Guardiani schreef: And the related question is: given an existing program that sends stuff out to ALSA and doesn't use gstreamer, how difficult is it generally to port it so that it works properly? No porting necessary, really. mplayer comes with a decoder called libmp3. It's not optimized for ARM or anything, and it compiles without any problems. We don't use it in Kagu for A2DP though because there is another decoder out there called ffmp3 which doesn't use floating point math, so it's a little more efficient on ARM. use libmad (-ac mad), that works great on arm and x86. Any cpu savings over ffmp3? The mplayer maintainers tell me that ffmp3 is the best choice on ARM. Just for the sake of correctness, I did not quite say that :) This is what I replied to you earlier when we were discussing A2DP performance issues: Software MP3 (-ac ffmp3) and OGG/Vorbis (don't remember exact '-ac' option for it, but you don't need it anyway as this decoder is used by default) decoders are already enabled in mplayer. If we want the best MP3 decoding performance, libmad (-ac mad) is the best choice, but it is an external dependency and is not used right now. The worst option for software MP3 decoding on ARM is mp3lib (-ac mp3), it uses floating point math and is a lot slower than other (fixed point) MP3 decoders even on N800 which supports floating point math in hardware. You can try to test all these decoders yourself to figure out which one works the best for you. Just ffmp3 is a part of ffmpeg library and is bundled with mplayer by default and libmad is an external dependency which may make packaging a bit more complicated. That's the only reason why libmad support is not enabled in maemo build of mplayer yet. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
