| Age | Commit message (Collapse) | Author |
|---|
|
state_callback.
|
|
|
|
called.
|
|
Format all the code under `include` and `src` except those files under
`src/speex` with style setting in `.clang-format` file by the following
script:
```sh
FILE_LIST="$(find "include" "src" -not -path "src/speex/*" | grep -E ".*(\.cpp|\.c|\.h|\.hpp|\.hh)$")"
echo "Files found to format:\n---\n$FILE_LIST\n---"
clang-format --verbose -i $FILE_LIST
```
|
|
|
|
|
|
|
|
|
|
This solves the deadlock mentioned in BMO 1572273 comment 6. It's very
likely to have a deadlock when the output callback tries to stop the
input AudioUnit when the input device is unplugged while the output
device is unchanged during a WebRTC call.
One of the thread forming the deadlock is internal so we don't have any
control on it. The only way to free the deadlock is to prevent the
output callback to require the CAMutex tied to the input AudioUnit.
With the change, the input AudioUnit will be stopped in its own callback
so the deadlock won't be formed.
|
|
computation.
This is right after the callback, that has the number of channels the
user requested, and can be different from the number of channels of the
device.
|
|
A multiplication by the size of the type was missing.
|
|
This is best done by the host application, and had very little
implementation anyways.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The dispatch queue created within the cubeb context should be released when it's no longer needed, or the allocated memory of the queue will be leaked if it's not deallocated. The memory of the dispatch queue is allocated when the cubeb context is created, so the memory should be deallocated when the cubeb context is destroyed.
|
|
Fixes #482
|
|
|
|
|
|
|
|
1498242) (#465)
* audiounit: separate input output callbacks for collection changes (BMO 1498242)
* Apply review comments so far
* More review comments
|
|
* audiounit: report removed devices correctly (BMO 1491152)
* Update review comments
|
|
|
|
|
|
|
|
output is present. Otherwise just feed silence.
|
|
input_linear_buffer size is always directly matching how many frames are available for input
|
|
instead.
|
|
|
|
This avoid accumulating rounding errors each time some silence is inserted
|
|
Contrary to earlier assumed, even in duplex audio the sampling rate of the input device doesn't always match the rate of the output device.
|
|
It is possible that the callback caused a reinit task to be queued while at the same time audiounit_stream_destroy got called.
We need to abort early as otherwise both stm->input_unit and stm->output_unit would have been cleared.
|
|
|
|
|
|
re-creating it
Otherwise we would be out of sync triggering the assert. This resolves the issue mentioned in https://bugzilla.mozilla.org/show_bug.cgi?id=1489052#c10
|
|
After calling the resampler, we would reduce the number of frames in the input buffer correctly by the number of frames used, but would always fully clear the input buffer after.
Resulting with a input_buffer and its frame counters to be potentially out of sync
|
|
In duplex mode, audiounit_input_callback and audiounit_output_callback are always called on the same thread. input_linear_buffer is only ever accessed serially.
Additionally, the use of atomic variables was incorrect as they should only ever be modified when input_linear_buffer was modified.
So we remove the lock and the related atomics.
remove input_buffer_frames member as its value is always latency_frames
|
|
|
|
kAudioUnitErr_CannotDoInCurrentContext.
This can occur using BT headset which change from A2DP profile to HFP (Hands-free Profle) or HSP (Headset Profile) when opening the microphone.
|
|
Under some circumstances, like the input couldn't be rendered we could have fed less data than the resampler expected.
|
|
property_listener (#451)
* Use DEVICES_PROPERTY_ADDRESS in audiounit_get_devices_of_type
* Use exactly same AudioObjectPropertyAddress in audiounit_add_device_listener() and audiounit_remove_device_listener()
We have duplicated AudioObjectPropertyAddress variables in audiounit_add_device_listener() and audiounit_remove_device_listener(). This two functions use same values to add and remove listeners on same system events. Therefore, we should use the exactly same value for both instead of creating same values in two functions, in case the local variables are changed carelessly.
* Use global AudioObjectPropertyAddress settings for both audiounit_add_listener() and audiounit_remove_listener()
* audiounit_get_default_device_datasource
* Simplify audiounit_add/remove_listener() by introducing property_listener
audiounit_add_listener() and audiounit_remove_listener() should use exactly same variable to register and unregister event listener. Originally, these two functions are set by different local variables with same values: audiounit_add_listener(X, Y, Z, ...) and audiounit_remove_listener(X', Y', Z', ...), where X = X', Y = Y',...etc. There are too many function parameters so it's not easy to check if we have same parameters for audiounit_add_listener() and audiounit_remove_listener().
property_listener is introduced to simplify the parameter issues by using audiounit_add/remove_listener(property_listener L). A property_listener object L is created to register a event listener, and then be used to unregister the listener later. It'll be safer if audiounit_add_listener() and audiounit_remove_listener() use the exactly same object as their parameters. In addition, The readability is better since there is a "listener" be added/removed when we call audiounit_add/remove_listener().
* Use DEFAULT_INPUT/OUTPUT_DEVICE_PROPERTY_ADDRESS in audiounit_get_default_device_id()
* Make property_listener pointer be const
* Remove stm->XXX_listners if it's not nullptr no matter the input/output_unit exists or not.
stm->XXX_listener will be set based on existence of the input/output_unit. Therefore, if it's not nullptr, the input/output_unit must exist. Removing listeners or not only depends on existeneces of the listeners themselves.
|
|
* Add a test for cubeb_stream_get_current_device() and cubeb_stream_device_destroy()
* Reduce duplicates in audiounit_stream_get_current_device()
The audiounit_stream_get_current_device() will set the default device's name for input and output by the following steps:
1. Get default device's data, whose type is uint32
2. Convert the uint32 data into a string
3. Set the string into cubeb_device's name
Hence we can split it into functions to do the above steps:
i. audiounit_get_default_device_data(...)
Do the step 1
ii. allocate_and_convert_uint32_into_string(...)
Do the step 2 and 3. It will allocate memory for a string and put the converted string right there. (If we don't allocate and then set the values into the memory at the same time, we need to find a way to check the memory's boundary.)
They are called by a function named audiounit_get_default_device_name(...), with cubeb_device_type parameter to set the device name of input or output. And audiounit_get_default_device_name(...) will be used in audiounit_stream_get_current_device().
* Replace allocate_and_convert_uint32_into_string(...) by convert_uint32_into_string(...)
1. Rename allocate_and_convert_uint32_into_string(...) to convert_uint32_into_string(...)
2. Return a unique_ptr<char[]> from convert_uint32_into_string(...) pointing to an allocated memory
* Hard-coding the convertion from uint32 into string
This change is to make sure the conversion only ever needs to handle 4 bytes.
* Add more information to log when calling audiounit_stream_get_current_device(...)
We add a log with error message when we cannot get datasource data from the devices. However, we don't return an error code in this case since it's quite common when we try getting that data from USB devices. We will convert the datasource data into a string. If there is no data, the string is empty. Instead of logging when we cannot get the datasource data, it's better to log that the converted name is empty. It'll give more meaning (Users are more likely confused about what the empty datasource means.).
* Rename audiounit_get_default_device_data() to audiounit_get_default_device_datasource()
We should use an explicit name for this function since the same device will return different datasources. For example, the default input device on macbook pro will return "imic" if it uses the default internal microphone or "emic" when it uses an external microphone plugged in audio jack.
TODO: it's better to rename audiounit_stream_get_current_device to audiounit_stream_get_current_device_source. The reason is same as above.
|
|
available
This allows to output what people typically expect when playing mono audio: sound coming from both left and right channels.
To force this conversion for happening on mac, we tag that layout are unknown as soon as a channel type is unknown
|
|
The method kAudioUnitProperty_AudioChannelLayout used to retrieve the channel layout wasn't introduced until 10.12. So we use kAudioDevicePropertyPreferredChannelLayout instead should it fails.
Fixes #448
|
|
(#445)
* audiounit: new method on failed stream init to avoid deadlock (BMO 1470113).
* use an internal_destroy method to avoid duplication
|
|
|
|
|
