git.gag.com Git - debian/gnuradio/blob - gr-audio-osx/TODO

   1 List as of 2006-Apr-22, by Michael Dickens, primary author
   2
   3 * Change buffering to use gr_buffer's and necessary related classes.
   4   Currently uses a circular_buffer I wrote myself (in
   5   ./src/circular_buffer.h ), which hides the "circular" part from the
   6   user but otherwise is very fast as well as thread safe.
   7
   8 * A current limitation of this implementation is that the user cannot
   9   dynamically switch audio devices (input or output) during playback
  10   and use the new device without stopping the current executing GR and
  11   restarting the process.  I would like to figure out how to get a
  12   CoreAudio "listener" for when the default hardware input / output
  13   device changes (e.g. when switched by the user in the "Sound" system
  14   preference pane).  The code in ./src/audio-osx-source.cc creates
  15   listeners for the AudioUnit being used as well as the Hardware
  16   device, but these for some reason don't do the trick.  It's possible
  17   that the Python framework doesn't allow for one to do this.
  18
  19 * In both the source and sink, move the code which defines the "Audio
  20   Stream Basic Description" (ASBD) to a routine to do this as needed
  21   as start-up as well as in a callback ("listener") if the default
  22   device changes.
  23
  24 * Tweak the mutex (d_internal) to only where it is truly needed
  25   (around class-specific variables used across all threads) in order
  26   to improve performance.  Currently the mutex is used at the
  27   start and end of any function requiring access to the class variables.
  28
  29 * Change the instantiation arguments ... once those arguments are
  30   finalized.  Right now gr.audio.source () takes the sample rate (int
  31   - should be double), the device name (std::string), a boolean for
  32   blocking or not, and 2 completely non-standard ones for channel
  33   configuration and the maximum sample count to buffer.  These are
  34   reasonable for OSX, but might not be for other OSs.  Nothing to do
  35   right now but wait and discuss.
  36
  37 * Once the previous issue has been resolved, then the current method
  38   of determining the number of channels needs to be updated.
  39   Currently the "device_name" for OSX should contain a numeric string
  40   for the maximum number of channels to use (e.g. "3" means 3
  41   channels, generally mapped to 2 channel stereo by OSX).  The
  42   "device_name" is generally input via "-O" in Python scripts, so "-O
  43   3" would allow for 3 incoming output channels (or fewer).  In theory
  44   the "channel_config" argument would make more sense for determining
  45   channel usage.  Example config strings might be "2.1" for stereo w/
  46   subwoofer (3 channels), "5.1" or "6.1" for various surround w/
  47   subwoofer (6 & 7 channels, respectively).  OSX can handle all sorts
  48   of channel configurations, but the names for these will be different
  49   than those use for OSS or ALMA or Windows ... thus the need for a
  50   common naming scheme for all cared-about configurations, possibly
  51   with options for other OS-specific options.