Let's use the common string representation for item category
names, defined in the shared header, instead of defining
them in every file.
Change-Id: Ie0c449d77fa383cad27f67b8ce902bd071342dbb
In order to give advanced control over a processing queue,
it would be better to have the checking function separated from
the osmo_gapk_pq_prepare(). Moreover, this change introduces an
additional 'strict' checking mode that requires a queue to have
a source item first and a sink item in the last position.
This change adds two meta-information fields to the processing
queue item structure. Both of them will be used for more
detailed logging and for the human-readable processing
queue description.
There are currently three types of prcessing queue items:
- source (file, alsa, rtp)
- proc (format, codec)
- sink (file, alsa, rtp)
Let's assign corresponding type for each item.
This would facilitate logging and the queue checking.
Since this change, every processing queue may optionally have
an associated human-readable name. If name is not required,
NULL should be passed to the osmo_gapk_pq_create().
In some cases it's required to wait for some queue items
to finish processing. For example, the ALSA sink writes the
audio samples to the buffer in non-blocking mode, so as soon
as all of them will be written, a program may finish execution,
causing the playback abort.
To prevent that, this change extends the library's API, allowing
each queue item to have a processing state callback that returns
a positive integer if processing is not finished yet,
and 0 otherwise.
The usage of linuxlist is more flexible than having a limited
array of pointers. This approach allows to have as much items
in a processing queue as required.
To avoid a naming conflict between libosmogapk and other projects
during linkage, all the exposed symbols should have an unique
prefix. Let's use 'osmo_gapk' for that.
The most compilers today do support the '#pragma once', which is
designed to cause the current source file to be included only once
in a single compilation. One has several advantages, including:
less code, avoidance of name clashes, and sometimes improvement
in compilation speed.
See: https://en.wikipedia.org/wiki/Pragma_once for details.
To be able to use the library, external applications need to know,
which symbols are exposed. This information is provided by header
files, which are being installed to a system's ${includedir}
since this change.
Vadim Yanitskiy