Application

Like I said example applications are very simple. With Every library I tried to write playback and record example. If you can use blocking API interface there is blocking example also. In these Examples I use sndfile because API is super easy to use and I could test with WAV. So no troubles big bobbles approach.

Code

I won’t be posting code here it can be found on Github repository. I tried to be super clear as they are examples and added comments as needed but if you don’t get glue fault is all mine.

Portaudio

Supported outputs: Alsa, Oss, Jack, Mac OS X CoreAudio and Many Windows Audio API’s

Why do want to use something else than ALSA? If you need to support other platforms than Linux you get idea of cross platform API for audio. Portaudio is hidden gem of Linux audio libraries. It’s stable as can get. Portaudio has blocking and callback support. It has Float 32-bit Int 32-, 16- and 8-bit input/output. I tries to be very high end in every corner. Also licensing is very liberal.  For a while It’s has seen slowing development  because main developers have something else to do in life.

For me biggest no-no for me was lack of Pulseaudio support (I go so upset that I wrote Pulseaudio  hostApi for Portaudio but that is worth of another blog post). Portaudio supports Windows, Linux and Mac OS X so it’s good choice if you need same quality audio in every platform.

Biggest minus in Portaudio is there ain’t much applications using it. There is some highlights like Mixxx and Audacity. Rest of the list can be found here. Why it’s not more popular I can’t say because it’s easy to use.

Summary: Simple but powerful API for I/O which I can recommend. So go and see examples if it’s for you and documentation from official pages. Next time we get on Pulseaudio.

Pkg-config makes things easy/complicated (choose one)

You can live you whole C developer life with Linux and GCC without ever toughing ‘pkg-config‘. pkg-config is just something that can make you life easier with C. It’s not easy to say in couple of words what it does but closest I can get it provides information how to compile application with specific C-library. In other words if you read blog before there were these bare ‘gcc’ library entries in command-line (-lname stuff).
With more complicated libaries: like GTK+ or SDL you can get yourself wondering what libraries shall I include and what not that I can get my application build. Every self respecting developer wants to keep library dependencies as low as possible. So if you don’t want to wonder anymore you can use ‘pkg-config’.

So what it really does?

Last time I promised SDL_image 1.2 example as it’s little bit more complicated to get build. Actually it’s not that complicated but it’s simple example library and you get nice GUI stuff. First we have to zypper or YaST pkg-config, unzip and SDL_image-devel packages so we can use and link against SDL_image.

zypper install pkg-config SDL_image-devel unzip

after you have managed to install it you can download this blog example application made by Ryan Clark from here: ‘SDL_DisplayBitmap.zip‘. It comes from nice SDL gaming wiki (This tutorial actually) and so if you are interested making games with SDL 1.2 or 2.0 you should pop there. You can download files and unzip it or you can crap same source below and save it as ‘SDL_DisplayBitmap.c’ if you do that remember to have some BMP-image in same directory where you compile named: ‘image.bmp‘. Real nerds goes with unzip. If you do it like me it goes like this.

unzip SDL_DisplayBitmap.zip
cd SDL_DisplayBitmap

Or code for copying

// THIS WORK, INCLUDING THE SOURCE CODE, DOCUMENTATION
// AND RELATED MEDIA AND DATA, IS PLACED INTO THE PUBLIC DOMAIN.
//
// THE ORIGINAL AUTHOR IS RYAN CLARK.
//
// THIS SOFTWARE IS PROVIDED AS-IS WITHOUT WARRANTY
// OF ANY KIND, NOT EVEN THE IMPLIED WARRANTY OF
// MERCHANTABILITY. THE AUTHOR OF THIS SOFTWARE,
// ASSUMES _NO_ RESPONSIBILITY FOR ANY CONSEQUENCE
// RESULTING FROM THE USE, MODIFICATION, OR
// REDISTRIBUTION OF THIS SOFTWARE.

#include <stdlib.h>
#include <SDL/SDL.h&lgt;

