The change in output is this:

-FAIL insertDTMF() with transceiver stopped in the middle should stop future tonechange events from firing assert_greater_than: More tonechange event is fired than expected expected a number greater than 0 but got 0
+PASS insertDTMF() with transceiver stopped in the middle should stop future tonechange events from firing

So it's a test that turns successful at some point.
It's strange if it only happens on Mac.

Reassigning to you Harald since this likely has to do with your recent DTMF changes.

With your latest changes we have full control of the buffer we feed to the sender on the webrtc layer.
However, the audio DTMF sender on the webrtc layer involves both the signaling thread and the worker thread.

My guess is that there is a race between the worker thread doing the playout of the tone and the signaling thread stopping the transceiver (caused by main thread stopping the transceiver).

Whether or not the buffer empties would matter to whether or not "playout" is visible on the other end, but I that is irrelevant here.

We should abort if the transceiver has been stopped and never feed it the letter "C" in the test.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/c62ce43b9bbb46a2c3b5f272ebaf83fd452c225d

commit c62ce43b9bbb46a2c3b5f272ebaf83fd452c225d
Author: Harald Alvestrand <hta@chromium.org>
Date: Mon Oct 08 16:17:34 2018

Disable layout test RTCDTMFSender-ontonechange (flaky)

Bug: 893112
Change-Id: Ieb111c7bfb25d298881ed6945f74d51dc9ad07db
Reviewed-on: https://chromium-review.googlesource.com/c/1268244
Reviewed-by: Harald Alvestrand <hta@chromium.org>
Reviewed-by: Florent Castelli <orphis@chromium.org>
Commit-Queue: Harald Alvestrand <hta@chromium.org>
Cr-Commit-Position: refs/heads/master@{#597579}
[modify] https://crrev.com/c62ce43b9bbb46a2c3b5f272ebaf83fd452c225d/third_party/WebKit/LayoutTests/TestExpectations