Thanks for filing the issue!

Able to reproduce the issue on reported chrome version 69.0.3497.57 and on the latest canary 70.0.3535.0 using Windows 10.
Note: Issue isn't seen on Mac 10.13.1 and Ubuntu 14.04
 
As the issue is seen from M60(60.0.3112.0) considering it as Non-Regression and marking it as Untriaged.
Note: Tentatively adding component "Blink>Media>Audio", please change if this isn't apt.

If break means audio is no longer heard, then I can reproduce this on Mac and linux well. I also see that CPU goes up to 120% (or more) when audio stops.  Could be that we're not collecting nodes that should have been.  Needs further investigation; pretty sure this is a WebAudio issue.

Did some profiling on my Z840 (gn enable_profiling=true).  pprof top20 results below, but the tldr is that we spend quite a bit of time clamping the automation values to the nominal range.  We're also allocating (and deallocating) a lot of memory somewhere, and that's not good, if the allocation is happening in WebAudio.  Fixing these will certainly help, but I'm not sure if it will make the song play without glitches.  One step at a time....

    1642  12.1%  12.1%     1642  12.1% float clampToDirectComparison (inline)
     775   5.7%  17.8%     2904  21.4% blink::AudioParamTimeline::ValuesForFrameRange
     624   4.6%  22.4%      645   4.8% WTF::Partitions::FastFree@51bae0 (inline)
     614   4.5%  26.9%      614   4.5% __pthread_mutex_trylock
     595   4.4%  31.3%      709   5.2% WTF::Partitions::FastMalloc@3b9f30 (inline)
     477   3.5%  34.8%      477   3.5% blink::AudioBus::Zero (inline)
     455   3.4%  38.2%     5015  36.9% blink::AudioParamHandler::CalculateFinalValues (inline)
     381   2.8%  41.0%      381   2.8% __pthread_mutex_unlock_usercnt
     337   2.5%  43.5%      342   2.5% WTF::PartitionAllocator::FreeVectorBacking (inline)
     322   2.4%  45.8%      322   2.4% blink::AudioParamTimeline::ValuesForFrameRangeImpl (inline)
     257   1.9%  47.7%      329   2.4% WTF::PartitionAllocator::AllocateBacking (inline)
     249   1.8%  49.6%     5581  41.1% blink::AudioHandler::ProcessIfNecessary
     218   1.6%  51.2%     9766  71.9% blink::AudioNodeInput::Pull
     208   1.5%  52.7%      225   1.7% base::PartitionGenericSizeToBucket (inline)
     159   1.2%  53.9%      868   6.4% WTF::Partitions::FastMalloc@3b9f30
     143   1.1%  54.9%      146   1.1% blink::Biquad::Process
     139   1.0%  55.9%     6995  51.5% blink::AudioParamHandler::CalculateFinalValues
     132   1.0%  56.9%      777   5.7% WTF::Partitions::FastFree@51bae0
     127   0.9%  57.9%      450   3.3% blink::AudioParamTimeline::ValuesForFrameRangeImpl
     122   0.9%  58.8%      599   4.4% blink::AudioBus::Zero

Implemented some optimizations and pprof top20 results are below, showing some nice improvements.  This helps quite a bit, but the demo still takes like 90% CPU on my Z840.

