diff options
Diffstat (limited to 'gr-audio-osx/TODO')
| -rw-r--r-- | gr-audio-osx/TODO | 51 |
1 files changed, 0 insertions, 51 deletions
diff --git a/gr-audio-osx/TODO b/gr-audio-osx/TODO deleted file mode 100644 index e36ed2b25..000000000 --- a/gr-audio-osx/TODO +++ /dev/null @@ -1,51 +0,0 @@ -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. |