GB2544042A

GB2544042A - Public address system control apparatus

Info

Publication number: GB2544042A
Application number: GB1519076.2A
Authority: GB
Inventors: Andrew Clegg Simon
Original assignee: Individual
Current assignee: Individual
Priority date: 2015-10-28
Filing date: 2015-10-28
Publication date: 2017-05-10
Also published as: GB201519076D0

Abstract

The apparatus (10) comprises an input module and an output module, the input module being configured to receive input data representative of a playlist comprising a plurality of items of audio content, wherein the apparatus (10) is configured to receive or assign respective time-related scheduling data and respective priority data associated with each item of audio content, and wherein the time-related scheduling data is determinative of an order in which said respective audio content items are to be output via said public address system (14). The output module is configured to provide the audio content items in this order to the public address system. The apparatus is further configured to identify at least first and second audio content items scheduled to be output at the same time, wherein the first audio content item has a priority higher than that of the second audio content item. The priority data associated with said first and second audio content items is compared and the first audio content item is output on the basis of having the higher priority.

Description

PUBLIC ADDRESS SYSTEM CONTROL APPARATUS

This invention relates generally to an apparatus and method for controlling the output of a public address (PA) system and, more particularly but not necessarily exclusively, to an automated or at least partially automated PA system that enables various types and formats of audio content to be scheduled and output whilst retaining the real-time versatility of a conventional PA system. PA systems are well known, and widely used in various venues and buildings where it may be required to address a large number of people simultaneously. A typical PA system is an electronic sound amplification and distribution system with a microphone, amplifier and loudspeakers, for example, to make announcements within large public venues such as railway stations or airports. Other such systems may include means of zone switching and an amplifier and loudspeakers suitable for music as well as speech, used to distribute audio content (music/speech) throughout a venue or building.

The simplest PA systems simply amplify and output any audio content in real-time, as it is input. Thus, for example, a user may simply speak an announcement into a microphone, and the audio content is amplified and substantially simultaneously output via the loudspeakers.

Partially automated PA systems also exist, whereby pre-programmed templates and announcement texts can be selected, generated and scheduled to be output as required. Thus, for example, such systems may be employed at railway stations to output a selected safety message at predetermined intervals, as well as allowing live announcements (or preprogrammed announcements triggered for output by a user action) to be made as required. Such systems can be automated to a greater or lesser extent, as defined by the system templates and application requirements.

However, as the level of automation in relation to such systems increases, the degree of user control and versatility decreases accordingly. Thus, if it is required to make or incorporate high priority or emergency announcements within a schedule, there may be an unacceptable delay before such announcements are output, as the system has no way of prioritising such messages. In other systems, where a schedule of announcements may be configured whereby messages are scheduled according to periodic time intervals, it is possible that two messages may be scheduled to be output at the same time, and conventional systems have no means of deciding which of those two messages should be output first. Still further, there is no facility in conventional PA systems to effectively schedule announcements that may be dependent on factors other than the time of day. Thus, for example, it may be required to incorporate a time-sensitive and unscheduled announcement. In conventional systems, such announcements would have to be made ‘live’, but that would necessitate someone remaining physically present at the microphone to make the required announcement and repeat it as required. In this case, in conventional systems, the activation of the ‘live’ microphone has the effect of muting any currently-playing announcement such that the live announcement can take precedence. However, this solution is inefficient and not always practical.

It is an object of aspects of the present invention to address at least some of these issues and, in accordance with a first aspect of the present invention, there is provided control apparatus for a public address system configured to distribute amplified audio content in an area, the apparatus comprising an input module and an output module, the input module being configured to receive input data representative of a play list comprising a plurality of items of audio content, wherein said apparatus is configured to receive or assign respective time-related scheduling data and respective priority data associated with each item of audio content, and wherein said time-related scheduling data is determinative of an order in which said respective audio content items are to be output via said public address system, said output module being configured to provide said audio content items in said order to said public address systems, and being further configured to: identify at least first and second audio content items scheduled to be output at the same time; compare the priority data associated with said first and second audio content items; and output the audio content having a higher priority to said public address system.

In one exemplary embodiment of the present invention, the audio content item having a lower priority may be dropped or aborted. Alternatively or in addition, the audio content item having a lower priority may be output after the audio content having a higher priority has been output to the public address system. Indeed, the priority data associated with said first or second audio content item may be configured to determine whether the audio content item having a lower priority is dropped/aborted or simply delayed.

