QML port

As said, porting this audio-recorder to QT/QML and Ubuntu-Touch is a very actual question and task.
I hope you could start and lead this type of project.

I would happily help with the GStreamer-part and testing. It's GStreamer that does the actual heavy work, the recording.

Please read the following explanation.
Our GTK3-based recorder has these modules:

1) The GUI:
---------------
The GUI is defined in src/main.c. Main.c parses also all command line arguments and sets the variables.
Please study: http://bazaar.launchpad.net/~osmoma/audio-recorder/trunk/view/head:/src/main.c

In the QT/QML port, the GUI should be separate from the recorder itself. Many people have asked for a pure command line recorder that also handles command-line arguments and timer actions. This is not possible in the current version of audio-recorder.

2) Getting a list of audio Devices, Media players and Skype:
--------------------------------------------------------------------------------
src/audio-sources.c.
This module reads a list of connected audio-devices from the PuleAudio. The following "pactl" command returns exactly the same device list.

$ pactl list | grep -A2 'Source #'

The list is shown in the program`s "Source:" listbox in the main window.

Please study:
http://bazaar.launchpad.net/~osmoma/audio-recorder/trunk/view/head:/src/audio-sources.c
and
http://bazaar.launchpad.net/~osmoma/audio-recorder/trunk/view/head:/src/pulseaudio.c

All dependencies to libpulse (-lpulse) should be removed from the program. Now the program calls PulseAudio to get the device list. This is NOT anymore necessary. GStreamer can provide the list as well. Please read the comments at the top of src/audio-sources.c. Also pulseaudio.[ch] modules should be removed from the project. Use GStreamer (at the code level) for all tasks.
See: https://answers.launchpad.net/audio-recorder/+question/234124
--
The src/audio-sources.c adds also active Media Players and Skype(if installed) to the list.

Our Audio-Recorder implements the MPRIS2-interface which allows Media Players to send commands to the recorder via DBus. Audio-recorder simply reacts to the same MPRIS2-commands as the desktop`s sound-indicator on the toolbar. There is no magick involved.

Please see:
http://bazaar.launchpad.net/~osmoma/audio-recorder/trunk/view/head:/src/dbus-mpris2.c
and
http://bazaar.launchpad.net/~osmoma/audio-recorder/trunk/view/head:/src/dbus-player.c

Now-a-days most players implement the MPRIS2 (Media Player Interface) well. Audio-recorder tend to work well with them.

Skype does not implement the MPRIS2. It has its own set of DBus-imperatives.
See:
http://bazaar.launchpad.net/~osmoma/audio-recorder/trunk/view/head:/src/dbus-skype.c

Notice one important thing.
The src/dbus-server.c has nothing to do with MPRIS2.
dbus-server.c creates a small server for audio-recorder so other programs can send it commands like "start", "pause" and "quit". Normally audio-recorder simply sends commands to ITSELF (to an existing instance of the same program). Ok?
For example:

$ audio-recorder --command=stop
Sends a "stop" command to an existing instance of audio-recorder. It starts a new instance if needed. This is handled by src/main.c and src/dbus-server.c.

For more info, see:
$ audio-recorder --help

3) Recording manager:
--------------------------------
Rec-manager receives recording commands from the GUI, various Threads, Media players and from Skype.

Rec-manager is a message queue that sits and waits for commands, then dispatches them to the GUI or recorder. Originally, I needed a message queue because the program could receive messages form various sources, AND for example manipulating the GUI-elements from a thread could easily LOCK/FREEZE the program. The message queue solved this problem. In the earlier versions of GTK+ we had to call gdk_threads_enter() and gdk_threads_leave() to avoid locking the GTK`s main-loop. Today it is not recommened/or even possible to manipulate the GUI from a thread.

See: http://bazaar.launchpad.net/~osmoma/audio-recorder/trunk/view/head:/src/rec-manager.c

4) The recorder module:
---------------------------------
The gst-recorder.c module. This creates a unique filename and calls gst-pipeline.c with proper arguments and device IDs to create a GStreamer-pipeline for recording. Please study:
http://bazaar.launcpad.net/~osmoma/audio-recorder/trunk/view/head:/src/gst-recorder.c

5) Createing GStreamer-pipelines:
-----------------------------------------------
Gstreamer is absolutely everything here.

Gst-pipeline.c creates GStreamer-pipelines for both recording and the timer/VAD module. It can make both simple recording-pipeline that tapes from ONE single device, or more complex pipelines (by GstAdder element) that takes TWO or more input devices for recording. The simpler pipeline (that records from 1 device only) saves resources; AFAIK ;-).

See: http://bazaar.launchpad.net/~osmoma/audio-recorder/trunk/view/head:/src/gst-pipeline.c

6 Timer and its parser:
-------------------------------
The timer is defined in src/timer.c.
The timer actions are parsed by src/timer-parser.c. This returns a list of TimerRec structures.

Please RTF manual of valid timer-actions in data/timer-syntax.html.

And study: http://bazaar.launchpad.net/~osmoma/audio-recorder/trunk/view/head:/src/timer.c
and
http://bazaar.launchpad.net/~osmoma/audio-recorder/trunk/view/head:/src/timer-parser.c

Notice: The timer module creates its GStreamer-pipeline to detect any activity of sound. This is called VAD (Voice Activity Detector) pipeline. VAD-pipeline records to a "fakesink" /dev/null element. Its main task is to monitor the signal-level (audio level) and report thnis data to timer.c. This way the Timer can start recording eg. when there is audio/sound/whispering on the line.

Here are some Timer-actions where signal-data from the VAD-pipeline is vital.
"start if voice 30%"
"stop if voice 4 seconds 20%"
"stop if silence 5s".
"pause if silence".

You can easily output the signal (decibel) levels from the VAD module. Run
$ audio-recorder --debug-signal
or
$ audio-recorder -d
Active also Timer in the GUI.

So you will often see TWO (2) Gstreamer-pipelines in the "pavucontrol" window. The first one is the real recorder. It records the sound from the selected device(s). The other pipeline is a VAD (Voice Activity Detector) pipeline that MONITORS the signal/audio-level for the Timer module. It feeds the Timer with level (decibel) data.

$ pavucontrol

The VAD (Voice Activity Detector) is coded in:
http://bazaar.launchpad.net/~osmoma/audio-recorder/trunk/view/head:/src/gst-vad.c

It is a very simple module that calls gst-pipeline.c to create a GStreamer-pipeline for VAD. It then feeds signal (dB) values to the timer.c, and timer.c then (if it is active) does its decisions.

Good luck with the QT/QML-port of A.r!

The end.
(please notice. English is far from my native language. The list is; Finnish, Norwegian, English and Portuguese ;-)