106, the dashboard application 110, and the audio processing application 114 can be executed using a single hardware system or device, or a plurality of distributed hardware systems or devices that are in communication with one another as needed. Moreover, FIG. 1 does not separately show a data communication network (or multiple networks) that support data communication within the system 100. In practice, the system 100 can utilize any number of tangible and/or wireless data communication networks if so desired.

FIG. 3 is a flow chart that illustrates a process 300 that relates to health monitoring of one or more targets of interest. The process 300 represents an exemplary embodiment of a method of indicating health, status, or condition of at least one monitored target. The various tasks performed in connection with the process 300 may be performed by software, hardware, firmware, or any combination thereof. For illustrative purposes, the following description of the process 300 may refer to elements mentioned above in connection with FIGS. 1 and 2. In practice, portions of the process 300 may be performed by different elements of the described system, e.g., one or more of the systems, services, components, or applications shown in FIG. 1. It should be appreciated that the process 300 may include any number of additional or alternative tasks, the tasks shown in FIG. 3 need not be performed in the illustrated order, and the process 300 may be incorporated into a more comprehensive procedure or process having additional functionality not described in detail herein. Moreover, one or more of the tasks shown in FIG. 3 could be omitted from an embodiment of the process 300 as long as the intended overall functionality remains intact.

The following description of the process 300 assumes that a plurality of targets are being monitored or observed, and that at least one dashboard system, service, or application (of the type described above) has been deployed. Accordingly, a dashboard application is maintained, operated, and updated in an appropriate manner (task 302). Although not always required, this example assumes that the plurality of monitored targets are of the same type, such as a plurality of clusters as depicted in FIG. 2. As further examples, the plurality of similar targets could be a fleet of monitored vehicles, a number of personal computers operating within an organization, or vital statistics for a group of monitored athletes. As mentioned above, the dashboard application is a graphical tool that can be used to monitor the health, status, or condition of the monitored targets in an ongoing manner. In connection with such monitoring, the process 300 obtains at least one metric associated with each monitored target (task 304), wherein the obtained metrics individually, collectively, or in any combination are indicative of the health of the targets.

The obtained metrics may include “raw” data, measurements, or values that quantify or are otherwise indicative of the health, status, or condition of the monitored targets. Moreover, task 304 may obtain, generate, or calculate at least one metric, based on one or more other obtained metrics. For example, task 304 may obtain a metric formatted as a numerical score that is derived or calculated from one or more other collected metrics for a monitored target. As described above with reference to the dashboard element 200, a numerical health score can be generated to quantify the health, status, or condition of each monitored target.

The process 300 may continue by analyzing the metrics to resolve and determine whether the health, status, or condition of each monitored target is within a normal range, a warning range, or an alerting range (task 306). Although this example considers three different ranges, an implementation may include only two ranges or more than three ranges. As described above, certain embodiments utilize a simple numerical score and numerically defined ranges to categorize the current health of the monitored targets. The current health range for a given target is used to determine a level of audio degradation to be applied to a source digital media file, for purposes of an audible health indicator. In accordance with this example, the process 300 analyzes the metrics (e.g., checks the health scores) to identify the worst-performing/unhealthiest target of the plurality of monitored targets (task 308). This allows a user to be notified of important status changes and to quickly focus on high priority action items.

The process 300 continues by determining the appropriate level of audio degradation to be applied to a source digital media file that conveys audio content (such as music), wherein the level of audio degradation is determined as a function of the obtained metric(s) and/or as a function of the health score that corresponds to the monitored target of interest (task 310). For this example, when the analyzing step resolves that the health, status, or condition of the monitored target is within the normal range, then little to no audio degradation is to be applied to the source digital media file. In contrast, when the analyzing step resolves that the health, status, or condition of the monitored target is within the alerting range, then a relatively high level of audio degradation is to be applied to the source digital media file, such that playback of the modified audio data results in a highly distorted, highly corrupted, or highly mutated version of the default audio content. If the analyzing step resolves that the health, status, or condition of the monitored target is within the warning range (that at least partially resides between the normal range and the alerting range), then a relatively low level of audio degradation is to be applied to the source digital media file, such that playback of the modified audio data results in a moderately distorted, moderately corrupted, or moderately mutated version of the default audio content.

