Update WebRTC code to webrtc.org stable branch 3.43

RESOLVED FIXED in mozilla28

Status

()

defect
RESOLVED FIXED
6 years ago
3 years ago

People

(Reporter: jesup, Assigned: glandium)

Tracking

(Blocks 1 bug)

unspecified
mozilla28
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(6 attachments, 2 obsolete attachments)

3.43 is being used in Chrome 31, to be released soon.

We'll keep the new AEC code on top of it
Assignee

Updated

6 years ago
Assignee: rjesup → mh+mozilla
Status: NEW → ASSIGNED
Assignee

Updated

6 years ago
Attachment #823780 - Flags: review?(nfroyd)
Assignee

Updated

6 years ago
Attachment #823780 - Attachment is obsolete: true
Attachment #823787 - Flags: review?(nfroyd) → review+
Depends on: 933189
Assignee

Updated

6 years ago
Whiteboard: [leave open]
Assignee

Updated

6 years ago
Attachment #823787 - Flags: checkin+
Comment on attachment 827769 [details] [diff] [review]
Add a non-ARM MemoryBarrier function. r=

Why not just use __sync_synchronize() all the time?  Less ugly and the compiler will basically do the same thing (or perhaps it'll be hidden in the runtime somewhere) as your casting hack.
Comment on attachment 827769 [details] [diff] [review]
Add a non-ARM MemoryBarrier function. r=

Note: this patch is used for opensles drivers, which means android and gonk only.
Attachment #827769 - Flags: review?(mh+mozilla)
Attachment #827770 - Flags: review?(blassey.bugs)
Attachment #827781 - Flags: review+
Attachment #827782 - Flags: review?(blassey.bugs)
Attachment #827783 - Flags: review?(blassey.bugs)
Tested with our internal tests, apprtc, gupshup, and some others.  (Can't test with talky.io because of bug 934378)

Let's get it in before bitrot ensues!
Assignee

Comment 15

6 years ago
Comment on attachment 827769 [details] [diff] [review]
Add a non-ARM MemoryBarrier function. r=

Review of attachment 827769 [details] [diff] [review]:
-----------------------------------------------------------------

::: media/webrtc/trunk/webrtc/modules/audio_device/android/single_rw_fifo.cc
@@ +25,5 @@
>    // barrier.
>    typedef void (*KernelMemoryBarrierFunc)();
>    ((KernelMemoryBarrierFunc)0xffff0fa0)();
> +#else
> +  __sync_synchronize();

I agree with Nathan, you can just use __sync_synchronize() everywhere.
Attachment #827769 - Flags: review?(mh+mozilla) → feedback+
Attachment #827769 - Attachment is obsolete: true
Comment on attachment 827845 [details] [diff] [review]
Add a non-ARM MemoryBarrier function. r=

Per IRC
Attachment #827845 - Flags: review?(mh+mozilla)
Assignee

Updated

6 years ago
Attachment #827845 - Flags: review?(mh+mozilla) → review+
Comment on attachment 827770 [details] [diff] [review]
Don't free the global, shared Context ref. r=

Review of attachment 827770 [details] [diff] [review]:
-----------------------------------------------------------------

I think I already r+'d this
Attachment #827770 - Flags: review?(blassey.bugs) → review+
Comment on attachment 827782 [details] [diff] [review]
JB reflect for low-latency params r=

Review of attachment 827782 [details] [diff] [review]:
-----------------------------------------------------------------

I wrote this patch, so I probably shouldn't review it
Attachment #827782 - Flags: review?(blassey.bugs) → review?(mark.finkle)
Comment on attachment 827782 [details] [diff] [review]
JB reflect for low-latency params r=

Transition to reflection looks like it covers the bases
Attachment #827782 - Flags: review?(mark.finkle) → review+
Comment on attachment 827783 [details] [diff] [review]
Use the non-main-thread FindClass implementation r=

Review of attachment 827783 [details] [diff] [review]:
-----------------------------------------------------------------

::: media/webrtc/trunk/webrtc/modules/audio_device/android/audio_manager_jni.cc
@@ +85,4 @@
>    // Create a global reference such that the class object is not recycled by
>    // the garbage collector.
> +  g_audio_manager_class_ = jsjni_GetGlobalClassRef(
> +    "org/webrtc/voiceengine/AudioManagerAndroid");

What thread is this being run on? It will dispatch a runnable synchronously to the main thread, which means it will block waiting for the main thread. Is that ok?
Comment on attachment 827783 [details] [diff] [review]
Use the non-main-thread FindClass implementation r=

Review of attachment 827783 [details] [diff] [review]:
-----------------------------------------------------------------

::: media/webrtc/trunk/webrtc/modules/audio_device/android/audio_manager_jni.cc
@@ +85,4 @@
>    // Create a global reference such that the class object is not recycled by
>    // the garbage collector.
> +  g_audio_manager_class_ = jsjni_GetGlobalClassRef(
> +    "org/webrtc/voiceengine/AudioManagerAndroid");

> What thread is this being run on? It will dispatch a runnable synchronously to the main thread, which means it will block waiting for the main thread. Is that ok?

This will end up running on the MediaThread (the backend MediaManager's thread for interfacing with the media code).  Blocking it on MainThread (once? or once per GetUserMedia call?) probably isn't a huge problem.
Attachment #827783 - Flags: review?(blassey.bugs) → review+
Whiteboard: [leave open]
Depends on: 936790

Updated

6 years ago
Depends on: 939532
Depends on: 984256
Blocks: 987979
You need to log in before you can comment on or make changes to this bug.