int main(int argc, char *argv[])
{
	SDL_Surface *screen;	//This pointer will reference the backbuffer
	SDL_Surface *image;	//This pointer will reference our bitmap sprite
	SDL_Surface *temp;	//This pointer will temporarily reference our bitmap sprite
	SDL_Rect src, dest;	//These rectangles will describe the source and destination regions of our blit
	
	//We must first initialize the SDL video component, and check for success
	if (SDL_Init(SDL_INIT_VIDEO) != 0) {
		printf("Unable to initialize SDL: %s\n", SDL_GetError());
		return 1;
	}
	
	//When this program exits, SDL_Quit must be called
	atexit(SDL_Quit);
	
	//Set the video mode to fullscreen 640x480 with 16bit colour and double-buffering
	screen = SDL_SetVideoMode(640, 480, 16, SDL_DOUBLEBUF | SDL_FULLSCREEN);
	if (screen == NULL) {
		printf("Unable to set video mode: %s\n", SDL_GetError());
		return 1;
	}
	
	//Load the bitmap into a temporary surface, and check for success
	temp = SDL_LoadBMP("image.bmp");
	if (temp == NULL) {
		printf("Unable to load bitmap: %s\n", SDL_GetError());
		return 1;
	}
	
	//Convert the surface to the appropriate display format
	image = SDL_DisplayFormat(temp);
	
	//Release the temporary surface
	SDL_FreeSurface(temp);
	
	//Construct the source rectangle for our blit
	src.x = 0;
	src.y = 0;
	src.w = image->w;	//Use image->w to display the entire width of the image
	src.h = image->h;	//Use image->h to display the entire height of the image
	
	//Construct the destination rectangle for our blit
	dest.x = 100;		//Display the image at the (X,Y) coordinates (100,100)
	dest.y = 100;
	dest.w = image->w;	//Ensure the destination is large enough for the image's entire width/height
	dest.h = image->h;
	
	//Blit the image to the backbuffer
	SDL_BlitSurface(image, &src, screen, &dest);
	
	//Flip the backbuffer to the primary
	SDL_Flip(screen);
	
	//Wait for 2500ms (2.5 seconds) so we can see the image
	SDL_Delay(2500);
	
	//Release the surface
	SDL_FreeSurface(image);
	
	//Return success!
	return 0;
}

I chose this one because it doesn’t have any compiling aid for poor fellow in ZIP. So we can compile it in openSUSE and most of Linux distros like this:

gcc -o SDL_Display Bitmap SDL_DisplayBitmap.c $(pkg-config --libs --cflags SDL_image)
./SDL_Display

You should just see nice spaceship for 2.5 seconds nothing more or you own nice BMP-image.

Do I have to be BASH wizard and what even is BASH?

If you are reading this in openSUSE you probably use BASH (Bourne Again Shell) and that is all I want to say about that. It’s not the topic and you can forget all about it. You don’t have to be wizard of BASH to understand what happens in that sentence above. again we are compiling with ‘gcc‘ file named ‘SDL_DisplayBitmap.c‘ to binary ‘SDL_DisplayBitmap‘. New stuff starts after that. It just tells to BASH ask from ‘pkg-config’ libraries and needed c-flags that comes with SDL_image and attach them here. If you just run you get something like this

pkg-config --libs --cflags SDL_image
-D_GNU_SOURCE=1 -D_REENTRANT -I/usr/include/SDL  -lSDL_image -lSDL -lpthread

So compile string is actual then

gcc -o SDL_Display Bitmap SDL_DisplayBitmap.c -D_GNU_SOURCE=1 -D_REENTRANT -I/usr/include/SDL  -lSDL_image -lSDL -lpthread

But in every distro tends to tune these cflags stuff and every release of ‘SDL_image’ can tune needed libraries. This what you don’t want to know anything about! You don’t want to hassle openSUSE’s or Fedora’s or Ubuntu’s global building flags or include neither library locations by hand. You should just go with the automatic ‘pkg-config’ way. If I can give you one bit of advise other than always use suncream for libraries have ‘pkg-config’-config files and use them. Next we get on ‘make’ and Makefiles. As I’m too lazy to copy’n’paste my ‘gcc‘ strings here.