In accordance with certain embodiments, the resolution of the change in audio degradation correlates directly to the delta of the range used. In this regard, a higher delta between minimum and maximum results in more gradual changes, and a lower delta results in more abrupt, or abrasive changes. For example, using a range of 0 to 1000 results in smoother or more continuous change, as compared to a range of 0 to 100.

If the process 300 determines that little to no audio degradation is to be used (the “No” branch of query task 312), then the audio portion of the source digital media file remains unmodified. As previously described, the source digital media file can be a digital music file that conveys music content, such that the modified audio data represents an audibly degraded version of the music content. Alternatively, the source digital media file can be a digital video file that conveys default audio content, such that the modified audio data represents an audibly degraded version of the default audio content. Thus, the process 300 controls playback of the unmodified audio data from the source digital media file 316 such that the “normal sounding” audio can serve as an audible indicator of normal health, status, or condition of the monitored target (task 314). In certain implementations that include a corresponding dashboard application, the process 300 may control or initiate the updating of the dashboard application in an ongoing manner and contemporaneously with controlling the playback of the unmodified audio data (task 318). For an implementation that monitors a plurality of similar targets, the playback of normal sounding, unmodified, undistorted, and non-degraded audio (e.g., music or a music playlist) means that all of the monitored targets are currently operating within the healthy or normal range. Consequently, a user listening to the source digital media file is provided with an audible indication that nothing needs immediate attention.

If, however, the process 300 determines that audio degradation is to be used (the “Yes” branch of query task 312), then at least the audio portion of the source digital media file 316 is modified in accordance with the determined level of audio degradation, resulting in modified audio data (task 320). The process 300 continues by controlling playback of the modified audio data such that the modified audio can serve as an audible indicator of abnormal or suspect health, status, or condition of the monitored target (task 322). In certain implementations that include a corresponding dashboard application, the process 300 may control or initiate the updating of the dashboard application in an ongoing manner and contemporaneously with controlling the playback of the modified audio data (task 324). For an implementation that monitors a plurality of similar targets, the playback of audibly distorted, degraded, or otherwise low quality audio (e.g., music or a music playlist) means that at least one of the monitored targets is currently operating within the alerting or warning health range. Consequently, a user listening to the modified audio file is provided with an audible indication that at least one monitored target needs immediate attention or should be closely watched. In response to this type of audible indication, the user can access the dashboard application, observe or select the suspect or unhealthy target, and view additional details regarding its current status.

Although the example described above uses three different health score ranges, an implementation of the system can support any number of different ranges. Moreover, the audio degradation methodology or algorithm can utilize a limited number of discrete levels of audio degradation or it can be relatively continuous, smooth, and dynamic, such that the level of audio degradation gradually increases in a manner that is proportional with worsening health of the monitored target.

Modification of the source audio data (at task 320) can be achieved using one or more audio manipulation, digital signal processing, or data processing techniques or technologies. Any one or a combination of available methodologies can be applied to the source audio data to audibly modify, degrade, corrupt, or distort the playback sound of the original audio information. In certain exemplary embodiments, the audio modification is achieved by bitcrushing the source digital media file to introduce quantization noise to the default audio content. Higher levels of bitcrushing result in more noise and worse perceived audio quality. Alternatively or additionally, the audio modification can be achieved by any of the following, alone or in any combination, without limitation: changing tone or pitch; fluctuating volume or source level gain of all, or a subset of, frequencies; altering playback speed; introducing audio dropouts; adding background noise; introducing audio frequency modulation (such as a “phaser” effect).

One or more parts of the above implementations may include software. Software is a general term whose meaning can range from part of the code and/or metadata of a single computer program to the entirety of multiple programs. A computer program (also referred to as a program) comprises code and optionally data. Code (sometimes referred to as computer program code or program code) comprises software instructions (also referred to as instructions). Instructions may be executed by hardware to perform operations. Executing software includes executing code, which includes executing instructions. The execution of a program to perform a task involves executing some or all of the instructions in that program.

