In this bug we're moving away from monolithic JNI headers to class-specific
headers so that we don't have to rebuild the world every time we make a change
to a JNI interface.
Differential Revision: https://phabricator.services.mozilla.com/D75375
Pick commits:
9caa5b1 - Only print the filename when logging (#581)
8a4170a - sun: Line continuation character not needed
9696902 - sun: POLL_TIMEOUT is no longer used
159fb99 - sun: Add my email address to the copyright header.
e3b409f - sun: Refactoring: reduce duplication in stream structure.
36aa8b1 - sun: Make the purpose of some variables clearer.
1654468 - sun: Update header inclusion.
38ef439 - sun: Convert floats to LINEAR32 instead of LINEAR16
4dbacae - Remove test for registering device changed callback twice
7f94e27 - Force Rust builds to always rerun cargo.
3e23b25 - Remove TODO, we've done all of those, or they don't apply anymore
Differential Revision: https://phabricator.services.mozilla.com/D70546
--HG--
extra : moz-landing-system : lando
`disable-assert.patch` is nor needed because the change has been merged upstream.
`revert-optimization.patch` is not needed because we want to undo the revert since this import attemptts to fix the crash.
Differential Revision: https://phabricator.services.mozilla.com/D60517
--HG--
extra : moz-landing-system : lando
`disable-assert.patch` is nor needed because the change has been merged upstream.
`revert-optimization.patch` is not needed because we want to undo the revert since this import attemptts to fix the crash.
Differential Revision: https://phabricator.services.mozilla.com/D60517
--HG--
extra : moz-landing-system : lando
The current coreaudio-sys in gecko is a custom 0.2.2 version that used
to avoid the cross-compiling issue mentioned in bug 1569003. The issue
has been fixed in the coreaudio-sys 0.2.3, so we should follow the
upstream instead of using a custom version. As a result, the
coreaudio-sys would generate API bindings based on the MacOS SDK defined
in the build settings.
Differential Revision: https://phabricator.services.mozilla.com/D50531
--HG--
extra : moz-landing-system : lando
Revert the coreaudio-sys dependency changed in bug 1589514, which causes
a trouble when compiling with sccache
Differential Revision: https://phabricator.services.mozilla.com/D50529
--HG--
extra : moz-landing-system : lando
Pick commits:
92e2e11 - minor style fix
5163960 - Update authors
fdb0b1d - Make utf8_from_cfstringref work with empty CFStringRef (#20)
a39bf5f - Remove a fixed issue
Differential Revision: https://phabricator.services.mozilla.com/D50002
--HG--
extra : moz-landing-system : lando
- Don't import the build settings since the settings in gecko is more
complicated.
- Print out the picked commits when running the scripts
Differential Revision: https://phabricator.services.mozilla.com/D40097
--HG--
extra : moz-landing-system : lando
This is the most immediate solution to the problem. This is how
automation ends up building things because it's cross-compiling and
cross-compiling falls back to the code path of that feature, and this
solves the immediate problem of builds not working out of the box.
The more long term fix would be to fix the coreaudio-sys crate to do the
right thing.
Differential Revision: https://phabricator.services.mozilla.com/D39447
--HG--
extra : moz-landing-system : lando
There are three potential data-race operations that may run at the same
time:
1. Data callback and stream reinitialization
2. Data callback and stream destroying
3. Stream reinitialization and stream destroying
The case 1 and 2 won't happen as long as the AudioOutputUnitStop is
called at the beginning of stream reinitialization and stream
destorying. The AudioOutputUnitStop requires to lock a mutex inside
CoreAudio framework that is also used by the data callback. Thus, if
there is a running callback, which holds the mutex inside CoreAudio
framework, when AudioOutputUnitStop is called, then the calling will
block the current thread until the data callback ends since it is
waiting for the mutex. By calling AudioOutputUnitStop at the beginning
of the stream reinitialization and stream destroying, the data race of
case 1 and 2 can be avoided.
On the other hand, the case 3 won't happen since the stream
initialization and destroying is run on the same task queue. The two
tasks on the same serial task queue are impossible to be run at the same
time. The mutex in AudioUnitStream is unnecessary because it's used for
the case 3.
Differential Revision: https://phabricator.services.mozilla.com/D34076
--HG--
extra : moz-landing-system : lando
The custom mutex, OwnedCriticalSection, in the current code comes with
the C-to-Rust translation work of cubeb_audiouniut.cpp. Its design is in
C style and not fitted well in the Rust. Rust has a better mutex design.
In the previous patches, all the data that may be touched on the
different threads are moved into a struct wrapped by a Rust mutex. Those
data will be touched in the critical sections created by the Rust mutex.
Therefore, this custom mutex becomes redundant. It's time to say goodbye
to it.
Differential Revision: https://phabricator.services.mozilla.com/D34074
--HG--
extra : moz-landing-system : lando
The core stream data that will be touched on the different threads when
the stream is created, reinitialized, destoryed should be used in the
critical section. Those core data are initialized in stream-setup and
destroyed in stream-close. The stream-setup and stream-close is run in
the critical section so they won't be executed at the same time.
Currently, the critical section is created by our custom mutex. However,
this custom mutex will be removed in the later mutex replacement.
Instead of running these two operations in the critical sections created
by the custom mutex, they should be moved into a struct wrapped by a
standard Rust mutex. As a result, at the end when the custom mutex is
removed, these two operations are still in the critical sections that
are created by the Rust mutex.
Differential Revision: https://phabricator.services.mozilla.com/D34073
--HG--
extra : moz-landing-system : lando
The listeners will be registered and unregistered on the different threads,
so the listeners should be used in the critical sections. We do create
critical sections by our own mutex. However, this custom mutex will be
gradually replaced by the standard Rust mutex in the following patches.
To replace the custom mutex, we put the listeners to the struct wrapped
by a Rust mutex and register or unregister the listeners in the critical
section created by this struct. At the end when the custom mutex is
removed, those operations are still in the critical sections.
Differential Revision: https://phabricator.services.mozilla.com/D34072
--HG--
extra : moz-landing-system : lando
Calling configure_input requires borrowing AudioUnitStream as a
mutable. Merging configure_input into setup will help to avoid a
potential borrowing-twice issue in the later mutex replacement. There
will be a critical section created by a Rust mutex in the setup, which
will borrow the AudioUnitStream as an immutable.
Differential Revision: https://phabricator.services.mozilla.com/D34071
--HG--
extra : moz-landing-system : lando
Calling configure_output requires borrowing AudioUnitStream as a
mutable. Merging configure_output into setup will help to avoid a
potential borrowing-twice issue in the later mutex replacement. There
will be a critical section created by a Rust mutex in the setup, which
will borrow the AudioUnitStream as an immutable.
Differential Revision: https://phabricator.services.mozilla.com/D34070
--HG--
extra : moz-landing-system : lando
Avoid calling minimum_resampling_input_frames by a borrowing from
AudioUnitStream
Differential Revision: https://phabricator.services.mozilla.com/D34069
--HG--
extra : moz-landing-system : lando
We store global layout info and channels info in the cubeb context.
However, the streams might output to different devices. We should store
the layout info of the output device in the stream directly instead of
in the context. On the other hand, the `channels` value is a duplicate
of `output_desc.mChannelsPerFrame` or `mixer.out_channels` so we don't
need to store this value.
Differential Revision: https://phabricator.services.mozilla.com/D34068
--HG--
extra : moz-landing-system : lando
1. Avoid calling layout_init by wrong AudioUnit value
2. Avoid calling layout getting/setting APIs by borrowing the
AudioUnitStream as a mutable. It will help to avoid the potential
borrowing-twice issues in the later mutex replacement.
Differential Revision: https://phabricator.services.mozilla.com/D34067
--HG--
extra : moz-landing-system : lando