RPM Package Manager

RPM started as Redhat Package Manager but now it seems to get along with nesting acronym RPM Package Manager (Like GNU is acronym from GNU’s Not Unix) so it doesn’t mean anything special. There is neat how to install RPM in openSUSE-guide and complete Wikipedia article about RPM.

RPM Packages what are they

One can think RPM packages are just like Zip archives or tar-balls with binaries inside them so if you install rpm package it just knows where to copy application information to get this particular application running. Source RPM packages contains ways to build particular application to binary form so end user can make use of it. So simple is that. If it’s not you can read more from openSUSE wiki.
RPM packages are named after format ‘project_name-version-build-arch‘ they can be more difficult when we are dealing with C-libraries example GUI library GTK3 is named after scheme ‘liblibname-libversion-apiversion-version-build‘. Most of the libraries tends to follow that naming scheme.

It just get fuzzier

There is possibility to RPM have subpackages like ‘project_name-subname-version-build-arch‘. There is three should know subpackages that are commonly available (most cases not)

• docs – contains doumentation
• lang – contains localization
• devel – hmm.. this one is little bit trickier

RPM devel packages

Devel package contains files needed develop your/new application with library. If we use

rpm -ql libSDL_image-devel

we see as output what pacakge ‘libSDL_image-devel’ really contains

/usr/include/SDL
/usr/include/SDL/SDL_image.h
/usr/lib64/libSDL_image.so
/usr/lib64/pkgconfig/SDL_image.pc