An electronic device (also referred to as a device, computing device, computer, etc.) includes hardware and software. For example, an electronic device may include a set of one or more processors coupled to one or more machine-readable storage media (e.g., non-volatile memory such as magnetic disks, optical disks, read only memory (ROM), Flash memory, phase change memory, solid state drives (SSDs)) to store code and optionally data. For instance, an electronic device may include non-volatile memory (with slower read/write times) and volatile memory (e.g., dynamic random-access memory (DRAM), static random-access memory (SRAM)). Non-volatile memory persists code/data even when the electronic device is turned off or when power is otherwise removed, and the electronic device copies that part of the code that is to be executed by the set of processors of that electronic device from the non-volatile memory into the volatile memory of that electronic device during operation because volatile memory typically has faster read/write times. As another example, an electronic device may include a non-volatile memory (e.g., phase change memory) that persists code/data when the electronic device has power removed, and that has sufficiently fast read/write times such that, rather than copying the part of the code to be executed into volatile memory, the code/data may be provided directly to the set of processors (e.g., loaded into a cache of the set of processors). In other words, this non-volatile memory operates as both long term storage and main memory, and thus the electronic device may have no or only a small amount of volatile memory for main memory.

In addition to storing code and/or data on machine-readable storage media, typical electronic devices can transmit and/or receive code and/or data over one or more machine-readable transmission media (also called a carrier) (e.g., electrical, optical, radio, acoustical or other forms of propagated signals—such as carrier waves, and/or infrared signals). For instance, typical electronic devices also include a set of one or more physical network interface(s) to establish network connections (to transmit and/or receive code and/or data using propagated signals) with other electronic devices. Thus, an electronic device may store and transmit (internally and/or with other electronic devices over a network) code and/or data with one or more machine-readable media (also referred to as computer-readable media).

Software instructions (also referred to as instructions) are capable of causing (also referred to as operable to cause and configurable to cause) a set of processors to perform operations when the instructions are executed by the set of processors. The phrase “capable of causing” (and synonyms mentioned above) includes various scenarios (or combinations thereof), such as instructions that are always executed versus instructions that may be executed. For example, instructions may be executed: 1) only in certain situations when the larger program is executed (e.g., a condition is fulfilled in the larger program; an event occurs such as a software or hardware interrupt, user input (e.g., a keystroke, a mouse-click, a voice command); a message is published, etc.); or 2) when the instructions are called by another program or part thereof (whether or not executed in the same or a different process, thread, lightweight thread, etc.). These scenarios may or may not require that a larger program, of which the instructions are a part, be currently configured to use those instructions (e.g., may or may not require that a user enables a feature, the feature or instructions be unlocked or enabled, the larger program is configured using data and the program's inherent functionality, etc.). As shown by these exemplary scenarios, “capable of causing” (and synonyms mentioned above) does not require “causing” but the mere capability to cause. While the term “instructions” may be used to refer to the instructions that when executed cause the performance of the operations described herein, the term may or may not also refer to other instructions that a program may include. Thus, instructions, code, program, and software are capable of causing operations when executed, whether the operations are always performed or sometimes performed (e.g., in the scenarios described previously). The phrase “the instructions when executed” refers to at least the instructions that when executed cause the performance of the operations described herein but may or may not refer to the execution of the other instructions.

Electronic devices are designed for and/or used for a variety of purposes, and different terms may reflect those purposes (e.g., user devices, network devices). Some user devices are designed to mainly be operated as servers (sometimes referred to as server devices), while others are designed to mainly be operated as clients (sometimes referred to as client devices, client computing devices, client computers, or end user devices; examples of which include desktops, workstations, laptops, personal digital assistants, smartphones, wearables, augmented reality (AR) devices, virtual reality (VR) devices, mixed reality (MR) devices, etc.). The software executed to operate a user device (typically a server device) as a server may be referred to as server software or server code), while the software executed to operate a user device (typically a client device) as a client may be referred to as client software or client code. A server provides one or more services (also referred to as serves) to one or more clients.

The term “user” refers to an entity (e.g., an individual person) that uses an electronic device. Software and/or services may use credentials to distinguish different accounts associated with the same and/or different users. Users can have one or more roles, such as administrator, programmer/developer, and end user roles. As an administrator, a user typically uses electronic devices to administer them for other users, and thus an administrator often works directly and/or indirectly with server devices and client devices.

