Proxy in SDK installation script
Hi, The following adds proxy configuration for apt in the SDK installation script. I didn't add any messages, and I'm not sure if it's OK in /etc/apt/apt.conf.d/99proxy but at least it should work. Best regards. -- Felipe Contreras --- maemo-sdk-install_3.0.sh 2007-03-16 15:16:37.0 +0200 +++ maemo-sdk-install_3.0-mod.sh 2007-03-16 15:02:06.0 +0200 @@ -760,7 +760,12 @@ fi fi -# TODO Add proxy configuration to apt.conf +# Add proxy configuration to apt.conf +if [ x$__proxy != x ] ; then +for __update_target in $__armel_target $__i386_target ; do +echo Acquire::http::Proxy \$__proxy\; $__scratchbox/users/$USER/targets/$__update_target/etc/apt/apt.conf.d/99proxy +done +fi phase Generating and installing scratchbox build tools virtual packages ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: What's wrong with folder browsing?
On 5/21/07, Karoliina Salminen [EMAIL PROTECTED] wrote: Hi, ext Kalle Vahlman wrote: Folder approach is intuitive, shared by all reasonable apps on all platforms, doesn't waste anything and just works. It does waste the users time (in the long run), which to me seems more important than the machines time. It pretty much depends on the user and if there are mp3-tags present on the files, I would like to have both ways available because: I happen to have a tag-messy music library (which is organized to folders, which is not my fault - I have done a lots of work to make compilations of various mp3-files I have got from my artist friends, but the tags being inconsistent is the fault of the author and encoder of the mp3-files) because my library consists of mostly indie music done by some friends. Obviously there are no mp3-tags on place and the files are organized with folders only (as the author of the file haven't been too interested to put the tags on place especially if the file is unfinished track that is just given out for review-listening), playing full albums (which are based on these files without mp3-tags or varying mp3-tags like Track 1 Fin:Greenblue 1 Track 2 fin: Green blue 2 Track 3 FIN: Blue Green3 Track 4 Christian Worton:greenblue 4 Track 5 Fin: Greenblue 5 Track 6: Unknown artist:Green Blue 6 ... and so forth. This ends up being several artists and several albums on system which blindly indexes the files based on the mp3 tags, which is pretty problematic and which isn't my fault as listener and it makes me pretty confused. The only solution currently to my understanding, in media players only supporting mp3-tag based organization is to play the files one by one which is not so nice for listening to background music. Now I could imagine a brilliant tool that would sort of solve this problem: A program or script that would run on linux and which would go and scan all the subfolders in the media folder and put the tags to the mp3-files on place so that the album name would be created from the folder name and the track name from the filename. Obviously it should do this without re-encoding the files (since re-encoding would degrade sound quality in lossy compression). If such tool already exists, I would love to hear where I can get it, I would really need one since I can't really blame the various authors of my mp3-collection since if I am getting better indie music than commercial music is for free, I can't really complain, having inconsistent mp3-tags is small issue taken in account that the music is superb quality, glitches on tags, but no glitches on music! There are some tools: http://pwp.netcabo.pt/paol/tagtool/ http://easytag.sourceforge.net/ http://www.gnomefiles.org/app.php/gmusicbrowser Best regards. -- Felipe Contreras ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Proof of concept G.711 dsptask
On 8/3/07, David Huggins-Daines [EMAIL PROTECTED] wrote: Simon Pickering wrote: I chose something relatively easy to make sure I didn't lose the will (battling against both the algorithm and the DSP oddities). Anyway, my hope is that this might show people that it's quite easy to use the dsp (for something simple at least), and to get people thinking of other ways of using it. Wow, this is excellent. Where does one download the TI DSP toolchain? Indeed, it's very interesting. I think this might work, but I'm not sure: http://maemo.org/community/wiki/dspprogramming/ -- Felipe Contreras ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: problems while building a Debian package in the scratchbox environment
On 8/31/07, Laurent Bloch [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I'm trying (unsuccesffully) to port Michael Mlivoncic's JPilot Package for N770 to the N800 with OS2007: http://michaels770.blogspot.com/2006/03/jpilot-package-for-n770.html In fact, I don't need pilot-link, as far as I want to use the N800 as a replacement for the Palm, but I need to recover my data, and to keep using jpilot on my Linux boxes. When trying, in the appropriate directory: dpkg-buildpackage -rfakeroot -b -d the sbox-SDK_ARMEL replies : unable to execute /scratchbox/compilers/host-gcc/bin/gcc: No such file or directory This looks very bad. How did you install the SDK? Did you follow the instructions carefully? I recommend to re-install the maemo SDK, there are not many steps required. http://repository.maemo.org/stable/bora/INSTALL.txt -- Felipe Contreras ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: [ANN] Ruby/Maemo first release.
Hi, On 9/22/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I'd like to announce the _packaged_ release of my Ruby/Maemo project. The files you need to start developing graphical Maemo apps in Ruby are at: http://maemo.rubyx.co.uk/projects/ruby-maemo That's great news but that URL doesn't seem to work =/ Best regards. -- Felipe Contreras ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo and Gstreamer
Hi Chetan, On 11/5/07, chetan nanda [EMAIL PROTECTED] wrote: Hi All, I have developed the media player for Maemo and still now i have implemented the play and stop functionality. Now i want to implement seek functionality, i have made some code. in that i have set two callbacks function while seeking. first when the seek will start and other when seek will end. At seek start , i am just setting the stream ( pipeline ) state to Paused state and at seek end, i am performing the seek calculation and set the stream in the playing state. But some how stream is not able to change from pause to playing state. Can anybody tell me , what could be the reason ? I'm not sure what could be the reason but you don't need to pause the pipeline. You can do export GST_DEBUG=*:4 or different levels to find out what's happening, and also ask in the GStreamer mailing list. Best regards. -- Felipe Contreras ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: What is the policy of Maemo on the source codes of embedded applications
On 11/5/07, Huang Gao [EMAIL PROTECTED] wrote: Dear all Maemo guys: I am now studying Maemo system, and found that not all source codes of it are opened to public; specially speaking, most embedded applications have not opened their source codes, though Maemo is stated as a full open source platform now (or these applications are not regarded as part of the platform? J ). For instance, source codes of filemanager can not be found at any repositories, as well as some other embedded applications. Are there anyone can give me some tips on this point? Is it a policy of Nokia that source codes of embedded applications will not be released to public, or there are some websites have opened them that are not so easy to be found? Some applications are closed. AFAIK the filemanager is one example, another one is the media player. Best regards. -- Felipe Contreras ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Looking for npapi microb-engine header files
On Nov 28, 2007 10:33 AM, Jean-Sébastien Légaré [EMAIL PROTECTED] wrote: Hi. I would like to port an existing mozilla plugin to the microb browser on the N800 running the latest OS2007. The whitepaper on the microb-engine available at browser.garage.maemo.org doesn't say much about their implementation of NPAPI and NPRuntime. Where could I get the set of header files, specific to the microb-engine on the n800 that I need to include in my plugin code? I am referring to the header files that we normally find in the gecko-sdk, such as npapi.h and npupp.h. Also, once I manage to compile the plugin as a shared object, how can I register it in the browser ? e.g. Can I install it with xpi from the browser? Can I place it in user's home directory under .mozilla/plugins/ or something similar ? I think you can use the following as a guide: http://repository.maemo.org/extras/pool/bora/free/t/tablet-browser-default-plugin/ -- Felipe Contreras ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to add ogg to the supported codecs/containers list?
On Dec 7, 2007 5:47 PM, Tuomas Kulve [EMAIL PROTECTED] wrote: The metalayer crawler has a configuration file /usr/share/libmetalayer/metadata_lib.conf which looks like the following: --- clip --- # libmetalayer configuration extractors mp3 libmtext_mp3 amr libmtext_amr --- clip --- What do those mean exactly? Does it add all files with mp3 extension to the /home/user/.meta_storage regardless of the mime type ? Looks like it.. What does the next column mean? AFAIK you should probably use libmtext_gst. If this doesn't work I can check further. The built-in media player says unsupported file format very easily for oggs but for some reason not always. I've been able to play oggs with vorbis and oggs with theora/vorbis with the MP, but not always. So where does the MP get the list of supported audio/video codecs? Does the .desktop file affect this situation somehow (exluding the fact that FM knows which app supports which mime type)? Again I'm not sure, but as you guessed probably the .desktop file is just for the FM. It seems that the MP doesn't list all files in .meta_storage to the Library it has. Does it add only files with audio/* or video/* as the mime type from the .meta_storage to the Library? Indeed, the MP checks for mime-types with audio/* or video/* otherwise it won't play. Hmm, I guess I should have sent this from my Nokia account. -- Felipe Contreras ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Chinook install
On Dec 20, 2007 9:51 AM, [EMAIL PROTECTED] wrote: On Wed, 19 Dec 2007, Michael R. Head wrote: Here's a good blog post describing the process for Ubuntu 7.10: http://www.progbox.co.uk/wordpress/?p=453 This didn't work either. However, I found in the mameo 4 docs a little piece about making sure that binfmt_misc was loaded as a module. I loaded this module and ran the install script with the -d and -u options. It appears to be working... right now its happily downloading a bunch of packages. Now I have to figure out how to load this module automatically. I've created a wiki page about how I usually do it: http://bluwiki.com/go/Maemo_Howto It's supposed to be distribution agnostic and I've done it several times. If you find any issues you can fix it. Best regards. -- Felipe Contreras ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Chinook install
On Dec 20, 2007 3:15 PM, [EMAIL PROTECTED] wrote: Ive installed Scratchbox and now Im struggling with the Maemo install. Im running the maemo-sdk-install script. Is there a problem repository.maemo.org? Yes, I can't do any 'apt-get update' in my already installed Chinook. I should disclose that I am behind a proxy server, but setting http_proxy worked before for the Scratchbox install. That's not a problem. -- Felipe Contreras ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: ANNOUNCE: Internet Communications Software Update 2 for N800/N810
On Jan 3, 2008 2:45 PM, olle [EMAIL PROTECTED] wrote: Great news! Does this mean that pidgin plugins such as OTR ref: https://bugs.maemo.org/show_bug.cgi?id=1921 will work OOTB or perhaps only require some minimal porting? From what I can see no port is needed, but some manual configuration needs to be done. I think both telepathy-haze and missioncontrol need these. Best regards. -- Felipe Contreras ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: TCP socket library
On Feb 5, 2008 3:28 PM, Fred Labrosse [EMAIL PROTECTED] wrote: All, I'm fairly new to maemo development (but not to C/C++) and am starting an application for my N800. I need to use TCP sockets and was wondering if there was any high level library to do that. I saw references to SDL_net for maemo 2, but not maemo 4 (and indeed, it is not installed on my nokia or in the devel environment). Would anybody have anything to suggest? There's also libsoup which although it's meant for HTTP stuff there's also an Socket class: http://library.gnome.org/devel/libsoup/stable/SoupSocket.html It's going to be on the next GNOME release. And GIO which will be included in the next GLib's release. Documentation is not online AFAIK. Best regards. -- Felipe Contreras ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: DSP SBC encoder task
On Sat, Jun 7, 2008 at 12:17 AM, Simon Pickering [EMAIL PROTECTED] wrote: Hi Chaps, I have been thinking more about this and I think another approach could be considered. It would be easier to plug your work into everything else if you wrote it up as a patch to the regular sbc.c so it transparently chooses the soft or dsp codec at runtime. It would work with the alsa plugin, gst, and eventually pulse without extra work. Marcel will have to weigh in if it's to be accepted upstream. In any case, we'd need an override. It could be done with an environment variable like SBC_CODEC with values eg soft, dsp, auto with auto the default if it's not set. This does step around gstreamer a little, but anyway, alsa and pulse don't have the greatest gstreamer integration to start with... Yes, that sounds like a good idea. At the moment I'm effectively running all of sbcenc.c on the DSP, while I should just be doing sbc_encode() + whatever init and clean-up routines are needed to handle the DSP on the ARM and to pass it the stream format data. I've started looking at the Bluez code and it looks like it should be reasonably easy (he says!) to have just these bits running on the DSP (expect lots of questions still though). Would it be synchronous? I mean, that the encoding will start with sbc_encode, and before the function returns the output would be ready. I haven't done DSP development, but I've used DSP libraries and all of them seem to be asynchronous. What do you mean by it stepping around GStreamer? From my quick look at the code, the same init/clean-up and sbc_encode() routines seem to be used for both GStreamer and the ALSA bits; what more does GStreamer need to know? In theory it should be fairly easy to create a new GStreamer element that overrides the software one. Best regards. -- Felipe Contreras ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Community council is a representative body - not community leadership
On Mon, Jun 16, 2008 at 11:04 PM, Darius Jack [EMAIL PROTECTED] wrote: Hi Igor, And please stop speaking about html code as I use the same mailer for years and in your previous e-mails you have seen no problems. So what's the problem with you today. The fact that people have brought up this issue until now doesn't mean the have been annoyed by it before. This is a mailing list for developers, and developers usually have high-standard regarding many technical things, and that includes net-etiquette. Probably you won't read this either, but:: http://tools.ietf.org/html/rfc1855 - Make things easy for the recipient. - Assume that individuals speak for themselves, and what they say does not represent their organization (unless stated explicitly). -- Felipe Contreras ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Wiki page of the Day: Video encoding
On Mon, Jul 7, 2008 at 1:05 PM, Dave Neary [EMAIL PROTECTED] wrote: Hi all, This is the last time I'll be cross-posting WPotD announcements - from now on I'll use the new [EMAIL PROTECTED] list for WPotD updates, and I invite any of you interested in community processes, the wiki or the development of the website to join that list. Thank you very much for the help on USB networking - it's now been cleaned up put to bed, as has booting from a flash card and partitioning a flash card (thanks in large part to General Antilles's monster contribution). A special thank you also to the anonymous contributor who updated playing ogg files and allowed me to remove the in progress tags this morning. The wiki is coming along nicely! The WPotD for today is Video encoding http://wiki.maemo.org/Video_encoding - an article which, it seems to me, is in dire need of reduction. From my own experience, the page should be an instruction manual on installing tablet-encode and its dependencies, and that's it. Thank you again (and especially General Antilles, the tireless warrior) for your help, and let's keep the momentum through this week. If you only have 5 minutes to contribute, then picking one paragraph, and tidying up the text or deleting it (if needed) is a great contribution. Re-reading other people's edits to spot corrections is also a great help. There's also the official documentation: http://maemo.org/development/documentation/how-tos/3-x/transcoding_how-to.html I should probably give more love to the transcoding script, but so can anybody else. Best regards. -- Felipe Contreras ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Remove Darius?
On Sat, Sep 6, 2008 at 5:39 PM, Eric Warnke [EMAIL PROTECTED] wrote: I would support that as well. I don't see the point of his posts, but if he is legitimate (not a troll) then I hope he learns how to communicate whatever he is trying to say. My bet is he is some kind of 'support vampire' [1], if you are reading this I suggest you try to communicate with some people on the community off-the-record so you can come up with more useful feedback. You cannot change the world unless you understand how it works. Just ignore him on-the-record, is my suggestion. [1] http://www.slash7.com/pages/vampires -- Felipe Contreras ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: ALSA sound driver for Nokia 770 and DSP programming
On Thu, Sep 25, 2008 at 10:07 PM, Siarhei Siamashka [EMAIL PROTECTED] wrote: Hi, As has been discovered long ago [1] but eventually forgotten, Nokia 770 has AIC23 audio hardware [2] which can be used not only from DSP side, but from ARM as well. Moreover, OS2006 kernel sources even contain an ARM driver for it, but this driver is disabled (that's understandable as the driver is not in a very good shape and has quite a number of bugs). Recently I have been trying to make it running and seems like we have a very good chance to have it working nicely. It is also interesting, that the linux-omap guys seem to be developing a new driver [3] for AIC23 which may eventually become a better alternative. Kernel patch is attached. It enables AIC32 driver, adds a hack to power on/off code so that audio codec is permanently powered on (power on/off code is not reliable and needs to be reworked). Also it fixes a problem with audio stuttering on video playback in mplayer (the driver had broken position reporting which is critical for proper audio/video synchronization). Here is some usage instruction (beware that standard disclaimer applies: you can use this patch at your own risk, this code is quite untested. If it somehow manages to fry your device, you have been warned and I'm not responsible for any breakages): 1. Disable esd daemon and DSP stuff in order to move it out of the way (temporarily rename '/usr/bin/esd' and '/usr/sbin/dsp_dld' to something else) 2. Apply the attached patch to OS2006 kernel, compile and flash it to the device 3. Compile and install alsa userspace library, I used alsa-lib-1.0.11.tar.bz2 4. Put attached 'asound.conf' into '/etc' directory on the device, it enables dmix plugin for audio mixing and resampling 5. Compile and try some applications which use ALSA, I tested 'aplay' and 'mplayer' The driver is semi-usable now, but a lot still needs to be done: * proper power management to avoid excessive battery drain * audio volume control * switch between speaker/headphone * audio quality is a bit crappy now, this needs to be fixed * maybe some more fixes for bugs that are yet to be discovered... DMA code is quite suspicious (especially the way it does channels linking) and might be responsible for audio quality issues. Also sofware mixing/resampling code in dmix plugin can benefit from ARM optimizations. Now regarding why we may want it. Once if we get a good, low latency, fully functional and reliable ALSA sound driver running on ARM, it gives maemo community a nice possibility to scrap all the proprietary DSP binaries. This provides us with a new and shiny 252MHz C55x DSP core ready to be used by something else :) Free linux DSP toolchain from TI [4] supports generation of both DSP kernel and DSP tasks for OMAP1 based devices which is sufficient for DSP development. The toolchain license was supposed to permit open source development (with noncommercial restriction), though the license text itself is a bit questionable [5]. With DSP avalable for use and having no need to spend efforts on ensuring compatibility and peaceful coexistence with proprietary binary codecs (free and proprietary code does not mix well), it should be possible to turn Nokia 770 into quite a powerful media player. Great stuff! Do you plan to use the dsp-gateway or dsp-bridge? -- Felipe Contreras ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: ALSA sound driver for Nokia 770 and DSP programming
On Fri, Sep 26, 2008 at 12:06 AM, Siarhei Siamashka [EMAIL PROTECTED] wrote: On Thursday 25 September 2008, Felipe Contreras wrote: On Thu, Sep 25, 2008 at 10:07 PM, Siarhei Siamashka [...] Now regarding why we may want it. Once if we get a good, low latency, fully functional and reliable ALSA sound driver running on ARM, it gives maemo community a nice possibility to scrap all the proprietary DSP binaries. This provides us with a new and shiny 252MHz C55x DSP core ready to be used by something else :) Free linux DSP toolchain from TI [4] supports generation of both DSP kernel and DSP tasks for OMAP1 based devices which is sufficient for DSP development. The toolchain license was supposed to permit open source development (with noncommercial restriction), though the license text itself is a bit questionable [5]. With DSP avalable for use and having no need to spend efforts on ensuring compatibility and peaceful coexistence with proprietary binary codecs (free and proprietary code does not mix well), it should be possible to turn Nokia 770 into quite a powerful media player. Great stuff! Do you plan to use the dsp-gateway or dsp-bridge? Now as you mentioned that, it indeed makes sense to consider other alternatives if they exist. Do you have any links to the information about dspgateway vs. dspbridge comparison (features/performance/reliability)? Using dspgateway has a clear advantage that it is already included in the kernel. And dspgateway is more or less ok, though patching it a bit in order to improve performance will be required. Not really, but I've been thinking that a comparison would be useful. Perhaps some dummy DSP nodes and clients to test them on both would help. I have one for the dsp-bridge, but not dsp-gateway. -- Felipe Contreras ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: gstreamer on CHINOOK
On Mon, Oct 20, 2008 at 2:32 PM, Sphurti Durgade [EMAIL PROTECTED] wrote: Hi all , i am running a mp3 file on N810 with gst-launch-o.10 as : Nokia-N810-50-2:/media/mmc2/Audio/Dostana# gst-launch-0.10 playbin uri=file:///media/mmc2/Audio/Dostana/dostana02\(www.songs.pk\).mp3 it is able to play with playbin but the same file if i play with filesrc as : Nokia-N810-50-2:/media/mmc2/Audio/Dostana# gst-launch-0.10 filesrc location=/media/mmc2/Audio/Dostana/dostana02\(www.songs.pk\).mp3 ! dspmp3sink is not able to play :( exit with Nokia-N810-50-2:/media/mmc2/Audio/Dostana# gst-launch-0.10 filesrc location=/media/mmc2/Audio/Dostana/dostana02\(www.songs.pk\).mp3 ! dspmp3sink Setting pipeline to PAUSED ... Pipeline is PREROLLING ... Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: DSPClock ERROR: from element /pipeline0/dspmp3sink0: Could not determine type of stream. Additional debug info: gstdspmp3sink.c(1026): gst_dspmp3sink_render (): /pipeline0/dspmp3sink0: gst_dspmp3sink_loop_initialization Execution ended after 16846000 ns. Setting pipeline to PAUSED ... Setting pipeline to READY ... Setting pipeline to NULL ... FREEING pipeline ... Nokia-N810-50-2:/media/mmc2/Audio/Dostana# file info: MIME type : audio/mpeg Audio Codec: MPEG 1 Audio, Layer 3 (MP3) Channels: Stereo Sample rate : 44100 Hz Bitrate :128kbps does anyone know why playbin is able to play same file and not filesrc ? and why filesrc is not able to not determine type of stream. That's because filesrc doesn't determine the type of the stream. You need to add typefind after filesrc for that, or manually set the right caps. -- Felipe Contreras ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Installing scratchbox on Fedora 8: PERMISSION PROBLEMS
On Thu, Oct 23, 2008 at 8:40 PM, Darren Enns [EMAIL PROTECTED] wrote: Hello! I have just sent a reply to my previous reply :) I have gotten a bit further by 'cheating', but since you are a Fedora user, can you confirm to me the things that I did (on my own) to 'fix' my problems? e.g. what were/are *your* permissions on the '/tmp' directory? Did you have to 'zap' the '/proc/sys/vm/mmap_min_addr' file too? BTW, I do have the i386 targets installed/configured (as per the docs). Oh, the hoops that us non-Debian people have to jump through! :) Which version of maemo are you running? In the latest one you get useful messages telling you that you need to modify mmap_min_addr and vdso if needed. I haven't had any issues in Fedora 9 with Diablo. -- Felipe Contreras ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Projects Nokia should support (yours?)
On Sat, Nov 1, 2008 at 4:40 AM, Zeeshan Ali (Khattak) [EMAIL PROTECTED] wrote: Hi! On Mon, Oct 27, 2008 at 10:35 AM, Fred [EMAIL PROTECTED] wrote: Would VLC (http://www.videolan.org) be a good client ? There was a port for Maemo but it was underpowered. It has the capacity to be embedded and could be a very good all-purpose (all-codec) media player ... Perhaps this is one of the days when VLC developers regret the decision to not synchronize/collaborate with GStreamer when GStreamer was there? Since Nokia supports GStreamer for very obvious (to the maemo community) reasons, supporting a competitor project wouldn't be a very wise idea. Like supporting both Qt and GTK+? -- Felipe Contreras ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Projects Nokia should support (yours?)
On Sat, Nov 1, 2008 at 10:59 PM, Zeeshan Ali (Khattak) [EMAIL PROTECTED] wrote: Hi! Agreed, we have officially supported GStreamer and the excellent mplayer which can be wrapped if someone wants a (different) gui. VLC certainly doesn't classify as a killer app bearing these in mind IMHO. You missed my entire point. :) mplayer is also a competitor of GStreamer and afaik it is NOT officially supported by Nokia. MPlayer is a great application no doubt but so is VLC (afaik much more portable even) and therefore unfortunately faces the same fate. Something with more mileage, though still not really a killer app, would be working on optimisation of the backend libs that all three media players use (therefore any media player would benefit). But this will have to wait until we see what the hardware is capable of really. Which backend libs all three apps use? I think GStreamer is the perfect backend that all multimedia applications should be using if they are very serious about targeting Maemo. OTOH! I understand their reasons for not going for GStreamer since this will require a huge amount of work and also throwing off a huge amount of investment both MPlayer and VLC have put into their own stacks. GStreamer is not as lightweight as FFmpeg for example. I can see why MPlayer and VLC developers wouldn't want to use it as a backend. As a framework it's great though. The backends that Simon talks about are the ones that most projects share: libmad, libvorbis, x264 (which VLC guys started), etc. But must of the codec support comes from FFmpeg (both gst and vlc use it), and I don't see, for example, GStreamer developers optimizing the codecs for ARM as the FFmpeg guys are doing. But this is of course in the open source arena, when doing products you can't just use FFmpeg due to licensing issues. That's why GStreamer is more attractive to companies since it's extensible and proprietary modules can be developed. Android is following a completely different approach. It's providing the codecs themselves[1] in an Apache licence, so the open source community can compile and improve them, but companies can also include them in their products paying the licence fees, and contribute without granting patents. Also, Google is providing the codecs with OpenMAX IL interface, so GStreamer can already make use of them through gst-openmax [2]. In a similar fashion GStreamer can use proprietary DSP accelerated codecs through the OpenMAX IL interface. Anyway, coming back to the subject; I don't have a media player that suit my needs in the Maemo devices, so VLC looks like a nice alternative. But eventually, as Simon points out, it's more important to work on the backends that the different players can reuse, otherwise performance will be bad. [1] http://android.git.kernel.org/?p=platform/external/opencore.git [2] http://www.freedesktop.org/wiki/GstOpenMAX -- Felipe Contreras ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Projects Nokia should support (yours?)
On Sat, Nov 1, 2008 at 3:40 PM, Siarhei Siamashka [EMAIL PROTECTED] wrote: On Saturday 01 November 2008, Ryan Abel wrote: On Nov 1, 2008, at 5:47 AM, Simon Pickering wrote: Something with more mileage, though still not really a killer app, would be working on optimisation of the backend libs that all three media players use (therefore any media player would benefit). But this will have to wait until we see what the hardware is capable of really. Considering the hardware is already doing 720p with only NEON optimizations, well. . . . There are always ways to make a powerful hardware run as fast as a snail ;) Especially when excessively complex frameworks and layers are used, chances of having something implemented inefficiently in between get a bit higher. Yes, but as long as you avoid memory copies having 3 or 4 layers is a small price to pay if the the gist of the code is properly optimized. H.264 for example can consume a lot of CPU power so every optimization (on the processing code) counts. -- Felipe Contreras ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Errors compiling example_wavelaunch.c
On Wed, Nov 19, 2008 at 8:09 AM, Manish_Ssinghal [EMAIL PROTECTED] wrote: This is because the header file gst/gst.h is included in gstreamer folder. You should include the path of gstreamer folder in your include directory or you should include Gstreamer-0.10/gst/gst.h to remove that error. Yuou should use: pkg-config --cflags gstreamer-0.10 -- Felipe Contreras ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: glib without gio ?
On Thu, Dec 11, 2008 at 11:42 AM, Eero Tamminen eero.tammi...@nokia.com wrote: Hi, ext Cedric Cellier wrote: I'm currently writing an app for maemo, that require the GIO library (part of glib) for some basic things. I cannot find the gio library on scratchbox (nor does pkg-config). On my debian lenny, it comes with glib2.0, but apparently this is not the case on scratchbox. GIO was added to later Glib2.x version than the one in Diablo. Is this lib packaged anywhere ? Or do I have to go without GIO on the maemo platform ? The newer Glib version will be available for Fremantle (and is included into the recently published Fremantle SDK Alpha release). It would be nice to add a GIO package in maemo-extras. -- Felipe Contreras ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: glib without gio ?
On Fri, Dec 12, 2008 at 8:44 AM, Kamen Bundev bun...@gmail.com wrote: I meant GLib, sorry, no coffee yet. On Fri, Dec 12, 2008 at 8:43 AM, Kamen Bundev bun...@gmail.com wrote: GIO is part of GTK+, you can't add a GIO package without upgrading the whole GTK+. Why not? It's code, you can do whatever you want with it. Philip Van Hoof did it for maemo: http://pvanhoof.be/files/gio-ugly-maemo-port.tar.gz -- Felipe Contreras ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Does anyone know the mechanism in Nokia's LCD driver?
On Tue, Jan 13, 2009 at 12:05 PM, Igor Stoppa igor.sto...@nokia.com wrote: Hi, On Tue, 2009-01-13 at 18:06 +0800, ext Huang Gao (Gmail) wrote: Hi, Igor Stoppa: Thank you for your reply! So can I understand that this hardware FB is not contained in SDRAM or SRAM, and LCD will refresh itself from this hardware FB by its controller automatically, without the help of OMAP DMA channel? I'm in no way a display guy but iirc there are 2 modes for refresh: -auto: whatever is written to the framebuffer goes through straight to the LCD -manual: the image needs to be flushed to the LCD If you are interested, you can check it from the kernel source files. Would the manual mode help to avoid tearing? -- Felipe Contreras ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo 5 on OMAP3 dev board
On Sun, Jan 18, 2009 at 8:14 AM, Ryan Abel rabe...@gmail.com wrote: On Jan 17, 2009, at 8:13 PM, Mike Turquette wrote: I'm a developer at Texas Instruments. I'm interested in building as many pieces of Maemo 5 (especially Hildon) as possible for some of our OMAP3 development boards. Nokia is (or was, they've likely moved on to their own hardware by now) using Beagle Boards for internal testing, so it's certainly a feasible thing. Some of us use beagle boards, but that's more of a personal endeavour. According to Quim Gil, Juha Kallioinen is working on an experiment precisely for this[1] [1] http://www.mail-archive.com/maemo-developers@maemo.org/msg17757.html -- Felipe Contreras ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: scratchbox ide
On Tue, Jan 20, 2009 at 9:41 PM, Neil Jerram neiljer...@googlemail.com wrote: 2009/1/20 Frank Banul frank.ba...@gmail.com: I'm curious what development tools you use? Textedit is nice and all but I'm sure that there are better tools. I would be interested in an editor that supported more code oriented tasks. Any suggestions? Emacs? I have pretty extensive code-oriented needs, and it meets all of those (and more). And vim :) -- Felipe Contreras ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: multiple SDKs on the same sbox
On Mon, Feb 16, 2009 at 3:17 AM, Daniel Monteiro daniel_on...@yahoo.com.br wrote: Hello folks, long time since my last email here. I've been silently developing my games for Maemo,but now here I am with a new question regarding Freemantle: Can I have Freemantle and Gregalle in the same sbox? Does gregalle run on the same sbox version required for Freemantle? Or does freemantle run on sbox 1.04? Yes, it's possible I've written a script that setups different targets at the same time. I've cleaned it up (removed Nokia internal stuff) and put it here: http://gist.github.com/65120 Except I don't know the url of the Fremantle rootstraps. Cheers. -- Felipe Contreras ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: GStreamer plugins on Maemo5.0
On Mon, Feb 16, 2009 at 12:42 PM, charulatha.varadara...@wipro.com wrote: I am a newbie to maemo. I am trying to understand how multi-media applications work on Maemo. From my initial study, I understand that Gstreamer framework is used in Maemo. I am very eager to know the list of Gstreamer plugins that would be needed in Maemo 5.0 for playing multimedia. Any pointers in this regard would be greatly appreciated. Ideally you shouldn't use the GStreamer elements directly, but use playbin2, or the midas framework. In any case, for Fremantle most of the codecs will be used trough gst-openmax, and the rest of the elements would be the open source GStreamer ones, with some mux/demux proprietary exceptions. -- Felipe Contreras ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: qemu 0.10
On Mon, Mar 9, 2009 at 12:01 AM, Cornelius Hald h...@icandy.de wrote: Hi, I just saw that a new version of qemu was released. Did anyone try to use this with scratchbox? If I understand it correctly it should improve the compatibility with the tablets. Is it worth a try? http://www.nongnu.org/qemu/changelog.html http://www.phoronix.com/scan.php?page=news_itempx=NzEyNA I tried, it didn't work with threads... but now it's fixed in the repository: http://repo.or.cz/w/qemu.git?a=commit;h=c2764719914ff0c4d6c06adafea17629600f21ba Maybe the next stable release? -- Felipe Contreras ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: qemu 0.10
On Mon, Mar 9, 2009 at 11:27 AM, Cornelius Hald h...@icandy.de wrote: - Felipe Contreras felipe.contre...@gmail.com wrote: On Mon, Mar 9, 2009 at 12:01 AM, Cornelius Hald h...@icandy.de wrote: Hi, I just saw that a new version of qemu was released. Did anyone try to use this with scratchbox? If I understand it correctly it should improve the compatibility with the tablets. Is it worth a try? http://www.nongnu.org/qemu/changelog.html http://www.phoronix.com/scan.php?page=news_itempx=NzEyNA I tried, it didn't work with threads... but now it's fixed in the repository: http://repo.or.cz/w/qemu.git?a=commit;h=c2764719914ff0c4d6c06adafea17629600f21ba Maybe the next stable release? Thanks for your answer. How did you do it? What I did is: - Compiled qemu 0.10 - Copied the binary qemu-0.10.0/arm-linux-user/qemu-arm to /scratchbox/devkits/cputransp/bin/qemu-arm-0.10 - Changed /scratchbox/devkits/cputransp/etc/cputransp-methods to contain the line: qemu-arm-0.10 - Changed /scratchbox/users/conny/targets/DIABLO_ARMEL.config to contain SBOX_CPUTRANSPARENCY_METHOD=/scratchbox/devkits/cputransp/bin/qemu-arm-0.10 However this seems to be not enough (or completely wrong). When I try to run an ARM binary from inside scratchbox I get: [sbox-DIABLO_ARMEL: ~] ./hello /scratchbox/tools/bin/misc_runner: /scratchbox/devkits/cputransp/bin/qemu-arm-0.10: No such file or directory I hope you can help me on that, I really would like to see if the new qemu version solves some problems that I have. Hmm, I used scratchbox2, it so much easier to experiment with. I've learned my lesson of hacking scratchbox1 (don't do it :P). -- Felipe Contreras ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Anyone porting madplay
On Thu, Mar 12, 2009 at 6:16 AM, Bruce Forsberg bruce.forsb...@gmail.com wrote: I am porting madplay to DIABLO. I was wondering if anyone knows if this is already available or if someone else is doing it now. I see that the two things it depends on libmad0 and libid3tag0 have been ported. The reason for porting this is that I am working on a project that requires this. For those not familiar with madplay it is a console mp3 player. It would be interesting to try also mpg123. Supposedly it performs better. -- Felipe Contreras ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: mafw-lastfm 0.0.1
2009/10/5 Xabier Rodriguez Calvar xrcal...@igalia.com: O Ven, 02-10-2009 ás 17:59 +0300, Claudio Saavedra escribiu: [Since this is the initial release, I think it's OK to make a heads up in this mailing, in case anyone else is interested in cooperating with this project] mafw-lastfm is a last.fm scrobbler for maemo devices using the Media Application Framework, like the N900. This is its the initial release. It basically works: it sets your playing-now status and it scrobbles. Just excellent! I reviewed it and it is a very good job! I am already working on some patches to add some features, but I'll tell you when they are ready :) /me crosses his fingers for multiscrobble and libre.fm :) -- Felipe Contreras ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
New project announcement: gst-dsp, with beagleboard demo image
Hi, This is the first public release of gst-dsp; a native GStreamer plug-in to access Texas Instruments' DSP algorithms for OMAP3 platforms. The code came originally from a series of TI projects: tiopenmax[1], and libbridge[2]. gst-dsp replaces these two layers and talks directly to the DSP bridge driver. The main advantages are code simplification (5k vs 50k), and better performance (at least 4 times less CPU usage). However, not all of the codecs have been implemented, only MPEG-4 and H.263 video encoders and decoders, the JPEG encoder, and H.264 is partially supported. Currently it's used in the Nokia N900. In order to make it easier for people to try it out, I created a demo image for the beagleboard with all the required components: GStreamer, gst-dsp, DSP public binaries, and a kernel with DSS2 and DSP bridge driver. The linux kernel (DSS2 + dspbridge) is at the v2.6.32-felipec1 tag in: http://gitorious.org/~felipec/linux-omap/felipec The DSP algorithms are public, and come from tiopenmax: https://gforge.ti.com/gf/download/frsrelease/170/1399/tiopenmax-0.3.5.tar.gz Here's the demo rootfs with the kernel image and instructions: http://people.freedesktop.org/~felipec/beagle-2.6.32-rc3/ And here's the video showing it on action for both playback and recording: http://www.youtube.com/watch?v=SN-Nw_yDQUs The main repository is hosted on github: http://github.com/felipec/gst-dsp And there's also one specific for maemo: http://maemo.gitorious.org/maemo-multimedia/gst-dsp This code wouldn't have been possible without all the contributions and specially thanks to TI for making their code open source. Here's the shortlog for 0.6.0: Andriy Shevchenko (1): base: fix a crash on send codec data Felipe Contreras (180): Initial commit Register dsp node Add README Fix and update copyrights Add ALLOCATE_HEAP and ALLOCATE_SN to dsp_bridge Add handy dsp_send_message dummy: use dsp_send_message Rename gstdsp.* to plugin.* Makefile: cleanup dummy: trivial clanups Add log utility Use log utility dmm_buffer: size_t improvements dmm_buffer: always unmap when freeing dmm_buffer: use getpagesize() dmm_buffer: alignment improvements dmm_buffer: add user_data field Add MPEG-4 video decoder README: update mp4vdec: trivial cleanup mp4vdec: send signal to output_loop mp4vdec: flush output buffers too mp4vdec: reset output port mp4vdec: extra check for null buffer mp4vdec: use atomic operations for status mp4vdec: use more atomic operations for status mp4vdec: send stop signal before mp4vdec: re-use comm buffers dmm_buffer: reorganize a bit dmm_buffer: add dmm_buffer_reserve dmm_buffer: allow to re-reserve memory dmm_buffer: allow re-mapping mp4vdec: trivial cleanup dmm_buffer: unmap before unreserving mp4vdec: re-use mappings for output buffers mp4vdec: convert flush condition to semaphore Remove cond.h Rename mp4vdec to vdec vdec: trivial cleanup vdec: trivial reorganization vdec: prepare for multiple algos vdec: move create_node to dsp_start vdec: start dsp node after getting the caps vdec: initial support for H.264 vdec: add Juha to authors list README: update vdec: cleanup vdec: make dsp_thread static vdec: reorganize a bit New base class Add new video encoder base: handle more commands base: reorganize got_message a bit venc: improve jpeg args venc: send jpeg dynamic params base: cleanup setup_output_buffers base: remove unused buffer_count base: reorganize a bit base: add use_pad_alloc option base: free mapped buffers on dsp_stop() base: be more verbose on get_slot() README: update Makefile: check for missing symbols New utility gstdsp_register() base: detect dsp errors base: properly handle dsp errors base: post error in the bus base: extra check for status in outout_loop() base: free events array base: reinitialize state on NULL-READY base: use circular buffer for timestamps base: increase ts_array base: increase mapping cache dummy: reorganize map_buffer dummy: input buffers don't need alignment dummy: cleanup dummy: don't map buffers venc: increase framesize limit for jpeg base: add gstdsp_post_error() venc: allocate a buffer when framesize is unaligned base: decrease wait for events timeout base: more error messages base: re-initialize on READY-PAUSED base: don't panic on wrong status base: destroy node at the right time base: catch playback completed message base: possible memleak fixes vdec: send codec data for MPEG-4 base: make map cache optional plugin: set more
Re: New project announcement: gst-dsp, with beagleboard demo image
On Tue, Oct 13, 2009 at 12:31 AM, Felipe Contreras felipe.contre...@gmail.com wrote: Hi, This is the first public release of gst-dsp; a native GStreamer plug-in to access Texas Instruments' DSP algorithms for OMAP3 platforms. The code came originally from a series of TI projects: tiopenmax[1], and libbridge[2]. gst-dsp replaces these two layers and talks directly to the DSP bridge driver. The main advantages are code simplification (5k vs 50k), and better performance (at least 4 times less CPU usage). However, not all of the codecs have been implemented, only MPEG-4 and H.263 video encoders and decoders, the JPEG encoder, and H.264 is partially supported. Currently it's used in the Nokia N900. In order to make it easier for people to try it out, I created a demo image for the beagleboard with all the required components: GStreamer, gst-dsp, DSP public binaries, and a kernel with DSS2 and DSP bridge driver. The linux kernel (DSS2 + dspbridge) is at the v2.6.32-felipec1 tag in: http://gitorious.org/~felipec/linux-omap/felipec The DSP algorithms are public, and come from tiopenmax: https://gforge.ti.com/gf/download/frsrelease/170/1399/tiopenmax-0.3.5.tar.gz Here's the demo rootfs with the kernel image and instructions: http://people.freedesktop.org/~felipec/beagle-2.6.32-rc3/ And here's the video showing it on action for both playback and recording: http://www.youtube.com/watch?v=SN-Nw_yDQUs I removed the video because of a bug in YouTube and uploaded it again: http://www.youtube.com/watch?v=CjxkNIHBGdI Cheers. -- Felipe Contreras ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Profiling applications (oprofile, others?)
On Thu, Dec 3, 2009 at 9:31 AM, Henrik Hedberg henrik.hedb...@innologies.fi wrote: Alberto Mardegan wrote: since fremantle's maemo-mapper is so horribly slow, I went and tried to run oprofile. Unfortunately it seems to me that static functions never appear in the final report. Is this how it is supposed to work? Your binary may lack frame pointers. See [1]. That documentation is incorrect. Siarhei Siamashka wrote a hack in the kernel so that recompiling with framepointers is not needed any more :) Maybe you just need debug symbols. -- Felipe Contreras ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: ?Ogg Vorbis support hw-accelerated
On Thu, Feb 11, 2010 at 2:08 PM, Gunter Ohrner g.ohr...@post.rwth-aachen.de wrote: I'll have to check whether ffvorbis is already used in the current ogg- support- or extra-codec-packages available at maemo.org, or does anyone here already know for a chance? Not AFAIK, I think Tuomas wanted a few features in gst-av[1] before going that way. I haven't had time to work on that. [1] http://github.com/felipec/gst-av -- Felipe Contreras ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: GStreamer, mp3 playback and the DSP
Hello, On Sat, Apr 10, 2010 at 3:29 PM, javicq jcqma...@ovi.com wrote: I'm currently using GStreamer to play mp3 files. I'm trying to move all mp3 decoding to the DSP but I'm unable to find any useful info on the matter. The only thing i got so far is this paragraph from the wiki: http://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/Architecture/Multimedia_Domain#Audio_Codecs Unfortunately that documentation is outdated. By the time N900 was released the audio codecs were not using OpenMAX IL, but that's irrelevant as the codecs were always meant to run on ARM side. -- Felipe Contreras ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: GStreamer, mp3 playback and the DSP
On Sun, Apr 11, 2010 at 12:01 AM, Javier S. Pedro ma...@javispedro.com wrote: Simon Pickering wrote: So yes, my understanding is that that is exactly what's involved, therefore it should be possible to write an OpenMAX compliant codec that uses the DSP bridge to transfer data back and forth to a decoder running on the DSP. There's a already a OpenMAX compliant MP3 decoder, the Palm Pre uses it. (mp3dec_sn.dll64P dsp side, libOMX.TI.Mp3.decode.so arm side). Unfortunately, I don't know the licensing of it, and Nokia for sure is not including it. I don't know which specific version of TI's MP3 decoder is Palm using, but you can find public versions of it from TI (not sure if you can distribute them): http://www.omapedia.org/wiki/L23.i3.3_Release_Notes I haven't tried this, but my guess is that simply sending buffers back and forth to the DSP would take more CPU, specially taking into account the OpenMAX overhead. The most efficient way to do this would be to add support for MP3 decoding to gst-dsp (bypassing OpenMAX). Then profiling would be needed in order to tune gst-dsp for audio (audio buffers are much smaller). You can try dsp-dummy to simulate MP3 decoding and see if it's worth the trouble. An alternative would be to take FFmpeg's MP3 decoder and see if there's any NEON optimizations that can be done. In fact, Nokia explicitly chose to remove the audio DSP decoders from the firmwares (see gst-openmax Maemo patches), probably to save rootfs space since the builtin media player would not be using them (for powersaving reasons). It would be nice if we could get a word or two from above about shipping those as an extras package, for the use cases like the one described by the OP. gst-openmax is just a wrapper in order to use OpenMAX IL components; there's no point in including the omx_mp3dec element if it's going to fail due to missing omx component. First you would need the DSP socket-node, then the omx component (libOMX.TI.Mp3.decode.so), and then it would make sense to add the element to gst-openmax. This would require modifications to gst-openmax and could be done as a separate package. I imagine/hope the N900 + DSP bridge setup is better, but I really don't know. Does anyone know? Could a Nokian tell us about the possibility of direct audio output from the DSP and how efficient the data passing is in the absence of direct audio output? I am not an authority here either, but remember that audio to the speakers should pass through PulseAudio's HP filter, or else they might be damaged. (http://talk.maemo.org/showthread.php?t=36555). So I guess the question is indeed the latter one :) Yeah, I don't know if it's possible to do that, but I wouldn't try. Cheers. -- Felipe Contreras ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: DSP n900
On Tue, Apr 13, 2010 at 6:46 AM, victor fragoso geektor2...@gmail.com wrote: I just wonder if someone has a link or useful information about programming the DSP from the n900. Try googling for: omap3 dsp -- Felipe Contreras ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: oprofile on ARM
On Sun, Apr 11, 2010 at 10:46 AM, Alberto Mardegan ma...@users.sourceforge.net wrote: again I've tried to profile Mapper on the N900, with no results. First I tried gprof, but it gives me all 0.0 times (and a google search reveals that this is a common problem in maemo, even though I didn't find an explanation of it); then I tried oprofile, which gives me an output like this: == samples % image name symbol name 3007 38.3497 no-vmlinux /no-vmlinux 1083 13.8120 libclutter-eglx-1.0.so.0.8.0 /usr/lib/libclutter-eglx-1.0.so.0.8.0 424 5.4075 libc-2.5.so memcpy 336 4.2852 libpng12.so.0.37.0 png_do_expand_palette 317 4.0429 libz.so.1.2.3 /usr/lib/libz.so.1.2.3 286 3.6475 libGLESv2.so /usr/lib/libGLESv2.so 219 2.7930 ld-2.5.so do_lookup_x 120 1.5304 libglslcompiler.so /usr/lib/libglslcompiler.so 55 0.7014 libc-2.5.so _int_malloc 48 0.6122 libpthread-2.5.so pthread_mutex_lock 44 0.5612 libpixman-1.so.0.15.3 fbCompositeSolidMask_nx8xneon 36 0.4591 libsrv_um.so /usr/lib/libsrv_um.so 35 0.4464 libc-2.5.so malloc 35 0.4464 libsqlite3.so.0.8.6 /usr/lib/libsqlite3.so.0.8.6 34 0.4336 libc-2.5.so memset 34 0.4336 libglib-2.0.so.0.2000.3 g_slice_alloc 32 0.4081 libglib-2.0.so.0.2000.3 g_hash_table_lookup [...] == (I got this output after moving the oprofile collected data into Scratchbox) But this doesn't help me, as Mapper's own functions appear on the bottom of the list and seem to take very little time. I tried to use the -c option of opreport to see the call graph, but it doesn't seem to be working properly, as for every function it gives this output: == --- 336 4.2852 libpng12.so.0.37.0 png_do_expand_palette 336 100.000 libpng12.so.0.37.0 png_do_expand_palette [self] --- == It seems it cannot resolve the caller, why? Did you try to reinitialize OProfile? One more question: how can I see the total time taken by a function? I would expect to see the main() function of Mapper at the top of the list, as it's clearly the function that takes most time, but it doesn't even appear in the list at all. So I assume that these times are net (that is, the time spend in subroutines is excluded from the function times), which might be useful in some case, but it definitely prevents me from knowing what functions in Mapper need to be optimized... I use Gprof2Dot for that: http://wiki.jrfonseca.googlecode.com/hg/gprof2dot.png I just added some basic information for this here: http://elinux.org/OProfile Cheers. -- Felipe Contreras ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
[ANN] maemo-scrobber 1.0 for last.fm + libre.fm
Hi, maemo-scrobbler is a scrobbler application (last.fm/libre.fm) for the Nokia N900 that listens for events coming from the official media player app through MAFW. You can configure your accounts through the control panel. The inspiration (and some code) comes from mafw-lastfm which does basically the same thing, but lacks some features. For more on mafw-lastfm see below. Compared to mafw-lastfm, maemo-scrobbler has: 1) Support for multi-scrobbling (both last.fm and libre.fm at the same time) Includes a song queue per service. 2) Improved song queue handling Since internally it uses libscrobble (which is independent of MAFW), the important code can be easily tested on desktop sw, and it has been done so… throughly. It doesn’t matter how flaky your network is, or that the servers are down, the songs will be submitted. 3) Permanent storage The song queue is not lost, even on crashes, device reboots, or software updates. 4) Video clips are ignored Small feature, but important. In other words: maemo-scrobbler Just Works™ ;) It's now on extras testing, please give it a try and vote up: http://maemo.org/packages/view/maemo-scrobbler/ For more info and the source code, check github: http://wiki.github.com/felipec/maemo-scrobbler/ == mafw-lastfm == Initially I tried to improve mfaw-lastfm, but I noticed so many problems that I decided to start from scratch, and soon I had all the functionality I wanted. Then I brought up all the problems to the mailing list [1], and I tried to contribute to mafw-lastfm [2], some trivial patches got in, but the important ones [3] did not. That was back in February, and at that point Claudio (the maintainer) decided to wait until a stable release (0.0.4), which was done in April. We are now in June and I haven't heard anything. So I decided to implement the missing pieces and provide what IMO is supperior software (at the very least it does what I need, and hopefully you would like it too). Cheers. [1] https://garage.maemo.org/pipermail/mafw-lastfm-devel/2010-January/26.html [2] https://garage.maemo.org/pipermail/mafw-lastfm-devel/2010-January/62.html [3] https://garage.maemo.org/pipermail/mafw-lastfm-devel/2010-February/68.html -- Felipe Contreras ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: [mafw-lastfm-devel] [ANN] maemo-scrobber 1.0 for last.fm + libre.fm
Hi Claudio, On Thu, Jun 3, 2010 at 6:48 AM, Claudio Saavedra csaave...@igalia.com wrote: On Thu, 2010-06-03 at 03:46 +0300, Felipe Contreras wrote: We are now in June and I haven't heard anything. This is just not true. To your inquire back in April, this is what I replied: https://garage.maemo.org/pipermail/mafw-lastfm-devel/2010-April/77.html I thought you'd follow up with what I commented as the two main reasons why I didn't consider libscrobble at that point yet, but since you didn't I just continued fixing issues in my code as time allowed. Ah, I didn't reply: 1. No now-playing notification Not a blocker IMO. In fact at least last.fm seems to understand just fine that the last scrobbled song is Now Playing due to the timestamp. So I fail to see what functionality users will miss. 2. No scrobbling right after the track has finished. I'm not sure what that means, but if it's related to the fact that I decided to scrobble songs each 10 minutes. First, I told you that it's not a limitation of libscroble, it's up to the client (maemo-scrobbler/mafw-lastfm) to call sr_session_submit() when it sees fit[1]. And second, I changed maemo-scrobbled back in January to do what you wanted[2]. Also, in the pathches for libscrobble I sent I called sr_session_submit() right after metadata_callback(). Therefore, as I mentioned, there's no change. The patch is small, so it's easy to see what's happening: https://garage.maemo.org/pipermail/mafw-lastfm-devel/2010-February/70.html So essentially the only drawback was support for Now Playing, which is not important to me (if even needed), but it's easy to implement, you could have done so easily. 1) Support for multi-scrobbling (both last.fm and libre.fm at the same time) Includes a song queue per service. I haven't worked on this yet, because I was fixing other issues that were more important. I list them below, even when I am sure that you know already. Yes, and I don't agree with the priorities. To me, as a user, I don't care if I cannot scrobble from certain proxified connections to last.fm, because even if I do, it would only be to last.fm. So, mafw-lastfm provides at best 50% of what I need (more like 40%); that's not acceptable. 2) Improved song queue handling Since internally it uses libscrobble (which is independent of MAFW), the important code can be easily tested on desktop sw, and it has been done so… throughly. It doesn’t matter how flaky your network is, or that the servers are down, the songs will be submitted. I have fixed all the issues with the network handling for at least a month now (these were released in 0.0.5). Well, that's easy to say. I would need to review the code to even be slightly confident that that's true. And of course, even if I don't see any problems... that's not a guarantee that _all_ the problems are fixed. I also implemented support for scrobbling behind proxies[1], which is in a branch in gitorious waiting to get some testing from users. Yes, as I said before, I don't think that's important. 3) Permanent storage The song queue is not lost, even on crashes, device reboots, or software updates. I have also implemented permanent storage during last week and it's working fine. I am planning to do a release including this during this week, but I was waiting for some translations to come in first [2]. Perhaps it's working fine, or perhaps it has issues with UTF-8, or perhaps (quite likely) it's implemented in a non-extensible way which would require many changes once multi-scrobbling is supported. I can tell you from experience that the latter is quite likely. In any case, you _knew_ libscrobbler supported this, and yet, instead of adding the missing features to libscrobbler, you decided to implement this yourself. 4) Video clips are ignored Small feature, but important. In the same email I link above, I replied to you that I wasn't against implementing this if there was broader interest from users. Since I didn't get much more feedback on this regard it was low in my priorities. Well, I saw many more users asking for this than proxy support. [...] Then I brought up all the problems to the mailing list [1], and I tried to contribute to mafw-lastfm [2], some trivial patches got in, but the important ones [3] did not. That was back in February, and at that point Claudio (the maintainer) decided to wait until a stable release (0.0.4), which was done in April. We are now in June and I haven't heard anything. Well, as I said already, I told you clearly what were my concerns regarding libscrobble. Instead of following up on the discussion, you preferred to go your own way and implement yet another scrobbler. Good on you. I already had implemented my own scrobbler in January. I have waited and waited in the hopes that we could work together in mafw-lastfm. Five months holding back my sw is just too much. So I decided to implement
Re: [mafw-lastfm-devel] [ANN] maemo-scrobber 1.0 for last.fm + libre.fm
On Thu, Jun 3, 2010 at 10:55 AM, Menno Jansz me...@jansz.com wrote: On Thu, 3 Jun 2010 03:46:25 +0300, Felipe Contreras felipe.contre...@gmail.com wrote: In other words: maemo-scrobbler Just Works™ ;) mafw-lastfm just works too... Good for you. Perhaps din't noticed the problems fixed in 0.0.5 (Do not lose cached tracks after returning from offline.) and 0.0.6 (Plug a very nasty leak.), or perhaps you just don't care. These problems were never present in maemo-scrobbler, even from Day 1 (before being public), because I decided to start from a platform-independent library that was easy to test without a real client. So I wrote scripts to generate fake playlists and try different scenarios in a systematic manner from my desktop. The testing included memory leaks detection with valgrind, and resource profiling with OProfile. All this things are very difficult/impossible to do when you are working directly on the device through MAFW. Only when libscrobbler was working perfectly from my desktop did I try to write a MAFW client. Initially I tried to improve mfaw-lastfm, but I noticed so many problems that I decided to start from scratch, and soon I had all the functionality I wanted. Whilst it's your prerogative to re-invent the wheel, as a happy user I feel I should point out that it does seem you are belittling Claudio's effort with the tone of your email. I'm not reinventing the wheel. Nobody (including mafw-lastfm) is providing a platform-independent, simple, well-tested, freedesktop-friendly scrobbling library. This library can be used on GNOME, Xfce, Meego, any music player, or an independent D-Bus service. So now that we have such a library, perhaps it would make sense to use it in Maemo? I tried that with mafw-lastfm, didn't stick, so now I'm trying with maemo-scrobbler. Cheers. -- Felipe Contreras ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: [mafw-lastfm-devel] [ANN] maemo-scrobber 1.0 for last.fm + libre.fm
On Thu, Jun 3, 2010 at 2:30 PM, Claudio Saavedra csaave...@igalia.com wrote: On Thu, 2010-06-03 at 12:39 +0300, Felipe Contreras wrote: Ah, I didn't reply: 1. No now-playing notification Not a blocker IMO. That's *your* opinion. For me, moving to a library that causes loss of functionality is a no-go unless there are very good reasons to do it, which was not the case, IMO. Fine. Take the malevolent dictator approach of maintaining. Have you considered asking your users? For me it's very simple: mafw-lastfm: last.fm: scrobble: yes, now playing: yes libre.fm: scrobble: no, now playing: no maemo-scrobbler: last.fm: scrobble: yes, now playing: no libre.fm: scrobble: yes, now playing: no I think most users would agree that scrobbling is by far #1 use-case of a scrobbler. Moreover, we are talking about a mobile device, that can be disconnected from the Internet a good portion of the day, this whole time now playing wouldn't work, and even after connecting to a network, there can be a delay up to 2 hours before the handshake to the service is established. If that was not enough, now playing is a feature that users would barely notice (it's just a hint on certain pages of the web interface). So, considering this, first, I would implement network connection detection, and only then now playing makes sense. But I don't see from which point of view multi-scrobbling is lower priority than now playing. In fact at least last.fm seems to understand just fine that the last scrobbled song is Now Playing due to the timestamp. So I fail to see what functionality users will miss. Not really. A very recently scrobbled track will be displayed as Just played. The only way to display a track as now playing is through the now playing notification. Right, what a huge loss of functionality. 2. No scrobbling right after the track has finished. I'm not sure what that means, but if it's related to the fact that I decided to scrobble songs each 10 minutes. First, I told you that it's not a limitation of libscroble, it's up to the client (maemo-scrobbler/mafw-lastfm) to call sr_session_submit() when it sees fit[1]. And second, I changed maemo-scrobbled back in January to do what you wanted[2]. Also, in the pathches for libscrobble I sent I called sr_session_submit() right after metadata_callback(). Therefore, as I mentioned, there's no change. Well, it makes a huge difference to know when a problem doesn't exist anymore. You could have said this back then when I commented it, but it seems you were expecting me to follow your progress or dig into your code just because you deserve it. As I already explained many times: THERE IS NO ISSUE; never was. libscrobble works fine in both scrobbling modes; I didn't make any change; the change was done in the client: maemo-scrobbler which is irrelevant for mafw-lastfm. If you had actually read the patches I sent for libscrobble support, you would have seen that. I haven't worked on this yet, because I was fixing other issues that were more important. I list them below, even when I am sure that you know already. Yes, and I don't agree with the priorities. To me, as a user, I don't care if I cannot scrobble from certain proxified connections to last.fm, because even if I do, it would only be to last.fm. But *you* are not the average user, so please excuse me for not following your needs to set my priorities. After all, you've shown enough skills to supply for your needs yourself :) So you discriminate certain kinds of users? See http://bugs.libre.fm/wiki/clients, there are many clients that support multi-scrobbling. Certainly they must think that it's important somehow. So, mafw-lastfm provides at best 50% of what I need (more like 40%); that's not acceptable. Not acceptable for *you*. It's perfectly fine if you disagree on what's necessary or not for a piece of software, just please don't come to me telling me what I need to focus on just because something doesn't work as you expect it. It's not about me; you have 0% support for libre.fm users. I have fixed all the issues with the network handling for at least a month now (these were released in 0.0.5). Well, that's easy to say. I would need to review the code to even be slightly confident that that's true. And of course, even if I don't see any problems... that's not a guarantee that _all_ the problems are fixed. Do you really want to go into this sort of non-constructive debate? I don't. And I obviously meant that I fixed all issues known. And that no new issues have arose since then. No, I was just highlighting the possibility that there still are issues there. And to prevent further debate: my best guess is that mafw-lastfm has more bug potential in this area (I would have to re-review the code). Since I know both code-bases, I guess my opinion is worth at least considering, you can disagree, no need to continue arguing. I also implemented support
Re: [mafw-lastfm-devel] [ANN] maemo-scrobber 1.0 for last.fm + libre.fm
On Thu, Jun 3, 2010 at 4:41 PM, Alberto Garcia agar...@igalia.com wrote: On Thu, Jun 03, 2010 at 04:10:28PM +0300, Felipe Contreras wrote: mafw-lastfm: last.fm: scrobble: yes, now playing: yes libre.fm: scrobble: no, now playing: no maemo-scrobbler: last.fm: scrobble: yes, now playing: no libre.fm: scrobble: yes, now playing: no [...] now playing is a feature that users would barely notice Well, that's a respectable opinion, but I for one consider it one of the most basic features of any Last.fm client. Well, basic, yes, but important? Can you live with the web interface showing just listened vs now playing? Or, what would you rather have a) rock-solid queue handling, or b) support for now-playing? In a mobile device I think a) is more important, but in a desktop I think b) is probably the case. Besides, I believe the best mafw-lastfm can do right now is; if you are disconnected for two hours, when you are connected back, you don't have now-playing until two hours pass. I would not consider that top-notch support for now-playing. So, I don't think loosing that _temporarily_ in favor of a more generic library with other benefits (IMHO better suited for mobile) is a bad trade-off. In any case, I filed an issue for that... you are welcome to vote up: http://github.com/felipec/maemo-scrobbler/issues#issue/1 And not that I have anything against Libre.fm (quite the contrary), but I'd say that at this moment it is the lack of Libre.fm support the feature that most users won't notice. Yes, but we agree that there must be some users out there, right? (otherwise other clients would probably not have implemented multi-scrobbling). Now, would you rather keep a feature that's not essential to the majority of users, and probably quite marginal, than providing support for libre.fm users, who can do nothing at all? IOW; taking a bit from the majority, to give a lot to the minority. I think not doing that is egotistical. Anyway, it's probably not worth discussing more. I decided not to provide now-support and concentrate on multi-scrobbling for v1.0, but I will do so soon. Feedback is appreciated if you feel this is an important feature, specially in the form of votes in the issue tracker. Cheers. -- Felipe Contreras ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: [ANN] maemo-scrobber 1.0 for last.fm + libre.fm
On Thu, Jun 3, 2010 at 4:15 AM, Felipe Contreras felipe.contre...@gmail.com wrote: On Thu, Jun 3, 2010 at 3:57 AM, Kevin Neely ktne...@astroturfgarden.com wrote: That sounds great. Is there a place to place a suggestion, other than filing a bug? My recommendation would be to also (perhaps optionally) ignore podcasts. Not really. Perhaps it would make sense to create a mailing list. For now I think maemo-devel would be ok. Apparently the maemo-scrobbler discussion is hurting the sensibilities of mafw-lastfm developers (whomever they might be). So I've created a new mailing list: https://groups.google.com/group/libscrobbler You are welcome to discuss feature requests there, both for Maemo, and other systems. -- Felipe Contreras ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: [mafw-lastfm-devel] [ANN] maemo-scrobber 1.0 for last.fm + libre.fm
On Thu, Jun 3, 2010 at 4:10 PM, Felipe Contreras felipe.contre...@gmail.com wrote: Anyway, my priorities for next are: network detection, then now playing, then proxy support. I'm not sure how much it will take me, but definitely not five months. Patches are welcome. In fact, I just released maemo-scrobbler 1.1-1 with all those 3 features: * Add support to detect network connections * Add support for Now-Playing * Add proxy support I tested by setting up a proxy, playing some stuff (now-playing works), then switch to a non-proxied connection, play more stuff (now-playing still works), then go offline, wait a few minutes, go back online, play more stuff (now-playing still works). This is the last one to mafw-lastfm ml... for real :p Enjoy! -- Felipe Contreras ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: [mafw-lastfm-devel] [ANN] maemo-scrobber 1.0 for last.fm + libre.fm
On Fri, Jun 4, 2010 at 5:22 AM, Felipe Contreras felipe.contre...@gmail.com wrote: On Thu, Jun 3, 2010 at 4:10 PM, Felipe Contreras felipe.contre...@gmail.com wrote: Anyway, my priorities for next are: network detection, then now playing, then proxy support. I'm not sure how much it will take me, but definitely not five months. Patches are welcome. In fact, I just released maemo-scrobbler 1.1-1 with all those 3 features: * Add support to detect network connections * Add support for Now-Playing * Add proxy support I tested by setting up a proxy, playing some stuff (now-playing works), then switch to a non-proxied connection, play more stuff (now-playing still works), then go offline, wait a few minutes, go back online, play more stuff (now-playing still works). This is the last one to mafw-lastfm ml... for real :p Oh, and I forgot to mention that quite a bit of code chunks come from the work from Claudio. It would have taken me much longer to find all that information myself. Thanks! -- Felipe Contreras ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Building pulseaudio for N900
Hi, Cc'ing some people that might have some idea. On Sun, Aug 22, 2010 at 11:52 PM, tarantism tarant...@ntlworld.com wrote: On Sun, 2010-08-22 at 18:33 +0100, tarantism wrote: After many hours in autotool hell, ... blah blah ... ... more blah Am I missing something in the build procedure? No. Just a badly 'installed' libtool upgrade to 2.2. I had the binary on the path but not the lib and include files. I have found scratchbox very difficult with out-of-date autotools packages. To build pulseaudio requires: autoconf = 2.63, automake =1.10 and (due to a bug it appears) libtool = 2.2 (?). None of these are available via apt-get and manually installing files into scratchbox is v. difficult (I suspect I've completely screwed my installation but hey-ho). What am I doing wrong? Is there a better way? -- Felipe Contreras ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
[ANN] gst-dsp 0.8.0 released
Hi, gst-dsp is a GStreamer plug-in to utilize Texas Intruments' DSP algorithms for OMAP3 platforms using the tidspbridge driver. [I forgot to post this on maemo/meego mailing lists, so here it goes, please CC gst-...@googlegroups.com if you reply] This is a major release, many features have been implemented: * Refactoring of DMA API * Fixes for newer DSP API versions * Add JPEG decoder implementation * Fix WMV support * Reorganize the way EOS is handled * Improve H.264 keyframe handling * Improve deinitialization on fatal errors (like MMU faults) * Fixes for ARMv7 speculative pre-fetching * Several improvements for encoding bitrate calculation * Add support for I420 color format * Correctly propagate aspect-ratio And the usual bunch of cleanups and reorganization. Also it's worth noting that this code has been tested on Nokia N900, beagleboard, and future Nokia hw; with different DSP binaries; L23.i3.8, L23.i3.3, and 0.3.5; and different DSP bridge driver versions. For very old binaries, build with DSP_API=0, it's not necessary to set SN_API yet, as the structures are binary compatible with all the versions. Moreover, this time I decided to package, this, and some related packages in tarballs in order to help some distributions: http://code.google.com/p/gst-dsp/downloads This time we have slightly more contributors, including even some patches from TI. Thanks everyone! Unfortunately this is still not ready for 1.0, the parsers need to be cleaned up, fixed, and merged. And once tidspbridge 0.4 is tagged, move to the new DMA API ioctls. Finally, most likely the core of gst-dsp will move to a separate library (not related to GStreamer): libtidsp, in order to be useful in other projects. A sample of that has been submitted to FFmpeg for review: http://article.gmane.org/gmane.comp.video.ffmpeg.devel/116798 Enjoy ;) Arvind Gupta (3): vdec: MPEG4 sn to use double buffer hack: venc: strip SPS and PPS headers on keyframes vdec: return last frame EOS from MPEG4, H.263 and WMV decoders Felipe Contreras (111): venc: fix default mode base: reorganize status check in output_loop() base: reorganize error checks in output_loop() log: fix log level 3 when DEBUG is on base: continue deinit on errors base: make sure stop message was sent base: detect algorithm errors base: don't print messages as errors base: reorganize error handling a bit base: exit dsp_thread more cleanly Allow more granularity in dspbridge API build: add DSP_API option Plug a few memleaks when node_create() fails bridge: trivial cleanups bridge: fix a small exceptional leak vdec: always clear params build: add option for socket-node API version Trivial cleanups dmm-buffer: we are using a proc handle, not node base: avoid yoda conditions base: improve send_buffer() venc: remove unnecessary buffer_clean()s dummy: invalidate before sending vdec: remove h264dec_in_stream_params Trivial cleanups base: check for errors in dsp_wait_for_events() base: avoid buffer duplication on corner-case Refactor some code into dmm_buffer_calloc() Refactor code into gstdsp_port_setup_params() Add new gstdsp_send_alg_ctrl() base: free alg_ctrl on exceptions Rework cache maintainance functions base: always invalidate out buffers afterwards Add DMA direction information Start using new DMA API dmm-buffer: remove _unmap() dmm-buffer: we know the page size dmm-buffer: let's not be too smart about unreserve dmm-buffer: put map and reserve together Manually call dmm_buffer_map() Add manual calls to dmm_buffer_unmap() dmm-buffer: remove clean/invalidate/flush build: general improvements venc: fix for MPEG-4 SN_API=1 venc: add keyframe-interval property Move ARRAY_SIZE to util.h vdec: log actual SN used Trivial improvements venc: improve bitrate calculation vdec: propagate aspect-ratio Support multiple SN_API's venc: register conversions library for jpegenc venc: fix jpegenc params Remove unnecessary assigns build: add dist target bridge: fix bad ioctls bridge: update copyright log: generic improvements vdec: fix trivial warning build: check for deprecated gst stuff Fix depreated stuff from gst vdec: trivial cleanup Create ports in base class log: trivial whitespace cleanups Update copyright notices Update licence notices Add LICENSE file build: only link to needed libraries get-version: trivial improvements build: a bit more warnings parse: fix compilation warning base: don't loose buffers on EOS base: fix a non-atomic check for self-status base: use atomic 'deferred_eos' instead of 'eos' base: reorganize EOS handling base: remove redundant checks for use_eos_align
[ANN] gst-openmax 0.10.1 stable release
Hi,
It has been a long time but finally it's here; the first stable
release of gst-openmax. Most likely it has been stable for quite some
time, but only now the code-style has migrated to GStreamer one, and a
bunch of patches from TI have been merged, so it seems like a good
time to release.
Also, this version now features a configuration mechanism, so you can
select pretty much every combination of GStreamer elements you might
need, and specify the OpenMAX IL library, component name, role, and
even your desired rank.
gst-openmax has been tested in multiple OpenMAX IL implementations,
such as Bellagio, and Texas Instrument's OMAP. Depending on the
implementation some changes might be needed, but ideally it should
work straight out-of-the-box. If you find that some changes are
needed, please contribute the changes back.
Elements supported
* MPEG-4 encoder/decoder
* H.263 encoder/decoder
* H.264 encoder/decoder
* WMV decoder
* Vorbis decoder
* MP3 decoder
* Volume filter
Experimental elements (should work but not extensively tested)
* AMR-NB encoder/decoder
* AMR-WB encoder/decoder
* AAC encoder/decoder
* MP2 decoder
* ADPCM encoder/decoder
* G.711 encoder/decoder
* G.729 encoder/decoder
* iLBC encoder/decoder
* JPEG encoder
* video renderer
* file reader
Compared to previous pre-releases, this version now features a configuration
mechanism, so you can select pretty much every combination of GStreamer
elements you might need, and specify the OpenMAX IL library, component name,
role, and even your desired rank.
Tarballs can be found here:
http://gstreamer.freedesktop.org/src/gst-openmax/
Compared to v0.10.0.5:
Felipe Contreras (33):
Update I420 to PackedPlanar
util: trivial cleanup
util: improve timeout messages
util: cleanup ports when going to loaded
util: increase timeout value
base_videoenc: use 0 as automatic bitrate
videodec: handle empty framerate
build: update 'common' stuff
util: fix compilation warning
base_filter: trivial cleanup
base_filter: more proper printf formatting
base_sink: remove dead assignment
videodec: fallback framerate to 0/1
tests: trivial fix
Move component and library name fields to 'util'
Reorganize core_new()
Reorganize {library,component}-name assigns
Make {component,library}-name read-only
base: remove unused set_property()
base: remove extra code
plugin: reorganize code into get_config_path()
plugin: add support for system-wide config
Add example configuration
plugin: reorganize element_table init
plugin: make element_table const
plugin: add support dependencies
plugin: store element_table in plugin cache
base-filter: improve EOS handling
Fix compilation warnings
Change to gst coding-style
Generate ChangeLog
build: remove patches extra dir
build: add missing files to the dist
Mark Nauwelaerts (1):
base_filter: fix race condition when shutting down
Rob Clark (21):
Fixes for building for 64bit host
Initial support for configuration file
Add default configuration
tests: update to use config file
build: fixes for out-of-tree
Use G_PARAM_STATIC_STRINGS
basefilter: small fix for compile error
Add GSTOMX_BOILERPLATE macros
util: thread safety for _get_type() functions
Construct GOmxPort objects in element constructor
Simplify g_omx_port_setup()
Don't hard-code port indexes
core: call OMX_GetHandle in g_omx_core_new
util: add some debug traces
Add G_OMX_INIT_PARAM utility macro
Add property helpers
Add component-role support
base: add input-buffers/output-buffers properties
Add some debug traces
Add GstOmxBaseAudioDec base class
replace deprecated API
Total contributions for v0.10.1:
1 David Schleef
2 Edward Hervey
370 Felipe Contreras
2 Frederik Vermelen
1 Frederik Vernelen
4 Jan Schmidt
1 Marco Ballesio
9 Mark Nauwelaerts
1 Olivier Crête
16 René Stadler
21 Rob Clark
4 Sebastian Dröge
1 Sriram Murthy
1 Stefan Kost
1 Tim-Philipp Müller
Thanks to all the contributors!
Cheers.
--
Felipe Contreras
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: ogg-support to libsndfile?
On Thu, Oct 14, 2010 at 10:10 PM, Aapo Rantalainen aapo.rantalai...@gmail.com wrote: Hi, currently libsndfile (1.0.20-0maemo1+0m5) doesn't support ogg-files. Package maintainer is :multime...@maemo.org, but address is not in use. Ahh, great, we would have to fix that. I'm CC'ing relevant people manually. I fetch source code with 'apt-get source' and reconfigured it. Configure said that all Flac/Vorbis/Ogg -devs must be installed to use any of them. (they are: libflac-dev libvorbis-dev libogg-dev) I got it configured and compiled and working on N900 with LD_LIBRARY_PATH (and then my application has ogg-support). I have upload-access to extras-devel. So: Is there anybody handling this, or should I? Should I upgrade libsdnfile or make new package: (e.g.) libsdnfile-ogg? Isn't libsndfile part of the 'Maemo 5' package? I guess you would have to create a new package. -- Felipe Contreras ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
[ANN] gst-dsp 0.10.1 released
Hi, Time for another minor release. Mostly cleanups this time, but there's a few fixes that should improve reliability. Also, there's support support for TIDSPBRIDGE_CACHE_LINE_CHECK, so you don't have to disable it anymore. And the new DMA API; begin_dma/end_dma ioctls. Most of these changes have been thoroughly tested in the internal maemo6 branch, which is now public (and rebased on top of this release): https://meego.gitorious.org/maemo-multimedia/gst-dsp/commits/maemo6-patches There's already some stuff on the 'next' branch that I don't want to merge yet. Next step is to cleanup the 'maemo6-patches' branch, and hopefully merge most, if not all the patches :) You can download the tarball from the usual place: http://code.google.com/p/gst-dsp/downloads/list Cheers. Felipe Contreras (20): base: trivial cleanups Add gstdsp_vdec_len_fixup() helper tidsp/*dec: fix all the lengths of decoder output Use new DMA API Activate pinned buffers for missing encoders base: handle possible pinned buffer leaks ipp: fix direction of intermediary buffer ipp: fix direction of more buffers Change dmm_buffer size/len semantics a bit dmm_buffer: store correct size (aligned) Trivial cleanups for 'len' Refactor code into common gstdsp_map_buffer() util: cleanup gstdsp_map_buffer() a bit Use b-dir instead lf b-alignment Remove unused 'alignment' field util: cleanup a bit util: cleanup gstdsp_map_buffer() variables util: improve buffer alignment warning message bridge: add extra safety to be nice with valgrind dmm_buffer: set correct buffer attributes Mark Nauwelaerts (3): tidsp: mp4venc: fix codec_data leak tidsp: mp4venc: ensure availability of codec data venc: indicate in src caps that h264 encoder produces au aligned data -- Felipe Contreras ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
[ANN] gst-dsp 0.10.2 released
Hi, This is basically a brown-paper-bag release since the previous one is totally broken (if you use DSP_API=2, which you should). Also, a few fixes from the Maemo 6 branch, and some fixes for old versions of the JPEG encoder (which is the only one that works from the public release), and a fix for a regression in video call. You can download the tarball from the usual place: http://code.google.com/p/gst-dsp/downloads/list Cheers. Felipe Contreras (6): dmm_buffer: fix for DSP_API=2 util: fix map_buffer() warning message base: fix access to correct dmm_buffer data ipp: fix alignment of strings jpeg: fixes for old socket-node README: add compatibility notes -- Felipe Contreras ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
