AnalyserNode.getByteFrequencyData() is affected by the sample rate of the output device
Categories
(Core :: Web Audio, defect, P3)
Tracking
()
People
(Reporter: li-peijian, Unassigned)
Details
Attachments
(2 files, 2 obsolete files)
Screenshot (210).png
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/112.0.0.0 Safari/537.36 Edg/112.0.1722.68
Steps to reproduce:
Change the default format of Windows sound playback device to a different sample rate.
Play audios with Web Audio API and draw frequency graphics with AnalyserNode.getByteFrequencyData().
Actual results:
In different sample rate of the output device, the amount of effective data that AnalyserNode.getByteFrequencyData() returns is different, that makes the peak's width of frequency graphics looks different.
Expected results:
Is this match the API specifications?
I thought this should be same in any output device's any sample rate.
|
Reporter | |
Comment 1•2 years ago
|
||
|
|
Reporter | |
Comment 2•2 years ago
|
||
|
|
Reporter | |
Comment 3•2 years ago
|
||
|
||
Comment 4•2 years ago
|
||
Reviewing:
https://webaudio.github.io/web-audio-api/#dom-analysernode-getbytefrequencydata
I see there have been some behaviour corrections since we last updated this method, not sure if we were already in line with the expected behaviour:
https://github.com/WebAudio/web-audio-api/issues/2361
|
||
Comment 5•2 years ago
|
||
This is expected. The file you're playing doesn't have frequency content after 20kHz, and you're drawing up to 192kHz.
Per specification the analyzer returns data up to the AudioContext sample-rate / 2 (the Nyquist frequency), which means most of the values are going to be 0, because the audio contains audio data with a frequency up to about 16kHz (looking at the second graph), and you ask to plot up to 192kHz.
Description
•