[linux-audio-dev] LAAGA API Proposal

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: [linux-audio-dev] LAAGA API Proposal
From: Richard Guenther (rguenth_AT_tat.physik.uni-tuebingen.de)
Date: Tue Jun 12 2001 - 10:55:15 EEST


Hi!

Just to speak with code, I've (quick and dirty) hacked something
up which is different from Pauls approach. Its in "commented
header" style, it helps if you know GLAME, but I'll try to
elaborate. Note that I dont explicitly show implementation details
(f.i. if using fds or not - I'm less convinced than before that
this would be a good idea, though I'd like to use poll/select).

The following approach (handling Ports and Connections not symmetrically)
simply sidesteppes the issue of on-line re-connecting (the Graph is
always online, there is no thing like "start", all connections get
managed by the destination, the ports by the sources).

Ask, if you have questions.

Richard.

/* Buffers are refcounted like in GLAME, they reside in shared memory
 * like in DataManager.
 * ShmLock is a fast (in the non-contention case) mutex that can
 * reside in shared memory (like the spinlocks in DataManager).
 * All "Handle"s are pointers to the actual data in shared memory.
 *
 * The port / connection notion is not symmetric, i.e. there exist
 * only output ports and connections can be requested from the
 * consumer side only. This simplifies (moves the pity down to the
 * idiot) handling of live connects/breaks.
 *
 * All shared memory / multi-process stuff is extremely sensitive
 * to failures (which could lead to corruption) and leaks. What
 * a pity (you may want to track pid's of object allocating
 * processes and periodically scan them - should work for Ports
 * and Connections but not for Buffers - probably just provide
 * a "refresh" call for explicit garbage collection).
 * More safe operation can be achieved by wrapping all this stuff
 * through a managing daemon - but communication with it would be
 * expensive.
 */

typedef struct {
        PortHandle port;
        ShmLock buffer_list_lock;
        int nr_buffers;
        ShmList buffer_list;
} Connection;

typedef struct {
        const char *name;
        ShmLock connection_list_lock;
        int nr_connections;
        ShmList connection_list;
} Port;

/* Registers a new port (output). */
PortHandle registerPort(const char *port);

/* Marks the port deleted (no further data) and prohibit new connects
 * to it. Actual port deletion is performed after all connections are
 * removed. */
void deletePort(PortHandle port);

/* Queues a buffer to all connected Connections of the port, if there
 * are no connections, the buffer is simply dropped. For each Connection
 * the buffer is refed once, the initial ref is dropped.
 * May return a hint, if the buffer was dropped immediately. */
int queueBuffer(PortHandle port, BufferHandle buffer);

/* Registers the caller as consumer of the port, i.e. establishes a
 * connection. May fail, if the port is unknown/deleted. */
ConnectionHandle connectPort(const char *port);

/* Breaks the connection dropping all pending buffers. */
void breakConnection(ConnectionHandle connection);

/* Gets (blocking) a new buffer from the connection. May return failure,
 * if the port was deleted and no data is available anymore (in which
 * case you still need to break the connection).
 * You may want to have an extra getBuffer() that always gets the most
 * recent buffer (and drops intermediate ones) - useful for noncritical
 * monitoring apps which may need a lot of CPU power (can you say
 * visualization plugin?) - perhaps provide a "connection type" to
 * the connectPort() call. */
BufferHandle getBuffer(ConnectionHandle connection);

/* Additional to the above GLAME-like buffer management functions
 * have to be added:
 */
BufferHandle allocBuffer(int size);
void refBuffer(BufferHandle);
void unrefBuffer(BufferHandle);
BufferHandle make_rw_Buffer(BufferHandle);
BufferHandle try_to_make_rw_Buffer(BufferHandle);


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Tue Jun 12 2001 - 12:10:17 EEST