QML port

Asked by Ayrton Araújo on 2013-06-21

This application is really good,
are you guys planning to have a QML interface of this for make it available to Ubuntu Touch?

I could fork the repo and start helping with this.

Question information

Language:
English Edit question
Status:
Solved
For:
Audio Recorder Edit question
Assignee:
No assignee Edit question
Solved by:
moma
Solved:
2013-10-28
Last query:
2013-10-28
Last reply:
2013-10-27
Launchpad Janitor (janitor) said : #1

This question was expired because it remained in the 'Open' state without activity for the last 15 days.

moma (osmoma) said : #2

This is a very good question.
Unfortunately, I have no plans to port audio-recorder to QT/QML. I do not have enough knowledge about QT/QML framework. I merely re-compile current audio-recorder from one Ubuntu (desktop) version to another.

I hope that other people will start developing a modern recorder for Ubuntu-Touch. I know that GStreamer has been ported to Ubuntu-Touch, so it should be easy to make a QT/QML GUI for that.

Best moma (osmoma) said : #3

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 ;-)

Ayrton Araújo (ayrton) said : #4

Thanks moma, that solved my question.

Ayrton Araújo (ayrton) said : #5

I will see what I can do. But help with this port could be interesting :-)

moma (osmoma) said : #6

Olá,
Muito bom Ayrton.

The initial "novo gravador de áudio" does not need to have MPRIS2 or Skype-interfaces. It does not need to have a complex Timer. All these components can be added later on. The most important parts are 1), 2), 4) and 5). But it might be a good thing to separate the GUI and the recorder module.

Recording pr. application (instead of per device).
OSX has a recorder that can tape all sound from an application. Current version of A.r records from one or more devices, instead of from an application (or per application).

Our recorder has no idea of what audio-devices an application has opened. So, for example we cannot say; "Record sound from RhythmBox" or "Record all audio from Skype". Unfortunately, this is not yet possible in our recorder! We can only record per. device ID.

And this can be a problem.
Lately, I received couple of emails about Skype. Our recorder tapes both the audio-card's output and web-camera's sound input. Unfortunately, the webcam`s microphone causes a looping ECHO via loudspeakers and this disturbs the recording.

I believe and hope that Gstreamer 1.0 can give a list of active applications (and what devices they have opened). This would enable per application recording. It would be nice if the recorder could connect to the audio-streams that an application has opened. This is just a wish.

Good luck with your ideas about QT/QML port.
We need your work ;-)
Obrigado Ayrton.

Osmo (Moma) Antero
Palmela / Portugal

moma (osmoma) said : #7