FIG. 4 is a simplified block diagram representation of an exemplary embodiment of an electronic device 400 according to some implementations. FIG. 4 includes hardware 420 including a set of one or more processor(s) 422, a set of one or more network interfaces 424 (wireless and/or wired), and machine-readable media 426 having stored therein software 428 (which includes instructions executable by the set of one or more processor(s) 422). The machine-readable media 426 may include non-transitory and/or transitory machine-readable media. Referring to FIG. 1, for example, a monitored target 102, the health evaluation application 106, the dashboard application 110, and the audio processing application 114 may be implemented in one or more electronic devices 400.

During operation, an instance of the software 428 (illustrated as instance 406 and referred to as a software instance; and in the more specific case of an application, as an application instance) is executed. In electronic devices that use compute virtualization, the set of one or more processor(s) 422 typically execute software to instantiate a virtualization layer 408 and one or more software container(s) 404A-404R (e.g., with operating system-level virtualization, the virtualization layer 408 may represent a container engine running on top of (or integrated into) an operating system, and it allows for the creation of multiple software containers 404A-404R (representing separate user space instances and also called virtualization engines, virtual private servers, or jails) that may each be used to execute a set of one or more applications; with full virtualization, the virtualization layer 408 represents a hypervisor (sometimes referred to as a virtual machine monitor (VMM)) or a hypervisor executing on top of a host operating system, and the software containers 404A-404R each represent a tightly isolated form of a software container called a virtual machine that is run by the hypervisor and may include a guest operating system; with para-virtualization, an operating system and/or application running with a virtual machine may be aware of the presence of virtualization for optimization purposes). Again, in electronic devices where compute virtualization is used, during operation, an instance of the software 428 is executed within the software container 404A on the virtualization layer 408. In electronic devices where compute virtualization is not used, the instance 406 on top of a host operating system is executed on the “bare metal” electronic device 400. The instantiation of the instance 406, as well as the virtualization layer 408 and software containers 404A-404R if implemented, are collectively referred to as software instance(s) 402.

Alternative implementations of an electronic device may have numerous variations from that described above. For example, customized hardware and/or accelerators might also be used in an electronic device.

FIG. 5 is a simplified block diagram representation of an exemplary embodiment of a deployment environment according to some implementations. A system 540 includes hardware (e.g., a set of one or more server devices) and software to provide service(s) 542, which may include the health evaluation service or application 106, the dashboard service or application 110, and/or the audio processing service or application 114. In some implementations the system 540 is in one or more datacenter(s). These datacenter(s) may be:1) first party datacenter(s), which are datacenter(s) owned and/or operated by the same entity that provides and/or operates some or all of the software that provides the service(s) 542; and/or 2) third-party datacenter(s), which are datacenter(s) owned and/or operated by one or more different entities than the entity that provides the service(s) 542 (e.g., the different entities may host some or all of the software provided and/or operated by the entity that provides the service(s) 542). For example, third-party datacenters may be owned and/or operated by entities providing public cloud services.

The system 540 is coupled to user devices 580A-580S over a network 582. The service(s) 542 may be on-demand services that are made available to one or more of the users 584A-584S working for one or more entities other than the entity which owns and/or operates the on-demand services (those users sometimes referred to as outside users) so that those entities need not be concerned with building and/or maintaining a system, but instead may make use of the service(s) 542 when needed (e.g., when needed by the users 584A-584S). The service(s) 542 may communicate with each other and/or with one or more of the user devices 580A-580S via one or more APIs (e.g., a REST API). In some implementations, the user devices 580A-580S are operated by users 584A-584S, and each may be operated as a client device and/or a server device. In some implementations, one or more of the user devices 580A-580S are separate ones of the electronic device 400 or include one or more features of the electronic device 400.

In some implementations, one or more of the service(s) 542 may use one or more multi-tenant databases 546, as well as system data storage 550 for system data 552 accessible to system 540. In certain implementations, the system 540 includes a set of one or more servers that are running on server electronic devices and that are configured to handle requests for any authorized user associated with any tenant (there is no server affinity for a user and/or tenant to a specific server). The user devices 580A-580S communicate with the server(s) of system 540 to request and update tenant-level data and system-level data hosted by system