what are all these files? There is one C-header file at least ‘/usr/include/SDL/SDL_image.h‘. Then there seems to be ‘/usr/lib64/libSDL_image.so‘ symlink to C-library and ‘/usr/lib64/pkgconfig/SDL_image.pc‘ which I’ll get back in future blogs (since it make ones life easier). but what is ‘/usr/lib64/libSDL_image.so’ file? Like said it’s symbolic link to C-library. you can check where it locates with (I assume you are using AMD64/x86_64 openSUSE if you are using something else like i586 use ‘/usr/lib‘ instead of ‘/usr/lib64‘

readlink /usr/lib64/libSDL_image.so

in my case it prints ‘libSDL_image-1.2.so.0.8.4‘.

Shared objects

Microsoft Windows operating system have DLL and Apple Mac OS X have dylib. In linux world they are Shared Objects (.so files). Shared Objects contains all the library functions in binary format. So you can link your applications with it (If you have headers).
GCC Linker (ld) seeks only for ‘.so‘ ending file but in these days most of the Shared Objects follow scheme with number file-ending which is ‘so.API.MINOR.PATCH’. Every API numbering (greater that 0) should be compatible with each other. If new functions are in place older stays API/ABI compatible. It should be like that so ‘so.1.0.0‘ is normally first stable. version ‘so.1.0.1‘ there is bug fixed and ‘so.1.1.0‘ there is new functions declared. It can be like that or project has adapted it’s own system.

How to use these files

I wondered what would be easy enough example with this? I Thought NCurses would do just fine. So copy text from Paul Griffiths Ncurses Hello World example or below to file ‘ncurseshelloworld.c‘:

/*

  CURHELL2.C
  ==========
  (c) Copyright Paul Griffiths 1999
  Email: mail@paulgriffiths.net

  "Hello, world!", ncurses style (now in colour!)

*/

#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>                  /*  for sleep()  */
#include <curses.h>

int main(void) {

    WINDOW * mainwin;

    /*  Initialize ncurses  */

    if ( (mainwin = initscr()) == NULL ) {
	fprintf(stderr, "Error initialising ncurses.\n");
	exit(EXIT_FAILURE);
    }

    start_color();                    /*  Initialize colours  */

    /*  Print message  */

    mvaddstr(6, 32, " Hello, world! ");

    /*  Make sure we are able to do what we want. If
	has_colors() returns FALSE, we cannot use colours.
	COLOR_PAIRS is the maximum number of colour pairs
	we can use. We use 13 in this program, so we check
	to make sure we have enough available.               */

    if ( has_colors() && COLOR_PAIRS >= 13 ) {

	int n = 1;

	/*  Initialize a bunch of colour pairs, where:

	        init_pair(pair number, foreground, background);

	    specifies the pair.                                  */

	init_pair(1,  COLOR_RED,     COLOR_BLACK);
	init_pair(2,  COLOR_GREEN,   COLOR_BLACK);
	init_pair(3,  COLOR_YELLOW,  COLOR_BLACK);
	init_pair(4,  COLOR_BLUE,    COLOR_BLACK);
	init_pair(5,  COLOR_MAGENTA, COLOR_BLACK);
	init_pair(6,  COLOR_CYAN,    COLOR_BLACK);
	init_pair(7,  COLOR_BLUE,    COLOR_WHITE);
	init_pair(8,  COLOR_WHITE,   COLOR_RED);
	init_pair(9,  COLOR_BLACK,   COLOR_GREEN);
	init_pair(10, COLOR_BLUE,    COLOR_YELLOW);
	init_pair(11, COLOR_WHITE,   COLOR_BLUE);
	init_pair(12, COLOR_WHITE,   COLOR_MAGENTA);
	init_pair(13, COLOR_BLACK,   COLOR_CYAN);

	/*  Use them to print of bunch of "Hello, world!"s  */

	while ( n <= 13 ) {
	    color_set(n, NULL);
	    mvaddstr(6 + n, 32, " Hello, world! ");
	    n++;
	}
    }

    /*  Refresh the screen and sleep for a
	while to get the full screen effect  */

    refresh();
    sleep(3);

    /*  Clean up after ourselves  */

    delwin(mainwin);
    endwin();
    refresh();

    return EXIT_SUCCESS;
}

if you just try to compile it with

gcc -o ncurseshelloworld ncurseshelloworld.c
/tmp/cc7CD9vN.o: In function `main':
ncurseshelloworld.c:(.text+0x9): undefined reference to `initscr'
ncurseshelloworld.c:(.text+0x41): undefined reference to `start_color'
ncurseshelloworld.c:(.text+0x48): undefined reference to `stdscr'
ncurseshelloworld.c:(.text+0x5a): undefined reference to `wmove'
ncurseshelloworld.c:(.text+0x66): undefined reference to `stdscr'
ncurseshelloworld.c:(.text+0x78): undefined reference to `waddnstr'
ncurseshelloworld.c:(.text+0x7d): undefined reference to `has_colors'
ncurseshelloworld.c:(.text+0x8b): undefined reference to `COLOR_PAIRS'
ncurseshelloworld.c:(.text+0xaf): undefined reference to `init_pair'
ncurseshelloworld.c:(.text+0xc3): undefined reference to `init_pair'
ncurseshelloworld.c:(.text+0xd7): undefined reference to `init_pair'
ncurseshelloworld.c:(.text+0xeb): undefined reference to `init_pair'
ncurseshelloworld.c:(.text+0xff): undefined reference to `init_pair'
/tmp/cc7CD9vN.o:ncurseshelloworld.c:(.text+0x113): more undefined references to `init_pair' follow
/tmp/cc7CD9vN.o: In function `main':
ncurseshelloworld.c:(.text+0x1ae): undefined reference to `stdscr'
ncurseshelloworld.c:(.text+0x1bd): undefined reference to `wcolor_set'
ncurseshelloworld.c:(.text+0x1ca): undefined reference to `stdscr'
ncurseshelloworld.c:(.text+0x1d9): undefined reference to `wmove'
ncurseshelloworld.c:(.text+0x1e5): undefined reference to `stdscr'
ncurseshelloworld.c:(.text+0x1f7): undefined reference to `waddnstr'
ncurseshelloworld.c:(.text+0x208): undefined reference to `stdscr'
ncurseshelloworld.c:(.text+0x210): undefined reference to `wrefresh'
ncurseshelloworld.c:(.text+0x226): undefined reference to `delwin'
ncurseshelloworld.c:(.text+0x22b): undefined reference to `endwin'
ncurseshelloworld.c:(.text+0x232): undefined reference to `stdscr'
ncurseshelloworld.c:(.text+0x23a): undefined reference to `wrefresh'
collect2: error: ld returned 1 exit status

so what to do? Probably you already have ncurses Development package installed like me but if not first install ncurses devel rpm to you system

zypper install ncurses-devel

then we little bit make our gcc line different:

gcc -o ncurseshelloworld ncurseshelloworld.c -lncurses
./ncurseshelloworld

which ‘-l’ tells you how to use ncurses library when seeking dependencies, After that you see many colors. So that was that and next time we go little bit into SDL_image 1.2 world and learn how to use pkg-config so we know what libraries are needed.

openSUSE and Linux

This is for first timers with openSUSE and GCC not people who know how to use YaST and openSUSE. If you understand openSUSE is Linux-kernel based RPM application distribution in common language openSUSE is Linux operating system you shouldn’t be reading this it’s just waste of your time. If you are still reading you should understand  in deep openSUSE is GNU/Linux based operating system but let’s not get in to that battle.
So One can think Google Android as Google/Linux distribution (It’s also Linux say what you want). They took some tools from normal Linux distributions (there are common tools like GCC) and made rest from the scratch. Is it better or worst you have to choose that from you point of view.
If you come from BSD world for example Mac OS X or FreeBSD and have done some object-C or C (with or without command-line) you don’t have to forget everything just keep your mind open. If you popped just from Microsoft Windows world thought ‘hey I’ll start developing Linux/Android/Cross-platform apps.’ you REALLY have to keep you mind open. Hey I was on Windows decade a go and I’m still alive in Linux world in base Microsoft Windows is POSIX standard compliant like Linux.

Command-line (CLI) and Graphical User Interface (GUI)

All I’ll cover in these blog posts are Command-line examples. If you want to use IDE (Eclipse or such) go a head but I’ll like one to understand how everything really works. You don’t have to dream like those machines about cosmic electric sheeps to understand command-line. You can get there also in Microsoft Windows world and you don’t have to ever get there in Linux if you don’t want to. I’ll just feel little bit safer if you or me understand how to install and compile applications on Linux with command line. I won’t explain to you what is command-line (CLI) and how to get there from GUI (Graphical User Interface) where you probably are reading this from you browser please surf to read the Wikipedia article about it. If you didn’t understand anything what I just said you can blame me and take a break.

Install GCC on openSUSE

I assume that you have installed openSUSE. If not download and install version that have GUI. Do it if you aren’t PRO or have some very very very very good reason (like running it on virtual machine top of Windows then VMWare and Virtualbox are you way to go. Qemu works but you have be again very open minded).
But now you have running openSUSE system with nice KDE/Gnome/XFCE4/LXDE GUI look and If you were hacker you installed all you needed stuff when you installed openSUSE to hard drive. If you like me and didn’t keep reading. In openSUSE you can manage everything with YaST or you can choose the red pill and see the true world.

YaST way

open YaST from application menu. You find it there just look for Logo under settings. Type in root password. Choose ‘Software Management’. Now you can just type ‘gcc’ in ‘Find:‘ box. I’ll just assume you install ‘gcc‘ by clicking box (there comes green right mark) front of it and then push Apply. It’s easy as that. Now you have C-compiler (no C++ or ADA) but no auto-tools or make (or Cmake/Scons).

If you are on CLI you see NCurses based YaST:

pure CLI way without YaST

Go to CLI (Konsole/Gnome-terminal/xterm or in to real CLI). You have to be use ‘root’ or have sudo rights to do any wizardry that is explained here. So I assume you just are root just type

zypper install gcc

and answer ‘y’ after it asks. It does the same as YaST.

That is that for first blog. If everything went right Now you have Gnu C-Compiler available. next time I’ll explain what you can do with it.

Disclaimer: All the stuff here are my own opinions not openSUSE nor Linux community. I'm have used openSUSE or SuSE something over 10 years. I have made professionally many years of development with openSUSE so I know somethings but I don't know everything and I just try to get you along.