Do not send extra channels for aggregate devices. #243
Conversation
|
cc @Pehrsons , who I've been working with on this. You may want to do more extensive testing here; I've only tested one combination of input/output devices. |
|
I believe the test failures are the same as on ToT, but I'm not sure if there are any new problems here. |
After f8df86f, we drop the **first** several channels if there are extras (e.g. for aggregate devices). This is often incorrect (because the first device is the input device), and also is inefficient.
mutexlox-signal
force-pushed
the
mutexlox/aggregate
branch
from
85b055a to
5594cc8
Compare
| // Notice: when we are using aggregate device, the input_hw_desc.mChannelsPerFrame is | ||
| // the total of all the input channel count of the devices added in the aggregate device. | ||
| // Due to our aggregate device settings, the data captured by the output device's input | ||
| // channels will be put in the beginning of the raw data given by the input callback. |
There was a problem hiding this comment.
Please keep this comment, but update it to make it accurate: the "our aggregate device settings" refers to the input device coming after the output device, for instance. Rather explain that the input device is set first on the aggregate device, so we only need to request those channels and CoreAudio will drop the rest automatically.
There was a problem hiding this comment.
Sorry for the delay; I lost track of this and have now forgotten all context. Can you please suggest a specific phrasing, and I can update the PR?
We drop the first several channels if there are extras (e.g. for aggregate devices) After f8df86f, this is often incorrect
(because the first device is the input device), and also is inefficient.
So, only request the channels we're planning to use.