Subject: Re: [linux-audio-dev] LAAGA - how are we doing ?
From: Karl MacMillan (karlmac_AT_peabody.jhu.edu)
Date: Thu May 03 2001 - 23:06:10 EEST
Some quick questions/comments:
- It might be nice to have access to multiple channels with one call -
i.e. request_channels, write_channels, read_channels, etc.
- Is there a reason not to use size_t instead of guint32? It seems like
it would be nice for these values to be larger on those platforms where
a larger value might be more efficient.
- It is not clear from this whether the plugins are required to be the
equivalent of run adding - that is can they simply write over the buffer
that is filled with read_from_channel call or do they have to add to the
buffer?
The last point seems important to me. My overall question is one of
amplitude normalization - if plugins normalize their output to -1 to 1 and
two plugins write to the same channel then the server would need to scale
the output. Is this what happens in your system now? What happens when a
plugin is removed - is the scaling reduced causing a big jump in volume
for the user? If there is no scaling how is clipping avoided? Otherwise
this looks great.
Karl
On Thu, 3 May 2001, Paul Davis wrote:
> >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
>
_____________________________________________________
| Karl W. MacMillan |
| Computer Music Department |
| Peabody Institute of the Johns Hopkins University |
| karlmac_AT_peabody.jhu.edu |
| www.peabody.jhu.edu/~karlmac |
-----------------------------------------------------
This archive was generated by hypermail 2b28 : Thu May 03 2001 - 23:42:50 EEST