No problem with oSIP. Just do the usual configure && make && make install (the last one as root).

It is best to have the autotool from GNU, and not from Apple, of which autoconf and make are part. To install GNU autotool, please ryou need to install XCode (and the Command Line Tools: XCode -> Preferences -> Download -> Component -> Command Line Tools) and mac ports first (www.macports.org) and then:

Once xcode and macports are installed, open a terminal and install the required build-time tools with:

	$ sudo port install coreutils automake autoconf libtool intltool wget pkgconfig cmake gmake yasm grep doxygen ImageMagick optipng


Install gas-preprosessor.pl  (http://github.com/yuvi/gas-preprocessor/ ) to be copied into /opt/local/bin :

	$ wget --no-check-certificate https://raw.github.com/yuvi/gas-preprocessor/master/gas-preprocessor.pl
	$ sudo mv gas-preprocessor.pl /opt/local/bin/.
	$ sudo chmod +x /opt/local/bin/gas-preprocessor.pl

Link macport libtoolize to glibtoolize 

	$ sudo ln -s /opt/local/bin/glibtoolize /opt/local/bin/libtoolize

Link host's strings to simulator SDK 

	For Xcode prior to 4.3:
	$ sudo ln -s  /usr/bin/strings /Developer/Platforms/iPhoneSimulator.platform/Developer/usr/bin/strings
	For newer XCode:
	$ sudo ln -s  /usr/bin/strings /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/usr/bin/strings

The above lines are from the README of the linphone. Basically you want to install the autotools, but I don't actually know which part of those packages comprise autotools. Some of them are obviously not related to autotools, like the ImageMagick. But just to be safe.... :-))

So, after you install the autotool, the next thing to do is.... trying to configure. It went well for oSIP but not so well for eXosip. configure script for eXosip gave me this:

I got the following error out of sudden:


I swear I did not touch the project settings! It had run well the previous time, but not anymore now! I did a google search and it baffled me to read how many problems could cause this and what the possible solutions are.

I finally nailed it: it was caused by a key in info.plist file which had no value: "Icon file". Below it is a another key: "Icon files" having value of an icons array.

I deleted that Icon file key and the project runs well again. But that problem could have easily been caused by many other factors.... the error message does not help at all!

I never had problem with my Samsung Galaxy W. I connected it to my Ubuntu, I issued adb install on the terminal, and everything went smoothly. Not a single problem.

Then I needed to upgrade to ICS. Samsung Galaxy wouldn't let me upgrade from Gingerbread to ICS. SO I bought LG L5 with ICS.

I connected LG L5 to my Ubuntu, issued adb install and....
adb spat this back to me:

error: insufficient permissions for device 

What went wrong???? I issued adb devices to list the Android devices latched to my Ubuntu. It gave me this:

List of devices attached 
????????????        no permissions 

So my LG is not recognized by Ubuntu. It turns out that you need to create udev file for every device that you are using. So you need to create this file as root: /etc/udev/rules.d/lg-android.rules

The file name is arbitrary, just as long as it ends with .rules extension. Use descriptive file name. In that directory I have lg-android.rules and htc-android.rules files. Add this line to the file:

SUBSYSTEM=="usb", ATTR{idVendor}=="1004", MODE="0777"

The number 0bb4 is manufacturer ID and must be replaced by the manufacturer ID of your device. List follows. And mode is the permission. I set it to 0777 just to make sure every body can execute, write to and read from the device.

Then save the file, and set its permission to be executable and readable by all.

sudo chmod a+rx /etc/udev/rules.d/70-android.rulessd

Then unplug the device, plug it again and issue adb devices again. If your device is not listed, wait a few minutes and issue adb devices again. Should be listed now. Otherwise, I don't know what's gone wrong. :p
One more thing, I need to set my LG L5 connectivity to Media sync (MTP) and enable USB debugging. MTP basically tells my device to act like USB thumb drive.

Following is the result of adb devices issued on my Ubuntu terminal after the above steps are conducted:


List of devices attached
LGOTMSe8ae1617 device


What baffles me is that, why does Samsung get recognized right away, and why does my LG L5 gets recognized automatically on Mac? All the above steps are absolutely unnecessary on Mac...

MANUFACTURER	USB VENDOR ID
Acer	0502
Dell	413c
Foxconn	0489
Garmin-Asus	091E
HTC (Older Phones)	0bb4
HTC (Newer phones)	18d1
Huawei	12d1
Kyocera	0482
LG	1004
Motorola	22b8
Nexus One/S	18d1
Nvidia	0955
Pantech	10A9
Samsung	04e8
Sharp	04dd
Sony Ericsson	0fce
ZTE	19D2

Ref:
http://esausilva.com/2010/05/13/setting-up-adbusb-drivers-for-android-devices-in-linux-ubuntu/

I had a slew of .cxx files inside my directory and I needed to change them to .cpp.

rename 's/.m4b$/.m4a/' *.m4b

First, sudo apt-get install libssl-dev

So I have been fiddling with textures in Cocos2d to find out what image format produces the least memory foot print while not degrading quality in a very visible manner.

So I created an original PNG image, and then converted it to different image formats using Texture Packer. I then created an XCode project to load those images and print out the memory footprint. The XCode project can be fetched from: https://github.com/rumahfirman/texture-format

First, I will list image format from biggest memory foot print to smallest memory foot print (the original image is original.png which is RGBA 8888):



From the above data, it can be seen that file size does not correlate to memory footprint. The smallest file size (which is 4 KB) produces the biggest memory foot print (4096 KB).

It is also obvious that the memory footprint of RGBA 4444 uncompressed PNG is the same as the original image which is RGBA 8888. So RGBA 4444 does not produce memory saving, yet result in quality degradation.

In the above file name, the suffix fs stands for Floyd Steinberg dithering. FSA stands for Floyd Steinberg Alpha dithering.

Dithering basically means to smoothen your image. If your original image contains color gradation, dithering is especially important. Reducing image quality often results in abrupt color changes while in the original image, the color gradually changes. This can be rectified by dithering and FS works well.

If your original image contains alpha channel, FSA also dithers the alpha channel, creating "dotted artifacts", which is especially visible if your image z-order is higher than some other image, i.e there is an image located behind the dithered image. To rectify this, choose FS without A, i.e dither all channels in the image except the alpha channel.

Now let's talk about quality. From best to worse:
Original
RGB 888
RGBA 5551
RGBA 4444
RGB 565

Rule of thumb: if possible, always use RGB 565 for background images.

I set out to understand linphone source code so I decided to learn SIP and tried to built a terminal SIP client. A simple one. No voice, no nothing, just to perform signalling, registering to SIP registrar. That's all.

I started out by learning oSip. I found out later that oSip is lower level, suitable to build lower level service like SIP proxies or registrars, but too cumbersome to build SIP clients. eXosip is more suitable (=easier to use) to build SIP clients since eXosip is a higher layer abstraction over oSip.

Anyway, I'll tell my story with oSip first. So I installed both osip and exosip on my Ubuntu using the default packaged.

sudo apt-get install libexosip2-dev

The above command will automatically install libosip2 since libosip2 is libexosip2's dependency. I adapted wen's tutorial here for Linux (he wrote it for Windows).

From oSip mailing list, Aymeric Moizard (oSip and eXosip author) told me that the packaged lib is outdated. The Ubuntu packaged library is version 3 (while the latest is version 4) and I needed to compile my source files using the switch  -DOSIP_MT . I don't need to use that option if I compile and link my source against the latest (v4) library.

I then decided to download the latest (version 4 as of this writing) oSip and eXosip source from the GNU repo and compiled and installed them on my own. The library is installed inside /usr/local/lib.
When reading the README of eXosip, it told me to install c-ares for asynchronous network operation, so I did that too.

There are quite some things that I learnt during compilation with these libraries.

First of all, I need to run ldconfig as a root right after I install the libraries. I don't really understand why, but otherwise I get numerous errors when compiling and then linking against the newly installed libraries.

Since I have two kinds of osip and exosip (one installed by apt-get, one manually installed), I need to tell the compiler which lib I want to use. I want to compile against the latest, which is manually installed, so this compiler option is necessary:

-L/usr/local/lib

It tells the compiler the location of my library. I also learnt how library naming system works. Library names end with .a extension and starts with the substring lib. For instance, the following is the result of doing ls /usr/local/lib on my system:



If you want to link against a certain library, then strip the lib and the extension from the library name, and prepend -l to it and use it as compiler option. So if you want to link against libeXosip2.a, you put this as compiler option:

-leXosip2

Or you can also use the cumbersome and longer form:

g++ myfile.c  /path/to/my/libeXosip.a

Anyway, the following is my simple Makefile to compile my eXosip source:


exosip: exosip.c
g++ -L/usr/local/lib -Wall -g exosip.c -o exosip -leXosip2 -lcares -DENABLE_TRACE


I needed to remove -DENABLE_TRACE (against what the README recommended) because it gave me errors. I need to find out why.