Hello Mikoláš,

Thanks for your email. I checked into what I am allowed to share, and
the Company I work for owns the implementation but I own the idea for
what we did, including the design using Csound. Therefore, while I am
not authorized to share the exact code we used I can explain the
design of the system and some of the key opcodes we used to get the
result.

By profession I am an audiologist. One of the tools in the audiology
toolkit is to do what is called a sound survey; this forms the basis
of any hearing conservation program. In summary, a sound survey tells
us some detail about what sound levels are at various physical
locations in an industrial environment. In this case our industrial
environment was an office layout that has several cubicles where
various professionals spend their days working.
https://www.3m.com/3M/en_US/safety-centers-of-expertise-us/center-for-hearing-conservation/measure/
https://www.osha.gov/laws-regs/regulations/standardnumber/1910/1910.95
Usually you end up with a picture or graph that looks something like a
floor layout superimposed with sound levels, much like what you see on
this page:
http://www.inertance.com/noise/industrial-noise/

Once we did the sound survey, we had to decide where to put the
microphones to avoid contamination from adjacent speakers, minimize
open/closed-loop feedback, where to put the speakers in the space to
produce the masking noise, and how the elements driving these
components would interact; in our case it was a bunch of Raspberry Pis
running Csound headless (meaning no monitors or keyboards).

Based on the size of our space we ended up with an array of 12
microphones that we put at various points of the room including the
ceiling and on some cubicle walls, and 6 speakers. The microphones are
micro-miniature Sonion MEMS digital mics connected to each Raspberry
Pi 3 via I2C and the speakers are simply coming out of the analogue
audio bus from Raspberry Pi model 2's that we had sitting around. We
just put them above the floating ceiling tiles.

The design inputs to the system include being able to monitor and
dynamically adjust a masking noise that is shaped based on a long term
average spectrum of speech (LTASS) measured from the environment. To
do this we segment the available frequency subdivisions using the Bark
scale, in our case 16 critical bands (index 3-19 from this figure):
https://en.wikipedia.org/wiki/Bark_scale
This is important because we want the minimum amount of sound pressure
level needed to produce a perceptual masking effect. Contrary to what
people tend to think when I explain this system, we are not writing
audio information the Csound tables; instead we segment the available
audio base-band spectrum into 16 critical bands, and monitor RMS
levels in each, applying gain or attenuation as needed. The analysis
is done using "pvsanal" and the crossover frequency design mimics that
seen in WOLA (weighted overlap-add, NOT overlap-add convolution).

For Csound specifically we simply use the "noise" opcode (with a beta
value of 0) with what amounts to similar techniques used in
subtractive synthesis; we produce much more amplitude than we need at
a given frequency subdivision and subtract what we do not need within
a given frequency band. The "OSClisten" and "OSCsend" opcodes are used
simply to pass around numeric information gathered from the "rms"
opcode across the 16 bands which is written into a table using
"tablew" and read using the "table" opcode. Each two microphones are
associated with one speaker; this was done to avoid audible artifacts,
feedback, or measurement errors from microphones and speakers being
too close to one another. The Csound design is similar across all
embedded hardware in that we have an orchestra that runs with infinite
duration (initialized in the instr 0 space) using the first instrument
in each instance as a control or 'brain' instrument that then creates
tables using "ftgen" and instrument events using "schedule". Like many
things in Csound, this whole design and implementation is ultimately
realized with what might be seen as simple code but that wraps a
complex idea.

There are a number of things I would have liked to add to the design
such as writing to log text files, using the zak system, the ability
to dynamically adjust frequency weighting using a machine learning
algorithm based on TensorFlow, the ability to add 'presets,' and so on
but the executive team at my Company was pleased with the result and
we had to cordon off the scope to not get out of hand. Ultimately it
cost about $1000 in hardware compared to a quote of $35000 for another
company to do it all for us (labor and hardware).

Coming back to the original topic, this is all being done in MN, using
Csound! For more detail it really is the kind of thing that's better
discussed in person. Not sure what types of conferences or talks or
whatever people are doing on Csound these days but sharing is caring
and knowledge is power, maybe if I am lucky I will be able to present
something ridiculous like this some day. For now, dear reader, I hope
this helps in your Csound journey.

Best regards,
David

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Hi David,

First of all, thanks for your response about the Minnesota Csound and computer music community.  That's very helpful information.  I'm aware of some of the modular, SuperCollider, and Max/MSP folks, but the only other person I've found doing Csound is a colleague of mine who is customizing the code in his Q-bit Nebulae module.  I'll keep on the lookout for others doing Csound.  And maybe I'll just rub elbows with the SuperCollider and Max/MSP folks if I can't find more Csounders.

