denkenreden@ Thanks for the issue.

Request you to provide a sample URL where this issue can be reproduced, which will help in further triaging.

Thanks...

denkenreden@

The repro code doesn't seem to be working even after I fixed the code with a button:

```
document.querySelector('#btn').onclick = () => {
  let ctx = new AudioContext();
  let x = new SBKSessionGenerator(ctx);
  x.play(511);  
};
```

I don't hear anything. Can you check?

@hongchan

Thank you for your help.
I've build a small example illustrating the problem.

Deleted: index.html 1.8 KB

index.html 1.8 KB View Download

Thank you for providing more feedback. Adding the requester to the cc list.

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

Oh, so the original repro case was working as intended. (no sound at all)

Consider this line of code:
```
this.frequencies = [18500, 18800, 19100, 19400, 19700, 20000, 20300, 20600, 20900];
```

The human audible range is typically 20hz~20Khz. But also the audibility is greatly affected by your reproduction device's frequency range (i.e. speaker, headphones and etc)

This is what I use:
https://www.innerfidelity.com/images/SennheiserHD650.pdf

The first graph (frequency response) shows that the headphone has a significant dip (-20dB) in the 10Khz~20Khz area. That means you won't hear much of 18~20Khz from this device.

Also there's one more technical constraint from our Oscillator implementation, which uses Wavetable model. Our model has the notion of "partial culling"; it basically cuts out partials beyond the Nyquist frequency, so the loudness gets smaller as the frequency approaches to the Nyquist. I think this is a common side effect of Wavetable-based oscillator.

FireFox has the same implementation for the OscillatorNode, so you'll get the same effect.

Do you have an actual use case that requires mathematical generation? I think it can be done with AudioWorkletNode by implementing a pure mathematical oscillator.

Especially in an academic environment (where I come from) there are quite a few people which are interested in communication using frequencies between 18 - 21 kHz. Research has shown that frequencies below 21 kHz are usually not a huge problem for speakers and microphones in typical smartphones and notebooks.

I'm working on a system that allows users to join a virtual session (for example a site that provides information for a lecture) using acoustic communication. There are even MAC-Protocols for acoustic communication that target browsers.

I've noticed that there are devices that are able to correctly reproduce the targeted frequencies using the code I provided and using chrome/blink. It seems as if it depends on the combination of the audio interface and the device. Even interfaces that are able to play at such high frequencies seem to fail doing so in certain situations.

To be honest the more I look into this issue I realize that it might be a problem with the audio driver and NOT the browser. Especially software such as Boom 3D - even if deactivated - messes with frequencies above 18 kHz for some reason. Today I discovered that some desktop applications face the same issue.

Since my goal is only to implement a prove of concept my solution is just switching to another audio driver and uninstalling all the software that might alter the audio.

I appreciate your help on this and I suggest closing this issue because I assume its not chrome that modifies the audio.

Thank you!

-Franz

Thanks for your detailed explanation. Please share your work when it goes public! :)

Consider also using an offline audio context to examine what's happening.  I like hoch.github.io/canopy to run simple examples to examine the audio output waveform.