[linux-audio-dev] LAAGA: updates, laaga-0.2.0 tarball available

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

Subject: [linux-audio-dev] LAAGA: updates, laaga-0.2.0 tarball available
From: Paul Davis (pbd_AT_Op.Net)
Date: Wed Jul 04 2001 - 23:21:34 EEST

http://www.op.net/~pbd/laaga-0.2.0.tar.gz

CHANGES
-------

     * fixed total error in audio mixdown code that
         prevented two instances of the test client from working
     * fixed test client to allow multiple instances of it to work.
     * switched to a new API (see below)
     * added provisional code for the "get selectable fd's" API
     * added provisional code to allow for port monitoring.
     * client thread isn't created until the client is activated
     * minor bug fixes, code cleanups, etc.

API 

---

I have changed things in the API in the interest of future back
compatibility. Rather than supply callbacks when a client is created,
we set them between them client creation and when the client is
activated. This allows us to increase the number of callbacks that can
exist without breaking existing clients. So, a sample client
initialization looks like:

      extern int my_process (nframes_t, void *);	        

      laaga_client_t *client = laaga_client_new ("myname");
      laaga_set_process_callback (client, my_process, some_arg);
      laaga_client_activate (client);
      ...

this would be a client that didn't care about buffer size or sample
rate or any other potential notifications. The callbacks that exist
right now can be set with:

int laaga_set_process_callback (laaga_client_t *, LaagaProcessCallback, void *arg);
int laaga_set_buffer_size_callback (laaga_client_t *, LaagaBufferSizeCallback, void *arg);
int laaga_set_sample_rate_callback (laaga_client_t *, LaagaSampleRateCallback, void *arg);
int laaga_set_port_registration_callback (laaga_client_t *, LaagaPortRegistrationCallback, void *);
int laaga_set_port_monitor_callback (laaga_client_t *, LaagaPortMonitorCallback, void *);

Note that its perfectly legal to have a client with no callbacks
registered.

In addition, I have added provisional code for the "get selectable
fd's" model that would assist existing applications to use
LAAGA. There is a central problem with this design, however, which is
that these fd's may need to change from time to time, and there needs
to be a way to tell the client that this has happened without
requiring that it understands how to do it.

Finally, I have added LaagaPortCanMonitor, a bit flag for ports on physical
interfaces. The comments say:

     /* if LaagaPortCanMonitor is set, then a call to
	laaga_port_request_monitor() makes sense.
	
	Precisely what this means is dependent on the client. A typical
	result of it being called with TRUE as the second argument is
	that data that would be available from an output port (with
	LaagaPortIsPhysical set) is sent to a physical output connector
	as well, so that it can be heard/seen/whatever.
	
	Clients that do not control physical interfaces
	should never create ports with this bit set, and they
	must have provided a port_monitor callback before
	creating any ports with this bit set.
     */

PERFORMANCE
-----------
The engine cycle time without clients and without compile-time
optimization is about 2-3usecs on a 450MHz PII.

Adding the sample ("single channel thru monitor") client increases
this to between 25 and 60usecs (the variation is rather interesting,
and seems to be bistable). Adding a second client that uses the same
code doesn't increase the cycle time by much more than 10usec, and in
some cases, actually decreases it (!). Talk about wierd
memory/cache/code interactions ...

This means that there is every indication that this implementation of
LAAGA can support useful numbers of out-of-process clients.

PROBLEMS
--------

The biggest problem is still that the engine application can exit
without having really exited, which seems to be a problem with
linuxthreads. All threads except for the audio driver thread have
finished, and we return to the command line. However, the audio device
and the various FIFO's are all still in use until the audio driver
thread is killed. This is really ugly.

Plus the same list that I mentioned last time:

   figure out how to have pools of buffers for ports by type
   figure out how to use the same buffer over and over when possible
 
   passing args to drivers and clients?
   getting callbacks and args from dynamically loaded clients?
   how do dynamically loaded clients (un)register ports, activate, etc.
   fix pthread exit problems
   pool based malloc for rt client-local mem allocation

Comments, etc. as usual are welcome.

--p

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

This archive was generated by hypermail 2b28 : Wed Jul 04 2001 - 23:25:46 EEST