You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have added the information so fro that we researched. What is missing is how we handle attachments, hanging material and other stuff.
Also we need to get more input on the things that we researched.
need to support a range of angles for the sound angle. for their speakers they have a set of angles within the range that they support. for others they can support any angle in that range
for sound angle, need to support asymetric dispersion with a different angle possible in each direction
also need to support rotation of the sound angle
max SPL is not always in dB. There are different dB formats like a weighted dB.
for mvr, need different material types to support reflectiveness for the audio analysis
The Frequency Min and Max should be at the -6dB mark (instead of the proposed 5dB)
I can confirm, that the MaxSPL taken from 1 meter from the speaker is common practice.
For Listening Planes, I would find it more useful to all polygon with any number of points that make up an infinitesimally thin layer. I believe this is how our software treats listening planes (with no range of height, just a single height measurement hovering over a surface).
we should treat the sound angle almost like a beam of light with a range of values in both the X and Y direction since the sound dispersion is not always symmetrical. using sound angle min X, min Y, max X, max Y. not all speaker manufacturers have this capability to change the angle dynamically on a speaker but we should support it
they also need to be able to rotate the sound, but don't need support for a range of rotations, they just need to be able to set the rotation on the sound "beam" since each speaker is different. an asymmetric dispersion at a 45 deg angle for example
we will get the list of SPL formats that we want to support for the gdtf, but we do not need to worry about converting the values from one format to another, this is not something that is done. speakers are specified with a certain format. so the user just needs the option to choose the format and enter the value, if they change the format later it should remove the value and force them to input a new one
Received the following information from d&b about different formats to support for sound level:
Here is a table with different excitation signals and weightings.
Excitation Signals and weightings are independent from each other and can be used in any combination.
Excitation Signal
Frequency Weighting
Unit
Time Weighting
Unit
Pink noise
None
DBZ, dB or DBSPL
Fast
F
IEC60268 "Program Simulation Noise"
A-Weighting
dBA
Slow
S
EIA426B "Loudspeaker test signal"
C-Weighting
dBC
Leq
Leq, Laeq, LCeq
AES75 "M-Noise"
Peak
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.