Patent Description:
A major disadvantage felt by these markets, is that optimum performance of an audio solution requires high levels of staff monitoring and interaction, which is rarely possible or practical. Therefore, audio solutions in general deliver poor results when left to their own devices.

Systems for managing sound emitting devices are known form patent documents <CIT>, <CIT>, <CIT>, <CIT>, <CIT>, <CIT>, <CIT>. The customization of audio content based on demographic criteria is known from <CIT>.

The reference to any prior art in this specification is not, and should not be taken as, an acknowledgement or any form of suggestion that the prior art forms part of the common general knowledge.

The system and method of the invention, also referred to herein as `Autonomous Volume Adjustment', or 'AVA' has been developed to ameliorate the problems of the prior art. AVA is an always on, autonomous algorithm which monitors noise levels inside a given area and makes multiple adjustments or sends notifications to speakers, IoT devices, digital services, APIs and other connected devices. AVA matches the listening conditions in store/venue with the appropriate playback settings (volume, treble, bass, frequency and other settings/filters) in near real time. AVA also assists in making content selection adjustments and may send/receive other notifications based on audio input device (such as a microphone) measurements which it has linked to in store behaviours/patterns over time.

The scope of the invention is set out in claim <NUM>.

Throughout this specification (including any claims which follow), unless the context requires otherwise, the word 'comprise', and variations such as 'comprises' and 'comprising', will be understood to imply the inclusion of a stated integer or step or group of integers or steps but not the exclusion of any other integer or step or group of integers or steps.

It is convenient to describe the invention herein in relation to particularly preferred embodiments referred to in at least partially as AVA as an example implementation by Qsic and incorporating an example controller referred to herein from time to time as the Qbit. In these example embodiments, the Qsic API is used to refer to an Application Programming Interface housed on one or more computing devices which are in communication with the controller. In some preferred embodiments, the Qsic API is remote and may for example be accessed via the internet or another network or communications link. However, the invention is applicable to a wide range of implementations and it is to be appreciated that other constructions and arrangements are also considered as falling within the scope of the invention. Various modifications, alterations, variations and or additions to the construction and arrangements described herein are also considered as falling within the ambit and scope of the present invention.

AVA is an improvement over simple flat level decibel based volume adjustments on groups of speakers. In some implementations AVA uses multiple microphones to identify the location of noise and the levels of noise at those locations, then algorithmically adjusts the individual speakers based on each speaker's proximity to the microphone and the speakers ideal volume against an aggregated input value. This is all done in real-time and on a one to one basis for each individual speaker and the origin of the noise.

In some implementations, AVA uses network/internet enabled speakers, this means that far more than just volume may be being controlled. Other levels of adjustment might for example include, but are not limited to: perceived loudness (individual frequencies) when listening at low volumes, sound morphing, speech clarity, Bass, Treble, Balance and anything else a speaker (preferably an intelligent speaker) can be used to control. In some comparative, not claimed examples the system of the invention may adjust one or more characteristics of queued or live content to fit the environment and circumstances at hand. In some comparative, not claimed examples, the system may for example tailor content to the current audience by normalising or setting levels in content prior to playing. This may for example be done when the content is loaded into the system of the invention so that it is ready for any future use, or a set time before it is scheduled to be played, or at any other suitable time. Such tailoring of content may in some comparative, not claimed examples be temporary - for example only for the purpose of playing at that venue at that time, or it may be more longstanding, for example for a particular venue or audience, etc irrespective of when it is played.

In some comparative, not claimed examples, the system and method of the invention also comprises a learning algorithm. In such implementations, over time AVA, utilising the Qsic API and infrastructure, will learn how different store/venue purchasing conditions sound and can make adjustments based on that. This includes, but not limited to; content adjustment, triggering in-store promotions, notifying in real time other digital services about upcoming changes in the in-store/venue environment and sentiment analysis.

An important element of the invention is the sensing of information in the managed environment and feedback of that information to a processor which makes adjustments accordingly. In the embodiment, this comprises a microphone. In some comparative, not claimed examples, a configuration algorithm may be run, which for example may assess and set minimum and maximum parameters (for example volume level) the speakers can be set to. Preferably such configuration is undertaken under specific room conditions. <FIG> is a schematic showing one example configuration algorithm.

As the room becomes louder (for example, through more people entering, talking more loudly, machines being switched on) the system can adjust the speakers (which may be intelligent speakers) so that the music is always at an audible level. By doing this the sound reading that is recorded by the microphone will for example increase with increasing background noise.

When calibrating a system, each speaker's volume (measured as a <NUM>-<NUM> percentage) is recorded against a specific microphone reading which represents an ambient level in the space, which might be for example a venue room. In some comparative, not claimed examples, speakers volumes may not be recorded as a percentage, but some other measure, for example the unit relative to the speaker manufactures specification. This serves as the basis for the equation of the speaker that will be used to find its ideal volume at any point in time. Multiple readings are preferably carried out as there is a high point and a low point in the ambient noise. The more of such recordings that are undertaken, the more information the controller will have in order to create the equation needed to adjust each speaker's volume levels.

Once sufficient data points have been obtained, the system can algorithmically create an equation to describe the relationship and create a graph of each speaker's volume vs the overall microphone reading. This allows the speakers to be adjusted by a controller such as the Qbit in response to varying noise levels as detected by the sensor (such as a microphone).

In some comparative, not claimed examples, the way each speaker is controlled is tied to the application on a device comprising a processor on a network, for example a Local Area Network (LAN), which is preferably located within the venue to provide as 'real-time' adjustments as possible.

In one example algorithm, the formula that has been prepared according to the process set out above allows the system to monitor each speaker to run the equation every x seconds which determines how often each speaker is updated with a new volume. In some comparative, not claimed examples, x is a number in the range of <NUM> and <NUM>, but it may also be larger or smaller as practically required for each implementation. For systems that need speakers to be updated more often a lower number should be favoured. The formula that is generated for each speaker may for example be dependant on the power output (for example, peak data input, decibel level, RMS values) vs the volume of the speaker.

In other example implementations, another characteristic is measured and used to adjust operation of a speaker. For example, "perceived loudness", may be used, for example by applying an approximate logarithmic relationship filter to the raw data to modify the Power. Other characteristics which may be measured for the purpose of determining the relationship to use to adjust operation of a speaker, might for example comprise equal loudness contours or decibels.

An example of RMS is a set of "data frames", where data frames is a section of data streamed into the Qbit from the microphone, which are passed into the rms formula which can generally be expressed as. This gives us the average 'power' of the data stream over a period of time.

RMS values are a way of referring to a speaker's power which is averaged over time. Since the power of an alternating current waveform supplying a speaker varies over time, audio power is typically measured as an average over time. An approximation of this can be obtained by making the assumption that it is a purely resistive load and using the root mean square (RMS) values of the voltage and current waveforms. An example formula according to this method is: <MAT>.

Where P = power, V = voltage and I = current.

In order to identify a new, adjusted speaker volume, a computing device, such as a Qbit, creates a formula for that speaker. It first receives an array of pre recorded RMS and Volumes which are used to create a vector of coefficients and least squares polynomial fit.

As a general example Curve Fitting is used to create a polynomial which gives the ability to evaluate the a volume when an RMS value is passed in. As a basic example Volume = x^<NUM> + 2x +b, where x is RMS.

As a further example, using Python, to fit a polynomial p(x) = p[<NUM>] * x**deg +. + p[deg] of degree deg to points (x, y). The following returns a vector of coefficients p that minimises the squared error.

Relative condition number of the fit. Singular values smaller than this relative to the largest singular value will be ignored. The default value is len(x)*eps, where eps is the relative precision of the float type, about 2e-<NUM> in most cases. full : bool, optional.

Switch determining nature of return value. When it is False (the default) just the coefficients are returned, when True diagnostic information from the singular value decomposition is also returned. w : array_like, shape (M,), optional.

Weights to apply to the y-coordinates of the sample points. For gaussian uncertainties, use <NUM>/sigma (not <NUM>/sigma**<NUM>). cov : bool, optional.

Return the estimate and the covariance matrix of the estimate If full is True, then cov is not returned.

Polynomial coefficients, highest power first. If y was <NUM>-D, the coefficients for k-th data set are in p[:,k].

Present only if full = True. Residuals of the least-squares fit, the effective rank of the scaled Vandermonde coefficient matrix, its singular values, and the specified value of rcond. For more details, see linalg.

Present only if full = False and cov'=True. The covariance matrix of the polynomial coefficient estimates. The diagonal of this matrix are the variance estimates for each coefficient. If y is a <NUM>-D array, then the covariance matrix for the 'k-th data set are in V[:,:,k].

The solution minimizes the squared error <MAT> in the equations: <MAT>.

The coefficient matrix of the coefficients p is a Vandermonde matrix.

This can then be used to identify (for example from a lookup table) a speaker's new volume to match any RMS value.

In layman's terms, a speaker will have an ideal volume vs a specific RMS value. The algorithm will make an adjustment to a speaker's volume to attempt to get it closer to its ideal value. This adjustment has parameters such as the maximum increase amount (to stop large sudden jumps in volume), maximum and minimum volume levels (which determine the speakers working range), how often each reading should be taken and how often each adjustment should be made.

In practice, in some comparative, not claimed examples, the Qbit will obtain an RMS value for a period of time, x seconds (wherein x seconds is as defined above) from the microphone and will hold that value until it gets the next one. The process controlling each speaker on the Qbit will request or be sent that value from the process managing the microphone input at separate intervals allowing it to make its own adjustments accordingly. Thus creating the autonomous volume adjustment.

The following key explains the various components used in each figure.

<FIG> is a schematic representation of a single point of Noise origin to a single speaker. In <FIG> a Microphone M1 which can detect sound within the region of radius from M1 denoted by circumference R1, receives sound input from speaker S1 and noise origin A1. The combined volume of the sound emanating from A1 and S1 will decrease as it travels to M1 where it is converted to an electrical signal and sent to the Qbit Q1 which receives the signal, recognises it as associated with microphone M1 and therefore speaker S1 and runs an algorithm associated with speaker S1, generating an output and sends a signal to speaker S1 to adjust the speaker volume S1.

<FIG> is a schematic representation of a single point of noise origin to multiple speakers. Microphone M1 which can detect sound within the region of radius from M1 within circumference R1, receives a combined sound input from speakers S1 and S2 along with ambient sound from A1. The combined volume of the sound emanating from A1 as well as S1 & S2 will decrease as it travels to M1 where it is then converted to an electrical signal and sent to the Qbit Q1 which recognises the signal as associated with microphone M1 and therefore speakers S1 and S2, runs one or more algorithms associated with one or more of speakers S1 and S2, generating one or more outputs and sends a signal to one or both of speakers S1 and S2 to adjust operation of speakers S1 & S2 accordingly.

<FIG> is a representation of multiple points of noise to multiple speakers. Microphone M1 which can detect sound within the region of radius denoted by circumferences R1, receives a combined sound input from speakers S1 and S2 along with ambient sound from A1, A2, A3 and A4. The combined volume of the sound emanating from A1, A2, A3 & A4 as well as S1 & S2 will decrease as it travels to M1 where it is then converted to an electrical signal and sent to the Qbit Q1 which recognises the signal as associated with microphone M1 and therefore speakers S1 and S2, runs one or more algorithms associated with one or more of speakers S1 and S2, generating one or more outputs and sends signal to one or both of speakers S1 and S2 to adjust operation of speakers S1 & S2 accordingly.

<FIG> is a representation of multiple points of noise with multiple speakers split across multiple microphones M1 & M2. M1 which can detect sound within the region of radius denoted by circumferences R1 and will receive a combined sound input from speakers S1 and S2 along with ambient sound from A1, A2, A3 and A4. The combined volume of the sound emanating from A1, A2, A3 and A4 as well as S1 and S2 will decrease as it travels to M1 where it is then converted to an electrical signal and sent to the Qbit Q1 which recognises the signal as associated with microphone M1 and therefore speakers S1 and S2. The Qbit then runs one or more algorithms associated with one or more of speakers S1 and S2, generating one or more outputs and sends signal to one or both of speakers S1 and S2 to adjust operation of speakers S1 and S2 accordingly.

Staying with <FIG>, M2 which can detect sound within the region of radius denoted by circumferences R2 will receive a combined sound input from speakers S3 and S4 along with ambient sound from A2 and A5. The combined volume of the sound emanating from A2 and A5 as well as S3 and S4 will decrease as it travels to M2 where it is then converted to an electrical signal and sent to the Qbit Q1 which recognises the signal as associated with microphone M2 and therefore speakers S4 and S5. The Qbit then runs one or more algorithms associated with one or more of speakers S4 and S5, generating one or more outputs and sends signal to one or both of speakers S4 and S5 to adjust operation of speakers S4 and S5 accordingly. In the case of A2, sound would be contributed to both Microphones as it impacts on both regions as defined by R1 and R2. M1 and M2 make no distinction between A2 and treat it as their own source as it falls in both M1 and M2's radius.

<FIG> shows Microphone M1 which can detect sound from speakers S1, S2 as well as ambient sounds from A1. On detecting sound, M1 sends microphone signal to Qbit Q1 which adjusts the volumes of S1 & S2 based on the combined ambient noise of the environment. The combined volume of the sound emanating from A1 as well as S1 & S2 will decrease as it travels to M1 where it is then converted to an electrical signal and sent to the Qbit Q1 which recognises the signal as associated with microphone M1 and therefore speakers S1 and S2, runs one or more algorithms associated with one or more of speakers S1 and S2, generating one or more outputs and sends a signal to one or both of speakers S1 and S2 to adjust operation of speakers S1 & S2 accordingly.

<FIG> is a representation of how speakers react to ambient noise decreases. <FIG> shows Microphone M1 which can detect sound from speakers S1, S2 as well as ambient sounds from A1, sends input to a Qbit Q1 which modifies the volumes of S1 & S2 based on the combined ambient noise of the environment. In this instance A1 has been reduced to show S1 & S2 with lower volumes.

<FIG>: Is a schematic describing the way speakers are updated via the algorithm on a control device (Qbit). The Qbit detects and registers <NUM> one or more input devices (audio input, such as a microphone) which may be a peripheral device or embedded/built into the Qbit device and sends a request to the Qsic API (Application Programming Interface) <NUM> to get the configuration for the particular audio device that has been added to the system. The API returns the configuration for the input device and loads the configuration. The Qbit searches the local network for speakers that have been previously configured <NUM> using the calibration method described in <FIG> and sends further requests to the Qsic API <NUM> to retrieve the calibration details for each speaker. This calibration will contain enough information to describe the relevant relationship and so make up the graph or equation described in <FIG>. The Qbit will load the configuration and setup each speaker to be controlled via the identified algorithm <NUM>.

Staying on <FIG>, the process has now been initialised and the microphone is now actively sending a Digital Signal <NUM> to the Qbit which processes the digital signal as a stream of data <NUM> and saves it every x seconds, (where x may be any suitable number but is preferably a number in the range of <NUM> and <NUM>), which determines how often each speaker is updated with a new volume. For systems that need speakers to be updated more often a lower number should be favoured. <NUM> so it can take a recording of the signal over time (x) <NUM> and create an average which can then be converted to an RMS value <NUM>. With the RMS value the Qbit sends this to each sub-process <NUM> that is monitoring a speaker (such as a smart speaker) which in turn sends the volume adjustment instruction to the speaker to make an adjustment to its volume. As used herein, sub-process refers to a computer implemented task or routine or method which operates within a broader one. So in this example, it refers to a computer implemented method which monitors a predefined speaker by waiting for data relevant to the speaker to be transferred to it and responding accordingly (in this example, by sending an instruction relating to a volume adjustment to the speaker). <FIG>: is a schematic describing one example method for system calibration. Starting at <NUM> the system is set up when a room or venue has its lowest sound ambience - depending on the levels of outside noise, this may have to be in the middle of the night or another appropriate time. All speakers linked to the input device to be at their ideal volume <NUM> for when a room has little ambient sound, all speakers linked to the input device will have their minimum working range set to this volume. This minimum working range will mean the speaker cannot go below this volume, as seen in <FIG> - <NUM>. The microphone records the ambient sound in the room <NUM> for x seconds, and the input stream <NUM> is averaged to then work out the RMS over the set timeframe <NUM>. The number x can be any suitable value, typically it is in the range of <NUM> and <NUM>. It determines how often each speaker is updated with a new volume. For systems that need speakers to be updated more often a lower number should be favoured. For each speaker the Qbit saves the RMS against the volume of the speaker <NUM>. The ambient sound level is then increased for example by either waiting for more people to enter a venue or by simulating increasing ambience <NUM>. In some comparative, not claimed examples, an increase in ambient sound (for example in a series of steps) is machine generated as part of a pre-programed calibration sequence. Once the ambience has increased the process flow can start again from <NUM>. This process can repeat until a maximum ambience is reached, it has been found that in general it is preferable that a minimum of <NUM> data points are gathered to make a prediction using the polynomial equation described above. The more data points recorded the more accurate the prediction will be. Once a maximum ambience is reached all speakers linked to the input device will have their maximum working range set to this volume. This maximum working range will mean the speaker cannot go above this volume, as seen in <FIG> - <NUM>. With the minimum and maximum volumes configured we have a working range of figures for each speaker.

<FIG>: Is a graph showing an example resulting polynomial from the process described in <FIG>. This shows how the new volume (y-axis) <NUM> is selected against the inputs average power output as Root Mean Square (RMS) (x-axis) <NUM> and volume. In <FIG> we can see how <NUM> speakers S1 & S2 have been calibrated by the points <NUM> on the graph to make up a polynomial formula which describes a curve which fits the data values from the previous explained calibration procedure in <FIG>.

When a new RMS value is calculated on the Qbit, the Qbit uses that value to figure out what volume it should attempt to get for a particular speaker. For example referring to <FIG>, if the RMS of the input device was <NUM> then S2 would attempt to get as close to <NUM> as possible. S1 would try to get to <NUM>.

<FIG>: Is a schematic showing an example control device (referred to herein as Qbit) as the point of control. In this schematic F. <NUM> represents the internal workings/algorithm on the Qbit while outside this box represents physical hardware and communications / connections with it.

<FIG> shows the Qbit <NUM> as the control device receiving a digital signal <NUM> from an input device (such as a microphone or decibel reader) <NUM>. The signal may optionally be continuous or it may be periodic, for example set at a particular frequency. The Qbit <NUM>, stores this digital signal and after x seconds, (where x may be any suitable number but is preferably a number in the range of <NUM> and <NUM>), which determines how often each speaker is updated with a new volume. The Qbit <NUM> processes the digital signal <NUM> to produce a power variable, for example an averaged RMS over the period of time. The Qbit <NUM> after receiving the current volumes <NUM> of the speakers starts the process of comparing the power variable (here an averaged RMS) to the corresponding volume for each speaker <NUM> which has been configured using the process described in <FIG>. Once a new volume has been found for a speaker <NUM> based on the input, a volume adjustment <NUM> is sent to the speaker <NUM>.

<FIG> is an overview of an example process from the most top level and includes a flow of the decisions used to make adjustments to the speakers. <FIG> shows, starting at <NUM> the Qbit detects and registers <NUM> one or more input devices (such as a microphone) which may be a peripheral device or embedded/built into the Qbit and sends a request to the Qsic API (Application Programming Interface) <NUM> to obtain the configuration for the particular audio device that is attached, the API returns the configuration for the input device and the configuration is loaded onto the Qbit. The Qbit searches the local network for speakers (such as smart or intelligent speakers) that have been previously configured <NUM> using the calibration method described in <FIG> and sends further requests to the Qsic API <NUM> to retrieve the calibration details for each speaker. This calibration will contain enough information to identify the relevant relationship and make up the graph or equation described in <FIG>. The Qbit will load the configuration and setup each speaker to be controlled via the AVA algorithm <NUM>.

The process has now been initialised and the sub-process controlling the speaker on the Qbit is now receiving an RMS value <NUM> from the sub-process controlling the microphone input every x seconds, where x is a number in the range of <NUM> and <NUM>, which determines how often each speaker is updated with a new volume. For systems that need speakers to be updated more often a lower number should be favoured.

The Qbit looks up the ideal volume for each speaker based on the RMS input <NUM> using the equation that was set in <NUM> and obtains the speaker's current volume <NUM>.

The Qbit now has <NUM> variables stored for each speaker. An ideal volume, the current volume and the current RMS. The Qbit will process the speaker's current volume and ideal volume to identify whether any difference is larger than a preset maximum increment setting <NUM>. If it is larger, the Qbit saves the new volume as the current volume plus or minus (depending on if the new volume is higher or lower than the current volume) the maximum allowed increment for that speaker <NUM>. If the change is not larger than the maximum increment the Qbit either adds or subtracts the change from the current volume (depending on if the new volume is higher or lower than the current volume) to get the new volume for the speaker <NUM>.

The maximum increment may be set in any suitable manner. In some implementations, it is done manually by a user, for example based on the venue characteristics, and for example after or during the calibration process. In some comparative, not claimed examples, the maximum increment is computationally arrived at based on data processed at the venue/location of interest - for example data collected during a calibration process such as the one described herein.

For each speaker the Qbit holds a range that the speaker should operate in, which is defined by the maximum and minimum volume for each speaker during the configuration as per <FIG>. This is to stop the volume getting too loud or too soft. The Qbit checks to see if the new volume for the speaker is higher or lower than the configured minimum or maximum volume <NUM>. If the new ideal volume is higher or lower than the configured maximum/minimum then the Qbit sets the ideal volume to be equal to the configured maximum/minimum of the speaker <NUM>. If the new volume is not higher or lower than the speakers maximum/minimum configured volume then the Qbit sets the ideal volume to be the passed in ideal value <NUM>. The Qbit then sends the new ideal volume to the speaker to set its own volume <NUM>.

For example if a speaker had a minimum allowed volume of <NUM> and maximum allowed volume of <NUM>, its current volume was set to <NUM> the maximum increment was <NUM> and its ideal volume after running the RMS lookup <NUM> was <NUM>: <NUM> would return Yes as the new volume is larger than the maximum increment allowed. <NUM> would return <NUM> since the maximum increment is <NUM> and the current volume is set at <NUM>. <NUM> would return No since <NUM> is less than the speakers maximum allowed volume of <NUM>. <NUM> would pass <NUM> to <NUM> and the speaker would set its new volume to be <NUM>.

As a second example, if a speaker has a minimum allowed volume of <NUM> and a maximum allowed volume of <NUM>, its current volume was set to <NUM>, the maximum increment is <NUM> and its ideal volume after running the RMS lookup <NUM> is <NUM>: <NUM> would return No as the new volume is not larger than the maximum increment allowed. <NUM> would return would return <NUM> since the change in volume would only be is <NUM>. <NUM> would return No since the new volume (<NUM>) is lower maximum allowed volume (<NUM>). <NUM> would pass <NUM> to <NUM> and the speaker would set its new volume to be <NUM>.

<FIG> is a representation of a Microphone detecting a tonal/pitch change in the ambient noise and altering content on a digital service or screen. <FIG> shows a group of children A2, becoming the source of the majority of noise raising the tone/pitch/frequency input to microphone M1. M1 sends a digital signal to the Qbit Q1 which determines more children have entered the venue by analysing the attributes such as frequency, tone and pitch of the digital signal from M1. Q1 send this notification to the Qsic API QA1. Which notifies other digital services DS1 such as advertising, digital signage, etc. In some comparative, not claimed examples, the controller (such as a Qbit) is on site at the venue and can process such information without the need to communicate with the Qsic API. For example, the Qbit may identify one or more preset outputs based on the identified changes in attributes, such as frequency, tone and pitch, etc. Such an output may for example comprise a signal to a content controller to alter content which is played through one or more speakers, or displayed on one or more screens to match one or more characteristics of the altered audience A2. In some comparative, not claimed examples, the Qbit may further comprise a controller to control such content.

<FIG>: is a flowchart showing the flow/feedback loop for when AVA detects differences in attributes from the ambient noise, passing this detection to the Qsic API and onto subscribed services. <FIG> shows ambient sound <NUM> being sent as a digital signal <NUM> to the Qbit <NUM> which records the microphone input for x seconds <NUM>. The number 'x' may be of any suitable value, preferably it is a number in the range of <NUM> and <NUM> and determines the length of the sample of audio to analyse. A larger number will give a greater likelihood of detecting change, but will be less responsive, while a smaller number may pick up too many changes. This number will preferably be tested on a venue by venue basis before being implemented. The recording is saved <NUM> and an analysis is run on the recording <NUM> of x seconds to determine features of the audio clip from the tone/frequency/pitch etc. These features/attributes are compared to the previous recordings attribute's <NUM> if a large enough difference is not found in the attribute changes the process continues from <NUM>. If a large enough change in features/attributes for example <NUM>, the average frequency has gone up and we have detected more children in the analysed sound, the change is sent to the Qsic API <NUM> which alerts other digital services of this change. These could be Qsic internal services, <NUM> for example shows new content being queued and then sent to play in the store <NUM>. Where <NUM> shows an external service being notified and in turn changing the digital advertising in the store <NUM>. Again, in some comparative, not claimed examples, the Qbit may itself undertake these steps without the need to communicate with the Qsic API.

<FIG>: is a schematic showing the flow of AVA's learning from historic data to predict/recognise events. <FIG> shows ambient noise <NUM> being sent as a digital signal <NUM> to the Qbit <NUM> which records the microphone input for x seconds <NUM>. The number 'x' may be of any suitable value, preferably it is a number in the range of <NUM> and <NUM> and determines the length of the sample of audio to analyse. A larger number will give a greater likelihood of detecting change, but will be less responsive, while a smaller number may pick up too many changes. This number will preferably be tested on a venue by venue basis before being implemented. The recording is saved <NUM> and an analysis is run on the recording <NUM> of x seconds to determine features of the audio clip from the tone/frequency/pitch etc. These features/attributes are compared to previous recordings attribute's <NUM> if no similar attributes are found the process continues from <NUM>. If a set of features/attributes for example <NUM>, the same features/attributes as the same time yesterday, the change is sent to the Qsic API <NUM> which alerts other digital services of this change. These could be Qsic internal services, <NUM> for example shows new content being queued and then sent to play in the store <NUM>. Where <NUM> shows an external service being notified and in turn changing the digital advertising in the store <NUM>.

<FIG> is a representation of a microphone M1 detecting the direction of multiple points of noise with multiple speakers split across it to equally distribute volume to the audience in the room. M1 is responsible for collecting relevant noise and the noise's direction within the area defined by the radius encircled by circumference R1 which in turn controls the volumes of S1, S2 & S3. Noise collected from within R1 is processed as sound with a direction. In this example, M1, detects that more noise is coming from the direction of A3. And in turn raises the value of S2 with a higher intensity value to compensate for the greater amount of noise compared to S1 & S3.

Claim 1:
A method of managing a sound emitting device adapted to play an audio content comprising
detecting ambient sound at a microphone;
converting the ambient sound to a digital signal;
recording the digital signal for a period which is optionally <NUM> to <NUM> seconds;
storing data associated with the digital signal recorded during said period in a data store;
analysing the stored data to determine an average frequency of the ambient sound during said period;
comparing the determined average frequency to average frequency determined from a previous set of stored data to identify a difference;
identifying an input adjustment correlated with the identified difference; and
communicating the input adjustment to the sound emitting device to adjust audio content by replacing queued tracks with targeted demographic based content, in response to an overall increase or decrease in average frequency of the ambient sound during the period.