In an exemplary embodiment of the invention, each audio content item may have one of a plurality of predefined priority values assigned thereto, wherein, optionally, a respective priority value is determinative of the action to be taken in respect of any audio content items having a lower priority relative thereto. The priority value may, for example, comprise a numerical value and, in one exemplary embodiment, the level of priority of an associated audio content item is defined by the numerical priority value, wherein, optionally, the lowest numerical value corresponds to the highest priority.

In an exemplary embodiment, each or a plurality of audio content items of said playlist may have one of a plurality of predefined priority values assigned thereto, said priority values being determinative of an order in which said respective audio content items are to be output relative to each other. A respective priority value may be determinative of the action to be taken in respect of any audio content items having a lower priority relative thereto. A priority value may comprise data representative of a numerical value.

In an exemplary embodiment, the input module may be configured to receive input data entered by a user, said input data comprising data representative of a new audio content item, time-related scheduling data and priority data, and wherein said output module is configured to receive said input data and insert said new audio content item into an existing playlist according to said time-related scheduling data and/or said priority data. The input module may, in this case, be configured to provide said user with an interface for entering said input data. The interface may include one or more selectable templates for creating an audio content item.

The priority data may be determinative of an order in which said respective audio content items are to be output and also one or more of a volume at which said audio content item is to be played, whether or not it should be played immediately upon receipt and an action to be taken in respect of an audio content item currently being played or next scheduled to be played.

The control apparatus may be communicably coupled to one or more servers on which one or more audio content items are stored, and from which said one or more audio content items are received by said control apparatus for output to said public address system.

In accordance with another aspect of the present invention, there is provided a public address system comprising an amplification and loudspeaker module, an interface and control apparatus substantially as described above communicably coupled to said amplification and loudspeaker module via said interface.

The input module of said control apparatus may be configured to receive input data from one or more mobile computing devices over a wireless or hard-wired communications network.

The control apparatus may be wirelessly connected to one or more virtual servers on which is/are stored one or more audio content items and from which said one or more audio content items are received by said control apparatus for output to said public address system.

These and other aspects of the present invention will be apparent from the following specific description, in which embodiments of the present invention are described, by way of examples only, and with reference to the accompanying drawing, in which:

Figure 1 is a schematic diagram illustrating a public address system coupled to apparatus according to an exemplary embodiment of the present invention.

Referring to Figure 1 of the drawings, a system according to an exemplary embodiment of the present invention comprises one or more audit server devices 10 including an input module for receiving input data from one or more input devices 12. Such input devices 12 may comprise one or more of a mobile device, such as a tablet, computer, PDA or mobile phone, a PC or indeed any other computing device that is communicably connected, wirelessly or otherwise, to the audio server device(s) 10. The audio server device 10 is communicably connected, via a suitable interface (not shown) to the input of a public address system 14, including an amplifier (not shown) and one or more loudspeakers 16 suitably located within an area. The audio server device(s) 10 is/are also communicably linked to a network of virtual servers or “the Cloud” 18, via a firewall and address translation module 20, although it will be appreciated that one or more physical servers could alternatively, or in addition, be used.

In general, an exemplary embodiment of the system provides a user interface and scheduling system for the public address system 14, whereby: 1. A user sends a request to the audit server device(s) 10 cause a message (or other audio content) to be played at a specified time and repeat a number of times; 2. The audio server device(s) 10 cause the public address system 14 to play the messages (or other audio content) at specified times; 3. Each time an audio server device causes a message to be played, the user is notified; 4. The user may be able to request, at any time, for a message to be stopped; and 5. The user can send an availability request to an audio server device to check it is available. All communication in this exemplary embodiment is via web services, optionally over HTTP port 80. Messages may use POST or GET verbs.

In use, and in more detail, announcements or messages to be played by the public address system can be input to the audio device(s) 10 by means of one or more of the input devices. For example, a message request may be entered including text defining the message to be played, and the interface presented to the user may also enable them to define a schedule for playing the message, and even define the zones or sections of the above mentioned area in which it is to be played. Thus, if the message is a bespoke announcement, it may be scheduled to first be played immediately (or at another predefined time) and then every defined number of minutes until a predefined time/date, or a predetermined number of times, or until a predetermined event occurs or even indefinitely until a user stops it. Furthermore, a whole set of predefined messages and/or other items of audio content may be pre-programmed and scheduled (in terms of timing and/or triggered by external events) in the form of a “playlist”. A so called “priority” value may also be assigned to each item of audio content, which priority value (or other data representative of a priority associated with the audio content) may be assigned by a user as they enter a message request or it may be assigned automatically according to the audio content type. Thus, for example, each item of audio content may be assigned a priority in the form of a numerical value between 1 and 10 with 1 representing a highest priority and 10 a lowest priority, although it will be appreciated that any number and/or format of priorities may be used for this purpose and the present invention is not necessarily intended to be limited in this regard.

