List as of 2006-Apr-22, by Michael Dickens, primary author

* Change buffering to use gr_buffer's and necessary related classes.

  Currently uses a circular_buffer I wrote myself (in

  ./src/circular_buffer.h ), which hides the "circular" part from the

  user but otherwise is very fast as well as thread safe.

* A current limitation of this implementation is that the user cannot

  dynamically switch audio devices (input or output) during playback

  and use the new device without stopping the current executing GR and

  restarting the process.  I would like to figure out how to get a

  CoreAudio "listener" for when the default hardware input / output

  device changes (e.g. when switched by the user in the "Sound" system

  preference pane).  The code in ./src/audio-osx-source.cc creates

  listeners for the AudioUnit being used as well as the Hardware

  device, but these for some reason don't do the trick.  It's possible

  that the Python framework doesn't allow for one to do this.

* In both the source and sink, move the code which defines the "Audio

  Stream Basic Description" (ASBD) to a routine to do this as needed

  as start-up as well as in a callback ("listener") if the default

  device changes.

* Tweak the mutex (d_internal) to only where it is truly needed

  (around class-specific variables used across all threads) in order

  to improve performance.  Currently the mutex is used at the

  start and end of any function requiring access to the class variables.

* Change the instantiation arguments ... once those arguments are

  finalized.  Right now gr.audio.source () takes the sample rate (int

  - should be double), the device name (std::string), a boolean for

  blocking or not, and 2 completely non-standard ones for channel

  configuration and the maximum sample count to buffer.  These are

  reasonable for OSX, but might not be for other OSs.  Nothing to do

  right now but wait and discuss.

* Once the previous issue has been resolved, then the current method

  of determining the number of channels needs to be updated.

  Currently the "device_name" for OSX should contain a numeric string

  for the maximum number of channels to use (e.g. "3" means 3

  channels, generally mapped to 2 channel stereo by OSX).  The

  "device_name" is generally input via "-O" in Python scripts, so "-O

  3" would allow for 3 incoming output channels (or fewer).  In theory

  the "channel_config" argument would make more sense for determining

  channel usage.  Example config strings might be "2.1" for stereo w/

  subwoofer (3 channels), "5.1" or "6.1" for various surround w/

  subwoofer (6 & 7 channels, respectively).  OSX can handle all sorts

  of channel configurations, but the names for these will be different

  than those use for OSS or ALMA or Windows ... thus the need for a

  common naming scheme for all cared-about configurations, possibly

  with options for other OS-specific options.