1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
|
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.
|