The allocations are gone (9.6%) and clampTo has gone from 12% to 6.8% (sum of all the Vclip routines)

     680   5.6%   5.6%      680   5.6% __pthread_mutex_trylock
     677   5.6%  11.2%      677   5.6% blink::AudioBus::Zero (inline)
     478   3.9%  15.2%      478   3.9% blink::VectorMath::AVX::Vclip
     474   3.9%  19.1%      474   3.9% __pthread_mutex_unlock_usercnt
     366   3.0%  22.1%      366   3.0% blink::AudioParamTimeline::ValuesForFrameRangeImpl (inline)
     305   2.5%  24.6%     4401  36.4% blink::AudioHandler::ProcessIfNecessary
     273   2.3%  26.9%     6397  52.8% blink::AudioNodeInput::Pull
     241   2.0%  28.9%     1831  15.1% blink::AudioParamTimeline::ValuesForFrameRange
     225   1.9%  30.7%      228   1.9% blink::VectorMath::SSE::Vclip
     180   1.5%  32.2%      857   7.1% blink::AudioBus::Zero
     178   1.5%  33.7%      305   2.5% blink::AudioParamHandler::CalculateSampleAccurateValues (inline)
     170   1.4%  35.1%     2638  21.8% blink::AudioParamHandler::CalculateFinalValues (inline)
     169   1.4%  36.5%      169   1.4% blink::Biquad::Process
     147   1.2%  37.7%      147   1.2% __GI___pthread_getspecific
     142   1.2%  38.9%     2781  23.0% blink::AudioParamHandler::CalculateFinalValues
     131   1.1%  39.9%      131   1.1% syscall
     127   1.0%  41.0%      127   1.0% _ZNSt3__14swapIPN5blink8AudioBusEEENS_9enable_ifIXaasr21is_move_constructibleIT_EE5valuesr18is_move_assignableIS5_EE5valueEvE4typeERS5_S8_ (inline)
     126   1.0%  42.0%      126   1.0% epoll_wait
     124   1.0%  43.1%      223   1.8% blink::VectorMath::X86::Vclip (inline)
     123   1.0%  44.1%      492   4.1% blink::AudioParamTimeline::ValuesForFrameRangeImpl

For the record, I'm attaching the pprof dot files that show the call graph and usages.  ref-result.dot is the ToT build and opt-result.dat is the same version but with some optimizations.

The CPU usage shown by running top goes from about 120% worst case to about 90% on my machine.  That's a nice 30% point reduction, but still pretty heavy usage.

Deleted: ref-results.dot 15.9 KB

ref-results.dot 15.9 KB Download

Deleted: opt-results.dot 14.8 KB

opt-results.dot 14.8 KB Download

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

commit 7e8253c958ca8f5105d09468a45155ee8a3053c7
Author: Raymond Toy <rtoy@chromium.org>
Date: Fri Sep 28 21:52:40 2018

Optimize AudioParam

Implement a few optimizations for AudioParams

o Preallocate summing_bus instead of creating a new summing bus each
  time the final values need to be computed. And only use the bus if
  needed.
o Use vectorized Vclip to clamp the values to the nominal range.

Roughly the CPU usage (according to top) goes from 120% to 90% on my
machine.  The bug contains pprof dot files that show all of the
profiling results.

Bug:  878301 
Change-Id: I99670a8397f5344e9a3ad88fe4d748f7e0486895
Reviewed-on: https://chromium-review.googlesource.com/1249583
Reviewed-by: Hongchan Choi <hongchan@chromium.org>
Commit-Queue: Raymond Toy <rtoy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#595227}
[modify] https://crrev.com/7e8253c958ca8f5105d09468a45155ee8a3053c7/third_party/blink/renderer/modules/webaudio/audio_param.cc
[modify] https://crrev.com/7e8253c958ca8f5105d09468a45155ee8a3053c7/third_party/blink/renderer/modules/webaudio/audio_param.h
[modify] https://crrev.com/7e8253c958ca8f5105d09468a45155ee8a3053c7/third_party/blink/renderer/modules/webaudio/audio_param_timeline.cc

tommiutri@ can you try out Chrome canary to see if the latest change helps out?  It definitely doesn't fix everything, but might help out a bit.  There's still work to do, but it's a bit harder to find and optimize the culprits.

Excellent, good work, 
I hereby confirm the problem is solved in Version 71.0.3568.0 (Official Build) canary (32-bit), there is no more crash in Apps that are playing midi like this.

I'm surprised that this helps enough. :-)

But based on c#10, I'll declare this as fixed.  If you run into more problems, please file a new issue.