Purely as an example, a message request may take the following form: { “Messageld” : “459e2a2d6ead40e685773df92d6fe9bl”, “AudioContent” : “base64imagehere”, “Priority” : 3, “Zones” : [ { “Terminalld” : 1, } ], “FirstPlay” : 1380106770, “LastPlay” : 1380106771, “RepeatCount” :-1, “Repeatlntemal” : 60000, “StartHour” : 6, “StartMin” : 0, “EndHour” : 8, “EndMin” : 0, “Days”: [0,1,2,3,4, 5,6], “Months”: [ 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11 ], “RetryCount” : 3, “Timeout” : 6000, “SuccessUrl” : “http://192.168.E50/success”, “FailureUrl” : “http://192.168.E50/failure” } wherein:

Messageld: This is the ID of the message as a 128bit GUID, generated by the client.

AudioContent: Base64 encoded audio file (the binary content itself).

Priority: The priority of the message, 1-10 with 1 as highest priority and 10 as lowest.

Zones: An array of zones that the message should be broadcast to. If zones are specified that the Microplay does not support - the Microplay should return failure immediately and not process the request.

FirstPlay: POSIX time for when the message should first be played. If set to the current time or in the past, the message should be played immediately.

LastPlay: POSIX time for when the message must stop, after this date has elapsed the message is considered ‘complete’ even if it hasn’t been played at all. A value of NULL signifies no end date, and the message will repeat for RepeatCount times.

RepeatCount: The number of time the message should be repeated. A value of- 1 means infinite repeats, 0 means no repeats, 1 means 1 repeat (so 2 plays in total), and so on

Repeatlnternal: The number of milliseconds to wait between repeat attempts. If RepeatCount is 0, this value is ignored regardless of what it may be set to.

StartHour: The hour each day to start playing.

StartMin: The minute of each day to start playing.

EndHour: The hour each day to stop playing.

EndMin: The minute of each day to stop playing.

Days: An array of days that the message should be played, with NULL representing ‘any’ day. The days use the following values:

Months: An array of months that the message should be played, with NULL representing ‘any’ month. The months use the following values:

RetryCount: The number of times to retry sending the message to the PA system 14 in case of failure. The audio server device(s) 10 will wait Timeout milliseconds for each attempt, and retry immediately until this count is reached.

Timeout: The maximum amount of time in milliseconds that the audio server device(s) 10 wait for the PA system to play the message. If the timeout expires, the message is considered a failure. If the RetryCount hasn’t been reached, the audio server device will immediately retry the message.

SuccessUrl: The URL to use for successful playbacks, see hereinafter.

FailureUrl: The URL to use for failed playbacks, see hereinafter.

The user interface may be configured to return an error immediately should there be an issues with a message.

It/they may also be optionally configured to generate a message that elaborates on the response code, or provides additional detail. e g. Possible Response Codes :

NoError = 0,

NoDatabase= 1,

ZoneOutofRange = 2,

PlayTimePassed = 3,

StopTimePassed = 4,

BadPriorityNumber = 5,

JsonParseError = 6,

DatabaseQueryError = 7,

AudioFileCreateError = 8,

AudioDecodeError = 9,

MissingContentLength = 10,

Priority2Error = 11

The audio server device(s) may be configured to generate a successful play notification comprising a message sent to the client who requested playback. Every time a message is played to any zone, this message may be sent to the client. If the message is sent to multiple zones simultaneously, such a message could be sent for each zone. { “Messageld” : “7C06B0B0-ADBC-44A2-AF02-29B19C849C05”, “Zones” : [ [ “Terminalld” : 6, “Zoneld” : 6, ], “DatePlayed” : 1379969817 }

Messageld: The ID originally provided in the initial request.

Zones: The zones the message was played to.

DatePlayed: POSIX time for when the message was physically played over the PA. Failure to play Notification

The audio server device(s) may be configured to generate a failure to play notification comprising a message sent to the client who requested playback. Every time a message fails to play to any zone, this message may be sent to the client. { “Messageld” : “7C06D0B0-ADBC-44A2-AF02-29B19C849C05”, “Zones” : [ { “Terminalld” : 6, “Zoneld” : 6 } ]. “DateAttempted” : 1379969817, “FailureCode” : 1, “FailureReason” : “Bad things happened”, “WillRetry” : false }

Messageld: The ID originally provided in the initial request Zones: The zones that could not be played to.

DateAttempted: POSIX time for when the message playback was attempted. FailureCode: Unique code for the exact failure.

FailureReason: Additional clarification on the failure code, including any additional relevant information.

WillRetry: Whether the Microplay will attempt to retry playback of the message. This will depend on the RetryCount value in the original request.

Possible Failure Codes

Unknown = 0,

Timeout = 1,

PaNotAvailable = 2

Should the user require that a message no longer be played, a step playback request is generated, that comprises a message sent to the audio server device(s) notifying them that they should no longer play the message and can consider it completed.

In response, the audio server device(s) may return a confirmatory message.

It will be appreciated that in addition to multiple message requests, of the type described above scheduled and prioritised appropriately, a pre-programmed playlist for the public address system 14 may also include other audio content, such as music, also appropriately prioritised and scheduled throughout a time period. The audio server device(s) may be entirely user programmable in this regard, and include the facility to enable additional message requests (or other audio content) to be added to the pre-programmed playlist and caused to be played (via the P)A system 14) according to the priority value assigned thereto.

In an exemplary embodiment of the invention, priorities of, say, 255 up to 1 (highest) may be selectable. But typically only 10 levels may be required for many applications.

In this exemplary embodiment, higher priority (lower numbers) messages/audio content are played ahead of lower ones, but the present invention is not necessarily intended to be limited in this regard.

Purely as an example, priority 1 and 2 level messages could be configured to cause any message playing to be aborted.

Consider the following illustrative examples: 1.1 LEVELS 1&2 1.1.1 Priority 1 Highest priority 1.1.1.1 Actions • Whatever message/music/feature is being played or about to play is TERMINATED. o All messages are terminated and the queue is cleared o The priority message is played o The volume is automatically increased by 10% for the message 1.1.2 Priority 2 Almost as high a priority as 1

Priority 2 is almost the same level as 1 except the messages in the queue are saved for later playing. 1.1.2.1 Actions • Whatever message/music/feature is being played or about to play is TERMINATED. o The message/music/feature is being played or about to play is pushed back into the queue. It will then be played later when its turn comes up. o The priority message is played. o The volume is automatically increased by 10% for the message. 1.2 LEVELS 3 &4

Generally used for ‘Free Text’ messages, created by Information staff.

Level 3 will move ahead of a level 4 message in the queue.

Last call messages may be given 4 or even 3. 1.3 LEVEL 5

Typically library messages are given priority 5 (midway). These are individually preset in the library setup, not user selectable. 1.4 LEVEL 6-10

No smoking messages etc. may be given numbers 6-10.

It will be appreciated by a person skilled in the art that the above examples are intended to be purely illustrative, and are not in any way intended to be construed as limiting. Priority values could, for example, have a format other than numerical. The order in which priorities are actioned, and their respective actions may also vary, and the present invention is not in any way intended do be limited in this regard.

In the case where an item of audio content is a message request, once created, the text may be passed through a profanity filter and, if required, a translation module before passing to a speech engine. The speech engine converts the message text into a corresponding digital speech file, after (optionally) cross-indexing with a lexicon function to check the language. Other items of audio content are also converted or accessed in the form of a digital sound file. This, a pre-programmed ‘playlist’ to cover a time period can be considered to be a collection of sound files each having associated therewith a schedule, priority value, and any other relevant data (e.g. volume, zones of area in which it is to be played, etc.). Each sound file, together with its additional data, may be ‘wrapped’ in a JSON (JavaScript Object Notation) object.

The JSON ‘packages’ are stored in the Cloud 18 and transferred to the audio server device(s) 10 to be played by the public address system 14. The audio server device(s) act(s) as an interface to the public address system, and is/are configured to unwrap each JSON package. It checks the message/content priority and queues the content accordingly. It may also check the required zones are free and, if the message can be played, it will go ahead for output to the public address system 14 at the appropriate time, to be played in the required zones and at the required volume.

As the audio server device 10 proceeds through the queue of audio content, it keeps the server(s) 18 (and the user) informed of progress by means of informative messages as set out above.

In the event that two items of audio content are scheduled to be played at exactly the same time, the audio server device(s) identify and select the content having the highest priority, and forward that to the public address system 14 to be played. Depending on its priority value, the other audio content will then either be dropped/aborted, or simply played after the higher priority content. Similarly, if a message or other audio content is required to be inserted into the playlist for immediate play, for example in the event of an emergency, a user can enter an appropriate message request in the manner described above and set the priority value to a high priority (1 or 2, say), such that the audio server device(s), upon receipt of the message, will abort any currently playing content, and immediately play the new message, in the required zones and at the required volume.

It will be appreciated by a person skilled in the art, from the foregoing description, that modifications and variations can be made to the described embodiments without departing from the scope of the invention as defined by the appended claims.

Claims

1. Control apparatus for a public address system configured to distribute amplified audio content in an area, the apparatus comprising an input module and an output module, the input module being configured to receive input data representative of a play list comprising a plurality of items of audio content, wherein said apparatus is configured to receive or assign respective time-related scheduling data and respective priority data associated with each item of audio content, and wherein said time-related scheduling data is determinative of an order in which said respective audio content items are to be output via said public address system, said output module being configured to provide said audio content items in said order to said public address systems, and being further configured to: identify at least first and second audio content items scheduled to be output at the same time, wherein said first audio content item has a priority higher than that of said second audio content item; compare the priority data associated with said first and second audio content items; and output said first audio content item on the basis of said higher priority.

2. Apparatus according to claim 1, configured to cause said second audio content item, having a lower priority, to be dropped or aborted.

3. Apparatus according to claim 1 or claim 2, configured to output said second audio content item, having said lower priority, after said first audio content item has been output.

4. Apparatus according to any of the preceding claims, configured to resume output of said playlist after said first and, optionally, said second audio content item has been output.

5. Apparatus according to claim 3 or claim 4, wherein the priority data associated with said first and/or second audio content items is determinative of whether the second audio content item is dropped/aborted or output after said first audio content item has been output.

6. Apparatus according to any of the preceding claims, wherein each or a plurality of audio content items of said playlist have one of a plurality of predefined priority values assigned thereto, said priority values being determinative of an order in which said respective audio content items are to be output relative to each other.

7. Apparatus according to claim 6, wherein a respective priority value is determinative of the action to be taken in respect of any audio content items having a lower priority relative thereto.

8. Apparatus according to claim 6 or claim 7, wherein a priority value comprises data representative of a numerical value.

9. Apparatus according to any of the preceding claims, wherein said input module is configured to receive input data entered by a user, said input data comprising data representative of a new audio content item, time-related scheduling data and priority data, and wherein said output module is configured to receive said input data and insert said new audio content item into an existing playlist according to said time-related scheduling data and/or said priority data.

10. Apparatus according to claim 9, wherein said input module is configured to provide said user with an interface for entering said input data.

11. Apparatus according to claim 10, wherein said interface includes one or more selectable templates for creating an audio content item.

12. Apparatus according to any of the preceding claims, wherein said priority data is determinative of an order in which said respective audio content items are to be output and also one or more of a volume at which said audio content item is to be played, whether or not it should be played immediately upon receipt and an action to be taken in respect of an audio content item currently being played or next scheduled to be played.

13. Apparatus according to any of the preceding claims, communicably coupled to one or more servers on which pone or more audio content items are stored, and from which said one or more audio content items are received by said control apparatus for output to said public address system.

14. Control apparatus in the form of one or more audio server device(s) substantially as herein described and/or with reference to the accompanying drawing.

15. A public address system comprising an amplification and loudspeaker module, an interface and control apparatus according to any of the preceding claims communicably coupled to said amplification and loudspeaker module via said interface.

16. A public address system according to claim 15, wherein said input module of said control apparatus is configured to receive input data from one or more mobile computing devices over a wireless or hard-wired communications network.

17. A public address system according to claim 15 or claim 16, wherein said control apparatus is wirelessly connected to one or more virtual servers on which is/are stored one or more audio content items and from which said one or more audio content items are received by said control apparatus for output to said public address system.

18. A public address system substantially as herein described and/or with reference to the accompanying drawings.