Second of all, your office noise masking system is one of the coolest audio systems I've ever heard of.  Fascinating.  Thanks for sharing your approach to the design!

Best,

Jason 

On Fri, Mar 6, 2020 at 12:36 PM David Akbari <dakbari@gmail.com> wrote:

Hello Mikoláš,

Thanks for your email. I checked into what I am allowed to share, and
the Company I work for owns the implementation but I own the idea for
what we did, including the design using Csound. Therefore, while I am
not authorized to share the exact code we used I can explain the
design of the system and some of the key opcodes we used to get the
result.

By profession I am an audiologist. One of the tools in the audiology
toolkit is to do what is called a sound survey; this forms the basis
of any hearing conservation program. In summary, a sound survey tells
us some detail about what sound levels are at various physical
locations in an industrial environment. In this case our industrial
environment was an office layout that has several cubicles where
various professionals spend their days working.
https://www.3m.com/3M/en_US/safety-centers-of-expertise-us/center-for-hearing-conservation/measure/
https://www.osha.gov/laws-regs/regulations/standardnumber/1910/1910.95
Usually you end up with a picture or graph that looks something like a
floor layout superimposed with sound levels, much like what you see on
this page:
http://www.inertance.com/noise/industrial-noise/

Once we did the sound survey, we had to decide where to put the
microphones to avoid contamination from adjacent speakers, minimize
open/closed-loop feedback, where to put the speakers in the space to
produce the masking noise, and how the elements driving these
components would interact; in our case it was a bunch of Raspberry Pis
running Csound headless (meaning no monitors or keyboards).

Based on the size of our space we ended up with an array of 12
microphones that we put at various points of the room including the
ceiling and on some cubicle walls, and 6 speakers. The microphones are
micro-miniature Sonion MEMS digital mics connected to each Raspberry
Pi 3 via I2C and the speakers are simply coming out of the analogue
audio bus from Raspberry Pi model 2's that we had sitting around. We
just put them above the floating ceiling tiles.

The design inputs to the system include being able to monitor and
dynamically adjust a masking noise that is shaped based on a long term
average spectrum of speech (LTASS) measured from the environment. To
do this we segment the available frequency subdivisions using the Bark
scale, in our case 16 critical bands (index 3-19 from this figure):
https://en.wikipedia.org/wiki/Bark_scale
This is important because we want the minimum amount of sound pressure
level needed to produce a perceptual masking effect. Contrary to what
people tend to think when I explain this system, we are not writing
audio information the Csound tables; instead we segment the available
audio base-band spectrum into 16 critical bands, and monitor RMS
levels in each, applying gain or attenuation as needed. The analysis
is done using "pvsanal" and the crossover frequency design mimics that
seen in WOLA (weighted overlap-add, NOT overlap-add convolution).

For Csound specifically we simply use the "noise" opcode (with a beta
value of 0) with what amounts to similar techniques used in
subtractive synthesis; we produce much more amplitude than we need at
a given frequency subdivision and subtract what we do not need within
a given frequency band. The "OSClisten" and "OSCsend" opcodes are used
simply to pass around numeric information gathered from the "rms"
opcode across the 16 bands which is written into a table using
"tablew" and read using the "table" opcode. Each two microphones are
associated with one speaker; this was done to avoid audible artifacts,
feedback, or measurement errors from microphones and speakers being
too close to one another. The Csound design is similar across all
embedded hardware in that we have an orchestra that runs with infinite
duration (initialized in the instr 0 space) using the first instrument
in each instance as a control or 'brain' instrument that then creates
tables using "ftgen" and instrument events using "schedule". Like many
things in Csound, this whole design and implementation is ultimately
realized with what might be seen as simple code but that wraps a
complex idea.

There are a number of things I would have liked to add to the design
such as writing to log text files, using the zak system, the ability
to dynamically adjust frequency weighting using a machine learning
algorithm based on TensorFlow, the ability to add 'presets,' and so on
but the executive team at my Company was pleased with the result and
we had to cordon off the scope to not get out of hand. Ultimately it
cost about $1000 in hardware compared to a quote of $35000 for another
company to do it all for us (labor and hardware).

Coming back to the original topic, this is all being done in MN, using
Csound! For more detail it really is the kind of thing that's better
discussed in person. Not sure what types of conferences or talks or
whatever people are doing on Csound these days but sharing is caring
and knowledge is power, maybe if I am lucky I will be able to present
something ridiculous like this some day. For now, dear reader, I hope
this helps in your Csound journey.

Best regards,
David

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here