Chrome only plays one source

[nickjillings]

Chrome only plays the first clicked source. This is apparant across all interfaces and if loop is true or false. Both windows and OSX versions tested.

All other browsers behave normally.

[nickjillings]

After some digging around, it appears this is a reported error in Chrome! https://bugs.chromium.org/p/chromium/issues/detail?id=647974&q=setValueAtTime&colspec=ID%20Pri%20M%20Stars%20ReleaseBlock%20Component%20Status%20Owner%20Summary%20OS%20Modified

There is little I can do until this is done, but I may try and find a workaround if this takes more than a week

[nickjillings]

@BrechtDeMan Note above

[BrechtDeMan]

Thanks. Surely this is a new error - if I understand correctly it does not play any samples except for the one that is first clicked? Is this due to a Chrome update, and can we confirm until which version (at least) it works? Or is this due to us, in which case can we revert to a more stable version?

Seems like I would have noticed if this was appearing in earlier versions!

[nickjillings]

This seems to be from a Chome update, there are several reports which highlight this. The bug was first highlighted on the 12th September, a week before Tim started using WAET and raising it to us.

It is somewhat possible to undo, however it would remove the entire cross fading from all browsers and require extensive unpicking. I will look into doing some browser detection to perhaps allow chrome to not use the faulty code, but hopefully Chrome will update their code very soon

[nickjillings]

And by seems to be, it is a chrome update as I have recreated the same bug in an empty browser console.

[BrechtDeMan]

Time for Chrome to be taken over and maintained by a large organisation with some resources... oh wait. A workaround would be great, of course, but alternatively a notice for Chrome users would do the trick (I imagine most Chrome users have another browser available).

[BrechtDeMan]

In Chrome but also in Safari and Firefox (testing for #157), I was able to play quite a few samples, and even stop in between, before it went muted. Seems very erratic, sometimes playing, sometimes not.

Chrome 54.0.2840.59, Safari 8.0.4 and Firefox 47.0 on OS X.10.2

[nickjillings]

@BrechtDeMan are you saying you experienced the playback failure on all of the Browsers? I've only replicated this in Chrome (53 & 54) but not any of the others.

The behaviour I've observed related to this bug is:

1. Play a fragment
2. Stop that fragment
3. Play another fragment - > This will then not play

From Rtoy (Web Audio guy at Google I think) on the bug listing:

This is a bug in an internal optimization for nodes with no inputs. The automations aren't run.

Because the audio buffers are one shot sources, they have to be destroyed and rebuilt each time the sounds stop. Between this time it is possible for a source to wish to change the gain, prempting the playback of the next sound for instance. In looping and synchronous, it should always work because all the nodes are always connected to their gain nodes.

I'm going to add a workaround which is kind of annoying, since it probably does more damage to the optimization than google just undoing their poorly implemented code. The workaround is effectively having an infinitely looping buffer of zeros playing, keeping all the nodes alive but also forcing processing to happen 100% of the page life. Not ideal.

However waiting for Google to rectify this may take longer than we can afford to say 'sorry, we don't support the worlds most popular browser'.

[nickjillings]

I've posted a workaround for the Chrome bug. I've tested it in Firefox and Safari and both behave normally. Chrome now also behaves normally for the majority of the time. There were a few 'missed' triggers, where one was shown as playing. This only occured if I quickly started, stopped, played another and went back to the first one. This is a pretty unlikely scenario, and is not session ending, more a nuisance.

Until Chrome rectify the issue this is most likely the best solution for now.

I've uploaded the current hot_fix onto my waet-dev point: http://dmtlab.bcu.ac.uk/nickjillings/waet-dev/test.html?url=tests/examples/mushra_example.xml

@brecht if you get a chance can you also test if if works for you in Chrome?

[BrechtDeMan]

Tested branch hot_fix locally, all with project.xml.

Chrome

• one time, clicking a sample (without clicking Stop before it) produced no sound at all
• another time, after having clicked stop, the first sample did not play, but it played after switching to another

Safari

• Did not notice any playback issues.

• 156 still true: endless looping scrubber bar when loop is off

• reference is all the way to the left, not in the middle

Firefox

Didn't notice any issues.

[BrechtDeMan]

I now also have http://webprojects.eecs.qmul.ac.uk/bdm30/master/ and http://webprojects.eecs.qmul.ac.uk/bdm30/dev_main/ set up - needs manual updating though so will only be current if I recently pulled the latest commit.

[nickjillings]

Thankf for the info. Yes mine are manual updates as well, but handy to quickly get stuff around.

OK, I'll go ahead and try to merge everything together, I've been working on Dev_main for the moment so will have to tidy some things up.

The Chrome stuff here can only be fixed really by Google, as they've changed the browser behaviour to be outside the speicifcation. Hopefully they'll jump on it soon.

[BrechtDeMan]

I've experienced this in legacy Safari (v8.04) as well. The second kind, i.e.

the first sample did not play, but it played after switching to another

[nickjillings]

I'll look at tightening the playback systems again and see if I can find another issue in there then.

[BrechtDeMan]

Confirmed that this is still an issue in Chrome, not necessarily first clicked stimuli i.e. it also happens after clicking around a bit.