Subject: Re: [linux-audio-dev] LAAGA API Proposal
From: Kardamone (kardamone2_AT_yahoo.com)
Date: Tue Jun 12 2001 - 14:33:07 EEST
Hi,
I don't know exactly if this is the place and time but, I thought i could dare a
line : is it an option to consider that there would be some "parameter ports"
available on LAAGA ? I mean a way to drive a simple value on an external
process or all focus will be attributed to audio data and let some midi do the
parameter stuff?
I'm a complete beginner in this field but width some experience in audio
production.. The main motivation of my question is : would it be possible to
thik about some kind of global modular ui for driving various audio processing
units and sequence / automate parameter changes etc...
Kard.
----- Original Message -----
From: "Richard Guenther" <rguenth_AT_tat.physik.uni-tuebingen.de>
To: <linux-audio-dev_AT_music.columbia.edu>
Sent: Tuesday, June 12, 2001 9:55 AM
Subject: [linux-audio-dev] LAAGA API Proposal
> 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);
>
>
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
This archive was generated by hypermail 2b28 : Tue Jun 12 2001 - 15:38:05 EEST