Subject: Re: [linux-audio-dev] LAAGA - how are we doing ?
From: Paul Davis (pbd_AT_Op.Net)
Date: Thu May 03 2001 - 19:50:23 EEST
>Here's a draft of the callbacks. I've tried to stay close to Paul's AES
>interfaces.
I think it needs to be a bit more full featured than that. here are
the features i think the server should provide:
* ways to move audio data to/from a channel
* ways to find out certain pieces of info about the audio interface
* ways to get input monitoring turned on and off
* ways to get an input meter level (perhaps of various kinds)
Here's a version of the full AES thing, slightly modified to use with
Kai's suggestions. This is in C++, so for C imagine that all the
function names are wrapped in (*function_name).
API used for plugin clients:
----------------------------------------------------------------------
/* how to request/release access to a channel */
int request_channel (int direction, channel_id_t channel);
void release_channel (int direction, channel_id_t channel);
/* how to move data to and from a channel. if the relevant
request_channel() call has not been made, then the results
of these two calls are undefined.
*/
void read_from_channel (channel_id_t channel,
Sample *buf,
guint32 nsamples, guint32 offset);
void write_to_channel (channel_id_t channel, Sample *buf,
guint32 nsamples, guint32 offset, gain_t gain);
/* how to insert a plugin into the run list */
int attach (AudioEnginePlugin *);
/* information about the server */
guint32 physical_input_channels ();
guint32 physical_output_channels ();
guint32 all_output_channels ();
guint32 bus_channels ();
guint32 network_channels ();
guint32 frame_rate ();
guint32 frames_per_cycle();
guint32 capture_frame_latency();
guint32 playback_frame_latency();
/* current time */
void smpte_time (SMPTE_Time &t);
guint32 frame_time ();
----------------------------------------------------------------------
In addition, although its not part of LAAGA, the server probably needs
to provide this functionality for a UI.
API used by a UI for the server:
----------------------------------------------------------------------
void set_smpte_source (SMPTE_TimeSource *);
void set_frame_source (Frame_TimeSource *);
void run();
void stop();
void stop_audio();
void start_audio();
void restart();
int set_frame_rate (guint32 rate); /* !!!!may not work!!!! */
int set_frames_per_cycle (guint32 fpc);
/* Getting the engine to monitor channels (copy the input
to the matching output)
*/
void request_monitor_input (channel_id_t chn, bool yn);
bool monitoring_input (channel_id_t chn);
/* asking the server to "bypass" output, and have all
channels monitoring input. i use this feature in ardour/aes
quite a lot when i'm running it.
*/
void request_all_monitor_input (bool yn);
bool all_monitoring_input ();
/* can the audio h/w do input monitoring itself, and ways
to check on and modify whether it is.
the results of get/set are undefined in has_hw_monitoring()
is false.
*/
bool has_hw_monitoring();
void set_hw_monitoring (bool yn);
bool get_hw_monitoring();
/* sample clock sync stuff */
bool has_clock_sync_reporting();
bool clock_sync_status (channel_id_t chn);
/* Getting the engine to provide input meter levels */
void request_meter_input (channel_id_t chn, bool yn);
/* reset meters */
void reset_overs (channel_id_t chn);
void reset_all_overs ();
void reset_peak (channel_id_t chn);
void reset_all_peaks ();
/* get meter values */
float peak_output_power (guint32 chn);
float peak_input_power (guint32 chn);
guint32 over_count (channel_id_t chn, OverType ot);
/* sample clock stuff */
SampleClockMode get_sample_clock_mode ();
/* this must be used with care. it could
mess up a working h/w configuration if used
incorrectly.
*/
int set_sample_clock_mode (SampleClockMode mode);
----------------------------------------------------------------------
Let me know what you think.
>The sampling rate issue is always a bit tricky. Hmm, maybe we should just
>pass the engine sampling rate in the client->init() call and plugins would
>be required to use that.
Yes, absolutely. the plugins should check the rate during their init
function, and if they can't use it, its their problem. On pro-audio
h/w, its possible that even the server can't change the rate (at least
not without annoying the user).
>> - Security. Given that we're presumably loading plugins for any
>> external app that asks us to, we need to have fairly low privileges.
>> How does this mesh with some of the high privileges we'll probably
>> need ? Do we need to somehow vet the external apps that are making
>> the requests ?
>
>This is an important thing to keep in mind, but at the moment I'd like to
>concentrate on the basic functionality, without worrying about security.
Tommi appears to have addressed this for us, right on time!
--p
This archive was generated by hypermail 2b28 : Thu May 03 2001 - 20:40:38 EEST