Tested the issue on Win-10 using chrome reported version #58.0.3029.110 and latest canary #60.0.3096.0.

Following are the steps followed to reproduce the issue.
------------
1. Opened the URL: https://mdn.github.io/webaudio-examples/audiocontext-states/ in 6 tabs.
2. Started by pressing "Create context" button in all the tabs one by one.
3. Then suspended 1 audio context per page.
4. Opened a 7th audio context and started by pressing "Create context" button and suspended by pressing "suspend context" button.
5. Observed that 7th audio context started and suspended without any issues.

Attached a screen cast for reference.

Reporter@ - Could you please verify the screen cast and please let us know if anything missed from our side. If possible please provide a screen cast explaining the exact issue.

Thanks...!!

Deleted: 721371.mp4 1.2 MB

	721371.mp4 1.2 MB View Download

reproduced exactly what you did and got the bug.
Can do a screencast but really exact same result but I hit the limit.

perhaps need to try with new private tab, then maybe need to reboot and do it with only chrome browser running to get same results as you

Thank you for providing more feedback. Adding requester "krajshree@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Seems with a new clean session it's not always doing the bug, but still. can repro


Following are the steps followed to reproduce the issue.
------------
1. Opened the URL: https://mdn.github.io/webaudio-examples/audiocontext-states/ in 6 tabs.
2. Started by pressing "Create context" button in all the tabs one by one.
3. Then suspended 1 audio context per page.
4. Opened a 7th audio context and started by pressing "Create context" button and suspended by pressing "suspend context" button.
5. Observed that 7th audio context started and suspended without any issues.

Deleted: 2017-05-12_12-53-26.mp4 1.3 MB

	2017-05-12_12-53-26.mp4 1.3 MB View Download

once it has done it, the repro stays consistent though

Tested the issue on Win-10 using chrome reported version #58.0.3029.110 and latest canary #60.0.3099.0. This time in a new incognito window as per your screen cast.

Following are the steps followed to reproduce the issue.
------------
1. Opened the URL: https://mdn.github.io/webaudio-examples/audiocontext-states/ in 6 tabs.
2. Started by pressing "Create context" button in all the tabs one by one.
3. Then suspended 1 audio context per page.
4. Opened a 7th audio context and started by pressing "Create context" button and suspended by pressing "suspend context" button.
5. Observed that 7th audio context started and suspended without any issues.

Reporter@ - Could you please let us know if any short cut keys are used to create and suspend context. 

Thanks...!!

all done using the with the mouse.

Note: Co-worker can reproduce only if using "duplicate tab"

Thank you for providing more feedback. Adding requester "krajshree@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

here is a page that reproduce the bug each time here, easier to test:

http://jsbin.com/suzoxiqicu/1/edit?js,output

In devtools console I get:

0 1 2 3 4 5 started
runner-4.0.2.min.js:1 n° 0 suspended
runner-4.0.2.min.js:1 n° 1 suspended
runner-4.0.2.min.js:1 n° 2 suspended
runner-4.0.2.min.js:1 n° 3 suspended
runner-4.0.2.min.js:1 n° 4 suspended
runner-4.0.2.min.js:1 n° 5 suspended
runner-4.0.2.min.js:1 n° 6 starts
runner-4.0.2.min.js:1 Error: Failed to construct 'AudioContext': The number of hardware contexts provided (6) is greater than or equal to the maximum bound (6).
    at new Player (suzoxiqicu.js:7)
    at suzoxiqicu.js:221
suzoxiqicu.js:7 Uncaught DOMException: Failed to construct 'AudioContext': The number of hardware contexts provided (6) is greater than or equal to the maximum bound (6).
    at new Player (suzoxiqicu.js:7:13)
    at suzoxiqicu.js:221:20

Not sure why you think suspending a context will allow more contexts to run.  If you really want that, you should close() the context.  Suspending a context just puts the context to sleep, but is ready to go as soon as you resume() it.

I was hoping for it when reading the "may" word in the W3C specs:
"suspended: This context is currently suspended (context time is not proceeding, audio hardware may be powered down/released)."

As doing it in js is a bit of work and not that practical (release of resources are GC dependant) and even not clear (no mediaElement audiocontext disconnect), not speaking of needing a new user gesture on mobile, all the cache/stream re-downloading all medias, etc. Doing it with suspend would be clearly easier for me :)

As for using "close", I tried that and have another bug report for using it for that exact problem, and need to do a jsbin repro too it seems : https://bugs.chromium.org/p/chromium/issues/detail?id=721373

For chrome, suspending does in fact release the audio device, but the audio context is still alive.  And for unknown historical reasons, you can only have 6 concurrent contexts.

The user gesture is a very recent addition to the spec here:  https://webaudio.github.io/web-audio-api/#constructors

Not being able to disconnect a media element is a spec issue:  https://github.com/WebAudio/web-audio-api/issues/1202

I think Chrome is behaving correctly in this case.

Closing this as WontFix (working as intended).  Please reopen or file a new issue if you think this isn't correct.

Ok, thanks for followup.