Patent Publication Number: US-11662973-B2

Title: Systems and methods for orchestrated audio session management for modern workspaces

Description:
FIELD 
     This disclosure relates generally to Information Handling Systems (IHSs), and, more specifically, to systems and methods for management of audio sessions by software clients operating on IHSs. 
     BACKGROUND 
     As the value and use of information continue to increase, individuals and businesses seek additional ways to process and store information. One option is an Information Handling System (IHS). An IHS generally processes, compiles, stores, and/or communicates information or data for business, personal, or other purposes. Because technology and information handling needs and requirements may vary between different applications, IHSs may also vary regarding what information is handled, how the information is handled, how much information is processed, stored, or communicated, and how quickly and efficiently the information may be processed, stored, or communicated. The variations in IHSs allow for IHSs to be general or configured for a specific user, or for a specific use such as financial transaction processing, airline reservations, enterprise data storage, global communications, etc. In addition, IHSs may include a variety of hardware and software components that may be configured to process, store, and communicate information and may include one or more computer systems, data storage systems, and networking systems. 
     IHSs provide users with capabilities for accessing, creating, and manipulating data. IHSs often implement a variety of security protocols in order to protect this data during such operations. A known technique for securing access to protected data that is accessed via an IHS is to segregate the protected data within an isolated software environment that operates on the IHS, where such isolated software environments may be referred to by various names, such as virtual machines, containers, dockers, etc. Various types of such segregated environments are isolated by providing varying degrees of abstraction from the underlying hardware and from the operating system of the IHS. These virtualized environments typically allow a user to access only data and applications that have been approved for use within that particular isolated environment. In enforcing the isolation of a virtualized environment, applications that operate within such isolated environments may have limited access to capabilities that are supported by the hardware and operating system of the IHS. In addition, each such isolated environment may operate without regard to other instances of such virtual environments that are operating on the same IHS, including without regard to resources that are in use by the other virtual environments operating in isolation on that same IHS. 
     SUMMARY 
     In various embodiments, methods are provided for audio session management for a plurality of workspaces operating on an Information Handling System (IHS). The methods may include: registering audio capabilities of the IHS with a workspace orchestration service that is remote from the IHS and manages deployment of the plurality of workspaces on the IHS; instantiating a first workspace according to a workspace definition provided by the workspace orchestration service; receiving, from the workspace orchestration service, a handle for operating audio capabilities of the IHS on behalf of the first workspace; determining an audio context based on the utilization of the plurality of workspaces operating on the IHS; utilizing the provided handle for modifying audio settings of the first workspace based on the audio context determined from the utilization of the plurality of workspaces; and utilizing the provided handle for operating the audio capabilities of the IHS based on user inputs to the plurality of workspaces. 
     In additional method embodiments, the handle further comprises a token specifying a duration of the validity of the handle for operation of the audio capabilities of the IHS by the first workspace. In additional method embodiments, the handle further comprises one or more conditions for evaluating the validity of the token. In additional method embodiments, the conditions comprise a minimum security score that must be maintained for the handle to remain valid, wherein the security score is determined based on the audio context in which the first workspace operations. In additional method embodiments, operation of the audio capabilities of the IHS are supported by a remote access controller of the IHS. In additional method embodiments, the operation of the audio capabilities of the IHS comprises removing audio from an audio stack maintained by an audio controller of the IHS. In additional method embodiments, the user inputs are made to the first workspace and the audio removed from the audio stack maintained by the audio controller correspond to audio outputs from a second workspace. In additional method embodiments, the first workspace cannot access the audio capabilities of the IHS directly due to isolation of the first workspace from the portion of the hardware and software of the IHS. In additional method embodiments, the operation of the audio capabilities of the IHS comprises adjusting a privacy mode in order to accept inputs to a microphone of the IHS. 
     In various additional embodiments, Information Handling Systems (IHSs) support audio session management for a plurality of workspaces operating on the IHS. The IHSs may include an embedded controller comprising a logic unit and a memory storing program instructions that, upon execution by the logic unit, cause the embedded controller to register audio capabilities of the IHS with a workspace orchestration service that is remote from the IHS and manages deployment of the plurality workspaces on the IHS. The IHSs may also include one or more processors and a memory coupled to the processors, the memory storing program instructions that, upon execution by the processors, cause the IHS to: instantiate a first workspace according to a workspace definition provided by the workspace orchestration service; receive, from the workspace orchestration service, a handle for operating audio capabilities of the IHS on behalf of the first workspace; determine an audio context based on the utilization of the plurality of workspaces operating on the IHS; utilize the provided handle for modifying audio settings of the first workspace based on the audio context determined from the utilization of the plurality of workspaces; and utilize the provided handle for operating the audio capabilities of the IHS based on user inputs to the plurality of workspaces. 
     In additional IHS embodiments, the handle further comprises a token specifying a duration of the validity of the handle for operation of the audio capabilities of the IHS by the first workspace. In additional IHS embodiments, the token is generated by the workspace orchestration service based on a unique identifier of the IHS and based a unique identifier of the first workspace. In additional IHS embodiments, the operation of the audio capabilities of the IHS comprises removing audio from an audio stack maintained by an audio controller of the IHS. In additional IHS embodiments, the user inputs are made to the first workspace and the audio removed from the audio stack maintained by the audio controller correspond to audio outputs from a second workspace. In additional IHS embodiments, the operation of the audio capabilities of the IHS comprises adjusting a privacy mode in order to accept inputs to a microphone of the IHS. 
     In various additional embodiments, systems support audio session management for a plurality of workspaces operating on an Information Handling System (IHS). The systems may include a workspace orchestration service that is remote from the IHS and that manages deployment of workspaces on the IHS. The systems may also include the IHS, that may include: an embedded controller comprising a logic unit and a memory storing program instructions that, upon execution by the logic unit, cause the embedded controller to: register audio capabilities of the IHS for use by the plurality of workspaces with the workspace orchestration service; a processor; and a memory coupled to the processor, the memory storing program instructions that, upon execution by the processor, cause the IHS to: instantiate a first workspace according to a workspace definition provided by the workspace orchestration service; receive, from the workspace orchestration service, a handle for operating audio capabilities of the IHS on behalf of the first workspace; determine an audio context based on the utilization of the plurality of workspaces operating on the IHS; utilize the provided handle for modifying audio settings of the first workspace based on the audio context determined from the utilization of the plurality of workspaces; and utilize the provided handle for operating the audio capabilities of the IHS based on user inputs to the plurality of workspaces. 
     In additional system embodiments, the handle further comprises a token specifying a duration of the validity of the handle for operation of the audio capabilities of the IHS by the first workspace. In additional system embodiments, the operation of the audio capabilities of the IHS comprises removing audio from an audio stack maintained by an audio controller of the IHS. In additional system embodiments, the user inputs are made to the first workspace and the audio removed from the audio stack maintained by the audio controller correspond to audio outputs from a second workspace. In additional system embodiments, the operation of the audio capabilities of the IHS comprises adjusting a privacy mode in order to accept inputs to a microphone of the IHS. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The present invention(s) is/are illustrated by way of example and is/are not limited by the accompanying figures, in which like references indicate similar elements. Elements in the figures are illustrated for simplicity and clarity and have not necessarily been drawn to scale. 
         FIG.  1    is a diagram illustrating certain components of an IHS operable, according to some embodiments, to support orchestrated audio session management for workspaces operating on the IHS. 
         FIG.  2    is a diagram depicting illustrative embodiments of methods and system for deployment and management of workspaces on an IHS in a manner that supports orchestrated audio session management for workspaces operating on the IHS. 
         FIGS.  3 A and  3 B  are a diagram depicting an illustrative system configured according to embodiments for deployment and management of workspaces on an IHS in a manner that supports orchestrated audio session management for workspaces operating on the IHS. 
         FIG.  4    is a swim lane diagram describing the operation of certain components of a system, according to some embodiments, in configuring orchestrated audio session management for workspaces operating on an IHS. 
     
    
    
     DETAILED DESCRIPTION 
     For purposes of this disclosure, an IHS may include any instrumentality or aggregate of instrumentalities operable to compute, calculate, determine, classify, process, transmit, receive, retrieve, originate, switch, store, display, communicate, manifest, detect, record, reproduce, handle, or utilize any form of information, intelligence, or data for business, scientific, control, or other purposes. For example, an IHS may be a personal computer (e.g., desktop or laptop), tablet computer, mobile device (e.g., Personal Digital Assistant (PDA) or smart phone), server (e.g., blade server or rack server), a network storage device, or any other suitable device and may vary in size, shape, performance, functionality, and price. An example of an IHS is described in more detail below.  FIG.  1    shows various internal components of an IHS configured to implement certain of the described embodiments. It should be appreciated that although certain embodiments described herein may be discussed in the context of a personal computing device, other embodiments may utilize various other types of IHSs. 
       FIG.  1    is a diagram depicting certain components of an illustrative IHS  100  that is operable according to various embodiments for orchestrated audio session management for workspaces operating on the IHS  100 . In some embodiments, IHS  100  may be employed to instantiate, manage, and/or terminate a secure workspace that may provide the user of IHS  100  with access to protected data in an isolated software environment in which the protected data is segregated from: the operating system (OS) of the IHS  100 , other applications executed by IHS  100 , other workspaces operating on IHS  100  and, to a certain extent, the hardware of the IHS. In some embodiments, the construction of a workspace for a particular purpose and for use in a particular context may be orchestrated remotely from the IHS  100  by a workspace orchestration service, such as described with regard to  FIG.  2   . In some embodiments, portions of the workspace orchestration may be performed locally on IHS  100 . IHS  100  may be configured with program instructions that, upon execution, cause IHS  100  to perform one or more of the various operations disclosed herein. In some embodiments, IHS  100  may be an element of a larger enterprise system that may include any number of similarly configured IHSs in network communications with each other. 
     As shown in  FIG.  1   , IHS  100  includes one or more processors  101 , such as a Central Processing Unit (CPU), that execute code retrieved from a system memory  105 . Although IHS  100  is illustrated with a single processor  101 , other embodiments may include two or more processors, that may each be configured identically, or that may be configured to support specialized processing functions. Processor  101  may include any processor capable of executing program instructions, such as an Intel Pentium™ series processor or any general-purpose or embedded processors implementing any of a variety of Instruction Set Architectures (ISAs). In the embodiment of  FIG.  1   , the processor  101  includes an integrated memory controller  118  that may be implemented directly within the circuitry of the processor  101 , or the memory controller  118  may be a separate integrated circuit that is located on the same die as the processor  101 . The memory controller  118  may be configured to manage the transfer of data to and from the system memory  105  of the IHS  100  via a high-speed memory interface  105   b.    
     System memory  105  that is coupled to processor(s)  101  via memory bus  105   b  provides processor(s)  101  with a high-speed memory that may be used in the execution of computer program instructions by processor(s)  101 . Accordingly, system memory  105  may include memory components, such as such as static RAM (SRAM), dynamic RAM (DRAM), NAND Flash memory, suitable for supporting high-speed memory operations by processor(s)  101 . In some embodiments, system memory  105  may combine both persistent, non-volatile memory and volatile memory. In certain embodiments, system memory  105  includes secure storage  120  that may be a portion of the system memory designated for storage of information, such as access policies, component signatures, encryption keys, and other cryptographic information, for use in hosting a secure workspace on IHS  100 . In such embodiments, a signature may be calculated based on the contents of secure storage  120  and stored as a reference signature. The integrity of the data stored in secure storage  120  may then be validated at a later time by recalculating this signature of the contents of the secure storage and comparing the recalculated signature against the reference signature. 
     IHS  100  utilizes chipset  103  that may include one or more integrated circuits that are coupled to processor(s)  101 . In the embodiment of  FIG.  1   , processor(s)  101  is depicted as a set of busses that couple processor  101  to various hardware components installed in the same motherboard. In some embodiments, all or portions of chipset  103  may be implemented directly within the integrated circuitry of processor(s)  101 . Chipset  103  thus provides processor(s)  101  with access to a variety of hardware resources. In IHS  100 , chipset  103  is illustrated as a single coupling with processor  101 . However, other implementations may utilize any number of connections to provide the illustrated communication pathways supported by chipset  103 . In some instances, capabilities supported by processor  101  are not directly available to workspaces operating on IHS  100  due to the isolation of these workspaces from certain hardware and software of the IHS. 
     In certain embodiments, IHS  100  may include a SPI (Serial Peripheral Interface) flash device  175  that stores certain data and instructions utilized by processor  101 . The SPI flash  175  may be a non-volatile memory device capable of being electrically erased and reprogrammed. SPI flash  175  may be coupled to processor  101  over an SPI bus  180  that supports transfers of blocks of data to and from SPI flash  175 . In some embodiments, SPI flash  175  may be divided into various regions, with each region storing different types of instructions and/or data. In certain embodiments, some of the regions of SPI flash  175  may be provisioned during trusted manufacture of IHS  100 , such as with boot code, cryptographic keys, firmware reference signatures, and tokens that are used to implement security protocols utilized by IHS  100 . 
     As illustrated, processor(s)  101  may also be coupled to a network controller  125 , such as provided by a Network Interface Controller (NIC) that is coupled to the IHS  100  and allows the IHS  100  to communicate with other systems, such as other IHSs similarly configured to IHS  100 , via an external network, such as the Internet or a LAN. Network interface device  109  may provide IHS  100  with wired and/or wireless network connections via a variety of network technologies, such as wireless cellular or mobile networks (CDMA, TDMA, LTE etc.), WIFI and BLUETOOTH. In some embodiments, network controller  125  may be instrumented with a controller or other logic unit that supports a sideband management connection  185   b  with remote access controller  155 . In some instances, capabilities supported by network controller  125  are not directly available to workspaces operating on IHS  100  due to the isolation of these workspaces from certain hardware and software of the IHS. 
     Chipset  103  may also support communications with one or more display device(s)  115  via graphics processor  170 . In certain embodiments, graphics processor  170  may be comprised within one or more video or graphics cards or an embedded controller installed as components of the IHS  100 . Graphics processor  170  may generate display information and provide the generated information to one or more display device(s)  115  coupled to IHS  100 , where display device(s)  115  may include integrated display devices and/or external display devices coupled to IHS. In certain embodiments, some or all of the functions supported by graphics processor  170  may be integrated within processor  101 . The one or more display devices  115  coupled to IHS  100  may utilize LCD, LED, OLED, or other thin film display technologies. Each display device  115  may be capable of touch input such as via a touch controller that may be a component of display device  115 , graphics processor  170 , or a separate component of IHS  100  accessed via bus  103 . In some instances, capabilities supported by graphics processor  170  are not directly available to workspaces operating on IHS  100  due to the isolation of these workspaces from certain hardware and software of the IHS. 
     In certain embodiments, chipset  103  may utilize one or more I/O controllers  150  to access various I/O hardware components such as user input devices and sensors. For instance, I/O controllers  150  may provide access to user-input devices such as a keyboard, mouse, touchpad, touchscreen and/or other peripheral input devices. User input devices may interface with a I/O controller  150  through wired or wireless connections. Sensors accessed via I/O controllers  150  may provide access to data describing environmental and operating conditions of IHS  100  (e.g., accelerometers, gyroscopes, hinge sensors, rotation sensors, hall effect sensors, temperature sensors, voltage sensors, current sensors, IR sensors, photosensors, proximity sensors, distance sensors, magnetic sensors, microphones, ultrasonic sensors, etc.). In some instances, sensor capabilities supported are not directly available to workspaces operating on IHS  100  due to the isolation of these workspaces from certain hardware and software of the IHS. 
     As illustrated, types of I/O controller  150  of an IHS  100  may include one or more audio controllers  140  that support various audio capabilities. In various embodiments, audio controllers  140  may include one or more dedicated hardware components such as a microcontroller or a DSP (digital signal processor), a system-on-chip implemented by processor  101  or another logic unit of IHS  100  and/or software components implemented by the operating system of IHS  100 . Audio controllers  140  support capabilities to play, detect, record, analyze and/or store audio data. Accordingly, audio controllers  140  may interface with internal and external speaker systems, microphones, headsets and various other audio devices that may be coupled to IHS  100  via wired or wireless couplings. In some embodiments, audio controller  140  may include support for various codecs for use in decompressing audio data for playback and in compressing recorded audio for storage. In some embodiments, audio controller  140  may also include codec capabilities for converting between digital and analog audio signals. Audio controller  140  may also include one or more buffer memories configured for temporary storage of audio data. Audio controller  140  may also support various controls for configuring audio inputs and outputs by IHS  100 . In some embodiments, an audio controller  140  may buffer audio data for playback and recording in an audio stack. In such embodiments, audio data on the audio stack may be identified according to a process of the IHS to which it corresponds. As described in additional detail below, embodiments support capabilities for managing workspace audio sessions by identifying and manipulating audio data on the audio stack that corresponds to specific workspaces operating on the IHS. These various capabilities supported audio controller  140  are not directly available to workspaces operating on IHS  100  due to the isolation of these workspaces from certain hardware and software of the IHS. 
     In some embodiments, the data inputs collected by such sensors may be received by sensor hub capable of utilizing this information in determining various physical characteristics of the location and manner in which IHS  100  is being utilized. For instance, the sensor hub may utilize inertial movement sensors, that may include accelerometer, gyroscope, and magnetometer sensors, and are capable of determining the current orientation and movement of IHS  100  (e.g., IHS  100  is motionless on a relatively flat surface, IHS  100  is being moved irregularly and is likely in transport, the hinge of IHS  100  is oriented in a vertical direction). In certain embodiments, the sensor hub may also include capabilities for determining a location and movement of IHS  100  based on triangulation of network signal and based on network information provided by the OS or by a network interface. In some embodiments, the sensor hub may support additional sensors, such as optical, infrared and sonar sensors, that may provide support for xR (virtual, augmented, and/or mixed reality) sessions hosted by the IHS  100  and may be used by the sensor hub provide an indication of a user&#39;s presence near IHS  100 , such as whether a user is present, absent, and/or facing the integrated display  115 . 
     Chipset  103  also provides processor(s)  101  with access to one or more storage devices  130 . In various embodiments, a storage device  130  may be integral to the IHS  100 , or may be external to the IHS  100 . In certain embodiments, storage device  130  may be accessed via a storage controller that may be an integrated component of the storage device. Storage device  130  may be implemented using any memory technology allowing IHS  100  to store and retrieve data. For instance, storage device  130  may be a magnetic hard disk storage drive or a solid-state storage drive. In some embodiments, storage device  130  may be a system of storage devices, such as a cloud drive accessible via network controller  125 . In some embodiments, storage device  130  may be instrumented with a controller or other logic unit that supports a sideband management connection  185   d  with remote access controller  155 . In some instances, data storage capabilities supported by storage devices  130  are not directly available to workspaces operating on IHS  100  due to the isolation of these workspaces from certain hardware and software of the IHS. 
     IHS  100  may also include a BIOS (Basic Input/Output System)  135  component that may include instructions stored in a non-volatile memory that may be accessible by processor  101 . The BIOS  135  provides an abstraction layer that allows an operating system of the IHS  100  to interface with the hardware components of the IHS  100 . Accordingly, BIOS  135  provides an abstraction layer to the firmware utilized by various hardware components of IHS  100 . In some embodiments, BIOS  135  may be implemented using a dedicated microcontroller coupled to the motherboard of IHS  100 . In some embodiments, some or all of BIOS  135  may be implemented as operations of an embedded controller, such remote access controller  155 . Upon powering or restarting IHS  100 , processor(s)  101  may utilize BIOS  135  to initialize and test various hardware components of the IHS  100 . Upon successful validation of these hardware components, in some embodiments, BIOS  135  may also initiate loading of an operating system for use by the IHS  100 . As illustrated, BIOS  135  may be instrumented with a controller or other logic unit that supports a sideband management connection  185   c  with remote access controller  155 . In certain embodiments, this sideband management connection  185   c  may be utilized by remote access controller  155  to identify communication capabilities that are supported by IHS  100  and that may be used in support of secure communications by workspaces operating on IHS  100 . 
     As illustrated, IHS  100  may also include a power supply unit  160  that provides the hardware components of IHS  100  with appropriate levels of DC power. Power inputs received via a power port or via USB ports may be routed to the power supply unit  160  of IHS  100 . The power inputs received by power supply unit  160  may be used in powering the operations of IHS  100  and in recharging internal batteries of IHS  100 . In some embodiments, power supply unit  160  may support power outputs drawn from the internal batteries of IHS  100  and provided to external devices coupled to IHS  100 , such as USB devices coupled to USB ports of IHS  100 . In some embodiments, power supply unit  160  may provide power to components of IHS  100  using multiple independent power planes. For instance, as described below, remote access controller  155  may be powered from a separate power plane from processor  101 . 
     As illustrated, IHS  100  includes a remote access controller (RAC)  155  that provides capabilities for remote monitoring and management of various aspects of the operation of IHS  100 . In support of these monitoring and management functions, remote access controller  155  may utilize both in-band and sideband (i.e., out-of-band) communications with various internal components of IHS  100 . Remote access controller  155  may be installed on the motherboard of IHS  100  or may be coupled to IHS  100  via an expansion slot provided by the motherboard. As a non-limiting example of a remote access controller, the integrated Dell Remote Access Controller (iDRAC) from Dell® is embedded within Dell PowerEdge™ servers and provides functionality that helps information technology (IT) administrators deploy, update, monitor, and maintain servers remotely. 
     In some embodiments, remote access controller  155  may operate from a different power plane from processors  101 , storage devices  130 , network controller  125  and various other components of IHS  100 , thus allowing the remote access controller  155  to operate, and management tasks to proceed, while the processing cores of IHS  100  are powered off. In some embodiments, various BIOS functions, including launching the operating system of the IHS  100 , may be implemented by the remote access controller  155 . In some embodiments, the remote access controller  155  may perform various functions to verify the integrity of the IHS  100  and its hardware components prior to initialization of the IHS  100  (i.e., in a bare-metal state). 
     In some embodiments, remote access controller  155  may support monitoring and administration of various managed devices  101 ,  120 ,  125 ,  130 ,  135  of an IHS via a sideband bus interface. For instance, messages utilized in device management may be transmitted using I2C sideband bus connections  185   a - e  that may be individually established with each of the respective managed devices  101 ,  120 ,  125 ,  130 ,  135  through the operation of an I2C multiplexer  155   a  of the remote access controller. As illustrated, managed devices  125 ,  130 ,  135  of IHS  100  are coupled to the IHS processor(s)  101  via one or more in-band buses supported by chipset  103 , where these in-band busses are separate from the I2C sideband bus connections  185   b - d  used for device management. Accordingly, managed devices  125 ,  130  and  135  communicate with the operating system of IHS  100  via in-band buses supported by chipset  103 , while the sideband buses  185   b - d  are used by managed devices exclusively for communications with remote access controller  155 . 
     In certain embodiments, a service processor  155   d  of remote access controller  155  may rely on an I2C co-processor  155   c  to implement sideband I2C communications between the remote access controller  155  and managed components  101 ,  120 ,  125 ,  130 ,  135  of the IHS. The I2C co-processor  155   c  may be a specialized co-processor or micro-controller that is configured to interface via a sideband I2C bus interface with the managed hardware components  101 ,  120 ,  125 ,  130 ,  135  of IHS. In some embodiments, the I2C co-processor  155   c  may be an integrated component of the service processor  155   d , such as a peripheral system-on-chip feature that may be provided by the service processor  155   d . Each I2C bus  185   a - e  is illustrated as single line in  FIG.  1   . However, each I2C bus  185   a - e  may be comprised of a clock line and data line that couple the remote access controller  155  to I2C endpoints  101 ,  120 ,  125 ,  130 ,  135  on each of the managed components. 
     As illustrated, the I2C co-processor  155   c  may interface with the individual managed devices  101 ,  120 ,  125 ,  130 ,  135  via individual sideband I2C buses  185   a - e  selected through the operation of an I2C multiplexer  155   a . Via switching operations by the I2C multiplexer  155   a , a sideband bus connection  185   a - e  may be established through a direct coupling between the I2C co-processor  155   c  and each of the individual managed devices  101 ,  120 ,  125 ,  130 ,  135 . In providing sideband management capabilities, the I2C co-processor  155   c  may interoperate with corresponding endpoint I2C controllers that implement the I2C communications of the respective managed devices  101 ,  120 ,  125 ,  130 ,  135 . The endpoint I2C controllers may be implemented as dedicated microcontrollers for communicating sideband I2C messages with the remote access controller  155 , or endpoint I2C controllers may be integrated SoC functions of a processor of the respective managed device endpoints  101 ,  120 ,  125 ,  130 ,  135 . 
     In some embodiments, remote access controller  155  may perform various operations in support of the delivery and deployment of workspaces to IHS  100 . In certain embodiments, remote access controller  155  may interoperate with a remote orchestration service via the described out-of-band communications pathways that are isolated from the operating system that runs on IHS  100 . In some embodiments, a network adapter  155   b  that is distinct from network controller  125  utilized by the operating system of IHS  100  may support such out-of-band communications between remote access controller  155  and a remote orchestration service. Via this out-of-band signaling pathway, remote access controller  155  may receive authorization information that may be used for secure delivery and deployment of a workspace to IHS  100  and to support secure communication channels between deployed workspaces and various capabilities supported by IHS  100 , while still maintaining isolation of the workspaces from the hardware and operating system of IHs  100 . 
     In some embodiments, authorization and cryptographic information received by remote access controller  155  from a remote orchestration service may be stored to secured memory  120 . As illustrated in  FIG.  1   , in some embodiments, remote access controller  155  may access secured memory  120  may via an I2C sideband signaling pathway  185   a  between I2C multiplexer  155   a  and an I2C communication capability supported by secure memory  120 . Remote access controller  155  may support execution of a trusted operating environment that supports secure operations that are used to deploy a workspace on IHS  100 . In certain embodiments, remote access controller  155  may calculate signatures that uniquely identify various hardware and software components of IHS  100 . For instance, remote access controller  155  may calculate hash values based on instructions and other information used to configure and operate hardware and/or software components of IHS  100 . For instance, remote access controller  155  may calculate a hash value based on firmware and on other instructions or settings of a component of a hardware component. In some embodiments, hash values may be calculated in this manner as part of a trusted manufacturing process of IHS  100  and may be stored in the secure storage  120  as reference signatures used to validate the integrity of these components at a later time. In certain embodiments, a remote orchestration service supporting the deployment of workspaces to IHS  100  may verify the integrity of the remote access controller  155  in a similar manner, by calculating a signature of remote access controller  155  and comparing it to a reference signature calculated during a trusted process for manufacture of IHS  100 . 
     In some embodiments, an IHS  100  may not include all of the components shown in  FIG.  1   . In other embodiments, an IHS  100  may include other components in addition to those that are shown in  FIG.  1   . Furthermore, some components that are represented as separate components in  FIG.  1    may instead be integrated with other components. For example, in certain embodiments, all or a portion of the operations executed by the illustrated components may instead be provided by components integrated into processor(s)  101  as systems-on-a-chip. 
       FIG.  2    is a diagram depicting illustrative embodiments of methods and system for deployment and management of workspaces on an IHS in a manner that supports orchestrated audio session management for workspaces operating on the IHS. For sake of explanation, the workspace lifecycle supported by embodiments has been split into three phases: workspace initialization phase  200 A, workspace orchestration phase  200 B, and workspace termination phase  200 C. During initialization  200 A, user  201  operates an IHS  100 , such as described with regard to  FIG.  1   , within a physical environment  202  (e.g., any type of environment and its associated context, including physical location, geographic location, location within a particular facility or building, detected networks, time of day, proximity of the user, individuals in the vicinity of IHS  100 , etc.). 
     The illustrated method for the workspace lifecycle according to embodiments may be initiated with an action by user  201  at a user interface that serves as a launch point  203  for initiating a workspace. In various instances, launch point  203  may be a corporate launch point provided by an employer of user  201 , a manufacturer launch point provided by the manufacturer of IHS  100 , or a third-party launch point provided as a service to user  201  by a third-party. In various instances, user  201  may operate IHS  100  to access a launch point  203  that is provided in the form of a web portal, a portal application running in the operating system of IHS  100 , or a special-purpose portal workspace operating on IHS  100 . In various embodiments, launch point  203  may be implemented using graphical, textual and/or audio interfaces by which data or other resource may be requested by a user  201 . In various implementations, launch point  203  may include Graphical User Interface (GUI) elements, such as icons, that represent different software applications, data sources and/or other resources that the user may select for use via a workspace. As such, launch point  203  may provide a user with an ability to request initiation of a workspace that process access to software applications and data sources that are available to the user  201 . 
     As described in additional detail below, workspaces for providing user  201  with access to protected data or other resources may operate using a local management agent  332  that operates on IHS  100  and is configured to interoperate with workspace orchestration service  206 . As described, launch point  203  may be provided in the form of a portal (e.g., a webpage, OS application or special purpose workspace) that includes a user interface that allows user  201  to request access to managed resources. In some embodiments, launch point  203  may be hosted by the local management agent  332  that runs on IHS  100  and interoperates with remote workspace orchestration service  206 . Examples of launch point  203  technologies may include WORKSPACE ONE INTELLIGENT HUB from WMWARE, INC., and DELL HYBRID CLIENT from DELL TECHNOLOGIES INC., among others. 
     Initialization phase  200 A begins when user  201  chooses to launch an application or access a data source that is managed by the workspace orchestration service  206 . In response to an access request issued by user  201  (e.g., the user “clicks” on an icon presented by launch point  203 ), at  204 , local management agent  332  of IHS  100  collects initial security context information and productivity context information. In various embodiments, the security context information of a workspace may include attributes indicating a security risk associated with: the data and/or application being requested, a level of risk presented by the user  201 , the hardware of the IHS  100 , the logical software environment of IHS  100  in which a workspace will be deployed, and the physical environment  202  in which IHS  100  is currently located. Accordingly, in this disclosure, a “security context” generally refers to data or other information related to a security posture in which a workspace will be deployed and utilized, where the security posture may be based on characteristics of user  201 , IHS  100 , the data and/or application to be accessed via the workspace, and/or environment  202 . In some embodiments, a security context may be quantified as a security risk score in support of evaluations of the level or risk associated with providing user  201  access to requested data and/or application while using IHS  100  in the particular context. 
     In various embodiments, security metrics that may be used in the calculation of a security risk score for a particular security context may include, but are not limited to: a classification of the requested data source and/or application, authentication factors used to identify user  201 , the location of IHS  100 , a role or other group classifications associated with user  201 , validation of networks in use by IHS  100 , type of network in use by IHS  100 , network firewall configurations in use by IHS  100 , indicators of attack (IoA), indicators of compromise (IoC) regarding IHS  100  or a resource being requested by user  201 , patch levels associated with the operating system and other applications in use on IHS  100 , availability of encryption, type of available encryption, access to secured storage, use of attestable hardware by IHS  100 , and supported degree of workspace isolation by IHS  100 . 
     In this disclosure, “productivity context” generally refers to user  201  productivity associated with a workspace, user  201 , IHS  100 , and/or environment  202 . A “productivity score” generally refers to an index usable to score, quantify, or measure various productivity characteristics of a productivity context. Examples of productivity context information may include, but are not limited to: the hardware of the IHS  100  that is available for use in support of a workspace, the software of the IHS  100  that is available for use in support of the workspace, power states of IHS  100  and/or hardware components of IHS  100 , maximum clock frequencies of hardware components of IHS  100  that can currently be supported, maximum operating speeds of software components of IHS  100 , peripheral devices coupled to IHS  100  and networks available for use by IHS  100  in supporting the workspace. 
     Initial productivity and security targets for a workspace may be calculated, at  205 , based on the context of user&#39;s  201  actions combined with the productivity and security context in which the workspace will operate. In some cases, at  205 , a local management agent  332  operating on IHS  100  may calculate initial security and productivity targets based upon the collected security and productivity context. In other cases, remote workspace orchestration service  206  may calculate security and productivity targets for a workspace. In this disclosure, “security target” generally refers to the attack surface presented by a workspace that is created and operated based on a specific workspace definition, while “productivity target” generally refers to the productivity characteristics of a specific workspace definition. Examples of a productivity target characteristics include, but are not limited to: types of data or data sources available to user  201  within a workspace, latency of the workspace, software applications available within the workspace, responsiveness of the workspace and remaining computational overhead available to the workspace. Attributes that may be used to characterize a security target may include, but are not limited to: a minimum security score for a workspace, a minimum trust score of IHS  100 , authentication requirements for user  201  (e.g., how many authentication factors are required, frequency of re-authentication), minimum level of trust in the network utilized by a workspace, required isolation of a workspace from IHS  100 , the ability to access browser within a workspace, the ability to transfer data between workspaces and the ability to extend a workspace. In some instances, productivity and security targets may also be based on user&#39;s  201  behavioral analytics, IHS  100  telemetry and/or environmental information that is collected via sensors of IHS  100 . 
     In this disclosure, “workspace definition” generally refers to a collection of attributes that describe aspects a workspace that is assembled, initialized, deployed and operated in a manner that satisfies a security target (e.g., the definition presents an attack surface that presents an acceptable level of risk) and a productivity target (e.g., the definition provides a requisite level of access to data and applications with an upper limit on latency of the workspace) in light of the security context (e.g., location, patch level, threat information, network connectivity, etc.) and the productivity context (e.g., performance characteristics of the IHS  100 , network speed, workspace responsiveness and latency) in which the workspace is to be deployed. A workspace definition may enable fluidity of migration of an instantiated workspace, since the definition supports the ability for a workspace to be assembled on any IHS  100  that is configured for operation with the workspace orchestration service  206 . 
     In specifying capabilities and constraints of a workspace, a workspace definition  208  may prescribe one or more of: authentication requirements for user  201 , types of containment and/or isolation of the workspace (e.g., local application, sandbox, docker container, progressive web application (PWA), Virtual Desktop Infrastructure (VDI)), applications that can be executed in the defined containment of the workspace with access to one or more data sources, security components that reduce the scope of the security target presented by the productivity environment (e.g., DELL DATA GUARDIAN from DELL TECHNOLOGIES INC., anti-virus software), the data sources to be accessed and requirements for routing that data to and from the workspace containment (e.g., use of VPN, minimum encryption strength), and workspace capabilities available to independently attach other resources. 
     In some implementations, workspace definitions may be based at least in part on static policies or rules defined, for example, by an enterprise&#39;s Information Technology (IT) personnel. In some implementations, static rules may be combined and improved upon by machine learning (ML) and/or artificial intelligence (AI) algorithms that evaluate historical productivity and security data collected as workspaces are life cycled. In this manner, rules may be dynamically modified over time to generate improved workspace definitions. If it is determined, for instance, that a user dynamically adds a text editor every time he uses MICROSOFT VISUAL STUDIO from MICROSOFT CORPORATION, then workspace orchestration service  206  may autonomously add that application to the default workspace definition for that user. 
     Still with respect to  FIG.  2   , during an orchestration phase  200 B of workspace deployment, at  208 , the initial security and productivity targets are processed and/or reconciled against resources, IHS capabilities, and cloud services capabilities in order to produce a workspace definition. As described, a workspace definition may specify capabilities and constraints of a workspace, such as: runtime security requirements of the workspace containment (e.g., such as isolation from the OS of IHS  100  or from certain hardware of IHS  100 ), the use of reference measurements to attest to the integrity of the workspace, applications to be provided for operation within the workspace, aggregation of resources available via the workspace, configurations for accessing data or resources (e.g., required use of a virtual private network (VPN)). 
     As described in additional detail with regard to  FIG.  3   , the initial workspace definition may then be utilized by an automation engine  302  of workspace orchestration service  206  to coordinate the assembly  209  and instantiation  210  of a workspace on an appropriate platform (e.g., on the cloud, on IHS  201 , or some combination of the two) based on the security and productivity contexts in which the workspace will operate. In some embodiments, automation engine  302  may resolve configuration conflicts between a workspace definition and the user&#39;s inputs in the operation of a workspace. In cases where a workspace is cloud-hosted, the automation engine  302  may assemble and instantiate a remote workspace that may be accessed via a secure connection established via a web browser or other web-based component operating on the IHS  100 . 
     At  211  of  FIG.  2   , the instantiated workspace is operated by user  201  and new productivity and security context information related to the behavior or use of data is generated at  212 . This operation of a workspace may result in a change or new classification of data based upon what user  201  has done, accessed, and/or created, thus resulting in a change to the security context of the workspace. To the extent the user&#39;s behavioral analytics, device telemetry, and/or the environment has changed to a quantifiable degree, these changes in security context may serve as additional input for a reevaluation, at  207 , of the security and performance targets by automation engine  302 . Additionally or alternatively, a new workspace context, security target, and/or productivity target may be now measured against the initial targets, and the result may cause automation engine  302  to produce a new workspace definition at  208 . 
     Particularly, if the instantiated workspace(s) have security or productivity parameters that fall outside of a range of the target scores for these parameters such that a difference between an updated context information and the previous context information is scored below a threshold value, automation engine  302  may generate modifications to an existing workspace and, at  210 , may deploy an updated workspace according to the modified definition. Conversely, if the difference between an updated context information and the previous context information is scored above a threshold value, automation engine  302  may generate a new workspace at  210 . Session data metadata and context may be preserved by data aggregation engine  336 , and session data may be restored in the new workspace as applicable. 
     Various conditions may trigger termination of a workspace at  213 , as part of termination phase  200 C. In some cases, user action may initiate the termination of a workspace (e.g., user  201  closes application or browser accessing data). In other cases, termination of a workspace may take place automatically as part of an adjustment in workspace definition (e.g., the workspace is terminated by automation engine  302  in order to support a new or updated workspace). As part of a termination phase  200 C of a workspace, various workspace resources of IHS  100  and/or at workspace orchestration service  206  may be released. 
       FIGS.  3 A and  3 B  are diagrams depicting illustrative embodiments of a system for deployment and management of workspaces on an IHS  300 B in a manner that supports orchestrated audio session management for workspaces operating on the IHS. The illustrated system includes a workspace orchestration service  206  that performs various workspace orchestration operations described above, such as: the evaluation of security and productivity targets based upon context information, the calculation of risk scores and other productivity and security metrics based on ongoing collection of context information, the generation of workspace definitions, and the assembly and instantiation of workspaces in accordance with a workspace definition, where the workspaces may be instantiated via a cloud service or an IHS  100 , such as described with regard to  FIG.  1    and further described with regard to  FIG.  3 B . As described, IHS  100  may supported deployment and operation of workspaces through the collection of productivity and security context information, the calculation of productivity scores and/or risk scores, the instantiation, execution, and modification of a workspace based upon workspace definitions that are received from workspace orchestration service  206 . 
     Workspace orchestration service  206  and IHS  100  may be coupled to each other via any suitable network technology and/or protocol which allows workspace orchestration service  206  to interoperate with IHS  100 . As described with regard to  FIG.  1   , an IHS  100  according to embodiments may include a component such as a remote access controller  155  that may support secure out-of-band communications that are independent from the operating system of IHS  100 . In some embodiments, such a remote access controller may be configured to utilize such out-of-band communication capabilities to support deployment and operation of workspaces on IHS  100  and to report changes in context information to the workspace orchestration service  206 . 
     As illustrated in  FIG.  3 A , workspace orchestration service  206  may include a number of sub-components that support deployment and ongoing evaluation and adaptation of workspaces on an IHS  100 . Embodiments of the workspace orchestration service  206  may include systems that may support web services  306 , manufacturer integration  317 , and analytics  323 . As illustrated, web services  306  may, in turn, comprise application services  301  and user interface (UI) and automation services  302 . In some embodiments, analytics services  323  may be configured to receive and process context information from IHS  100 , both during initial configuration of a workspace and in ongoing support of workspaces, and to provide that information, along with any analytics generated, to context logic  303  of application services  301 . Based on information collected during the deployment and ongoing support of workspaces, support assistance intelligence engine (SAIE)  324  may be configured to generate and/or analyze technical support information (e.g., updates, errors, support logs, etc.) for use in diagnosing and repairing workspace issues. Workspace insights and telemetry engine  325  may be configured to analyze and/or produce device-centric, historical, and behavior-based data (e.g., hardware measurements, performance measurements, use of features, settings, etc.) resulting from the operation of workspaces. Workspace intelligence  326  may include an intelligence engine for processing and evaluating context data in order to identify patterns and tendencies in the operation of workspaces and in the adaptation of workspaces based on context changes. 
     As illustrated, an application services  306  system of the workspace orchestration service  206  may include a UI and automation services  302  system that may include context logic engine  303 , classification policy logic  304 , and condition control engine  305 . Context logic engine  303  may support processing of context information in making risk assessments (e.g., evaluating the risk associated with requests by the user against the context of the user&#39;s behavior, history of the use of IHS  100 , capabilities of IHS  100 , and environmental conditions). For instance, security context information collected by IHS  100  may be provided to workspace orchestration service  206  where it may be used by context logic  303  to calculate a risk score associated with a request for use of a managed data source and/or application. Classification policy  304  may include administrator and machine-learning defined policies describing risk classifications associated with different security contexts, such as risk classifications associated with specific data, locations, physical environments, IHSs, logical environments, and user actions (e.g., use of high-risk data requires use of a workspace definition suitable for use with a risk score above a specific value). Condition control engine  305  may include intelligence providing automated decision making for alignment of risk and context. In some cases, condition control engine  305  may dynamically deploy a solution to address any detected misalignment of risk and context. For instance, upon requesting access to a highly classified data source that results in a significant increase in risk score, the condition control engine may select workspace definition modifications that implement security procedures that are suitable for the higher risk score. 
     Application services  301  may include a group of web services  306  called on by UI and automation services  302  to support various aspects of the orchestration of workspaces. Particularly, web services  306  may include application and workspace services  307  that may assemble and package applications for deployment in a workspace (e.g., an “.msix” file packaged and deployed to a MICROSOFT HYPER-V container). In some embodiments, a workspace definition may be used to specify various such types of workspace deployments that will be used to provide a user with access to an application. Web services  306  may also include a tenant subscription module  308 , that performs dynamic configuration of an IHS  100  for use with the described workspace orchestration services  206  at the point-of-sale (POS) of the IHS. A license tracking module  309  may be used to maintain and track license information for software, services, and IHSs. An access control module  310  may provide top level access controls used in controlling access to data and applications by authorized users. A Unified Endpoint Management (UEM) module  311  may be configured to support the described orchestration of workspaces on various different IHSs that may be utilized by a particular user. 
     Web services  306  that may be used in support of workspaces deployed on IHS  100  may further include resource provisioning services  312  for configuring IHS  100  or a workspace with secrets/credentials necessary to access specific resources (e.g., credentials for use of VPNs, networks, data storage repositories, workspace encryption, workspace attestation, and workspace-to-device anchoring). In some cases, resource provisioning services  312  may include secrets provisioned to IHS  100 , such as to secure memory  120 , as part of a trusted assembly process of IHS  100  and, in some instances, associated with a unique identifier  348  of the IHS  100 . Web services  306  may also include an authorization/token module  313  that provides identity functions and may connect to various authentication sources, such as Active Directory. Endpoint registration module  314  may be configured to register IHSs and/or workspaces in order to track the use of the described workspace orchestration. In some scenarios, a directory services  315  module may be configured to provide active directory services (e.g., AZURE ACTIVE DIRECTORY from MICROSOFT CORPORATION). Device configuration services  316  may enable central configuration, monitoring, managing, and optimization of workspaces that in certain contexts may operate remotely from an IHS and may only present the user of the IHS with a user interface that presents an image of the workspace output. In cooperation with resource provisioning services  312 , device configuration services  316  may also handle creation of secrets and IHS configuration. 
     Still referring to  FIG.  3 A , manufacturer integration components  317  communicate with application services  301  and client IHS  100  to provide features that are usable during workspace evaluation and instantiation, where these features may be based upon information available to the manufacturer of IHS  100 . For instance, certificate authority  318  may include an entity that issues digital certificates that may be used in validating the authenticity and integrity of the hardware of IHS  100 . Identity service module or engine  319  may be configured to manage the user identities, as well as brokering user identification for use of customer directory  322 . Order entitlement engine  320  may be used to manage purchased entitlements as well as the associated issued certificates signed by  318 . Ownership repository  321  may manage user entitlements associated with IHSs and their ownership and may provide support for users transferring ownership of an IHS and conveying the entitlements associated with that IHS. In certain scenarios, ownership repository  321  may use this transfer of ownership to decommission the secrets associated with the entitlements embedded in the IHS. Customer directory  322  may be configured to authenticate and authorize all users and IHSs in a network, such as assigning and enforcing security policies for all IHSs and installing or updating software (in some cases, customer directory  322  may work in cooperation and/or may be the same as directory services  315 ). 
     Referring now to IHS  100  of  FIG.  3 B , in some embodiments, IHS  100  may be configured to operate a local management agent  332  that may operate as a trusted and attestable process of IHS  100  and that may operate independent from the operating system  360  of IHS  100 . In some embodiments, local management agent  332  may include a workspace engine that instantiates and manages the operation of one or more workspaces  331 A-N on IHS  100 . As described, the capabilities of a workspace  331 A-N may be modified based on detected changes in the productivity and security contexts in which the workspace is operating. Accordingly, the workload(s) in each of the workspaces  331 A-N may be hosted in full or in part by a cloud resource, a specific server, or locally hosted on IHS  100 , depending on the context in which the workspace is operating. These allocations of workspace computing for each particular workspace  331 A-N may be prescribed by the workspace definition that is used to build and operate each workspace. As described, the workspace definition may be created by workspace orchestration service  206  based upon: context information provided by IHS  100 , security targets for each workspace  331 A-N, and/or productivity targets for each workspace  331 A-N. As described in additional detail below, an individual workspace  331 A-N may be provided with use of local resources of IHS  100 , such as use of audio capabilities of IHs  100 , via a secure communication mechanism supported by workspace orchestration service  206  and remote access controller  341  of IHS  100 . Utilizing the provided embodiments, such use of local resources, such as audio controls of IHS  100 , by workspaces  331 A-N may be adapted in response to detected changes in the security context of IHS  100 . 
     In some embodiments, local management agent  332  may be configured to host, launch, and/or execute a workspace hub  327  that provides a launch point  203  by which users may initiate workspaces  331 A-N through the selection of managed data and/or resources. As described, launch point  203  may be an agent, application, special-purpose workspace or web portal the provides a user interface by which a user may select from a collection of data sources, applications or other managed information or resources that are available to the user of IHS  100  via the operation of a workspace as described herein. In various embodiments, launch point  203  may be provided in the form for textual, graphical and/or audio user interfaces that allow a user of IHS  100  to select available data and/or resources. Workspace hub  327  may utilize a local environment management module in providing the workspace interface that is presented to the user on IHS  100  in a consistent manner across workspaces  331 A-N. 
     In some embodiments, each instantiated workspace  331 A-N may be a logical software environment that provides a user with access to requested data or applications, where the environment may be isolated in varying degrees from the hardware and software of IHS  100  based on the security context and productivity context in which each workspace  331 A-N is operating. In some instances, the selection of a data source or resource that is available to user via launch point  203  may result in launching a new workspace  331 A-N. For instance, if a user launches a browser through selection of an icon displayed by launch point  203 , a new workspace may be created and launched according to a workspace definition that has been selected for providing the user access to a web browser in the security and productivity contexts in which the request has been made. In a scenario where the user selects a confidential presentation file available from a data source that is provided by launch point  203 , an additional workspace  331 A-N may be instantiated with use of a presentation application and with access to the requested presentation file, where this new workspace is created based on a workspace definition that provides appropriate security for access to the confidential presentation. In other instances, a selection of the presentation file by a user may result in the presentation being made available through the existing workspace, in some cases using the existing workspace definition and, in other cases, using a workspace definition that has been modified to support the requested access to the confidential presentation file. 
     In various embodiments, in order to execute the various operations described herein, local management agent  332  may include a command monitor that provides instrumentation to receive commands from workspace orchestration service  206  in support of adaptation of workspaces  331 A-N based on detected changes in context. Local management agent  332  may include a telemetry module that may collect and communicate information to the workspace orchestration service  206 , including reporting changes in context that may warrant adjustments to workspaces  331 A-N. Local management agent  332  may also utilize a resource manager module that is configured to manage access to data, audio controls, network configurations, identity information, access control, and resource provisioning services. A security module of local management agent  332  may be configured to provide various security services. IHS  100  may include an IHS identification module  348  that provides a unique, unspoofable identifier that is cryptographically bound to IHS  100 . 
     As illustrated in  FIG.  3 B , IHS  100  includes a remote access controller  341  that provides capabilities for remote management of IHS  100  and that provides out-of-band management of various hardware components of IHS  100 . As indicated in  FIG.  3 B , the remote access controller  341  operates independently from the operating system  360  in providing remote management of IHS  100 . A selected portion of the capabilities of a remote access controller  341  are illustrated in  FIG.  3 B . As described with regard to  FIG.  1   , a remote access controller  341  may include a root of trust  342  capability that is used to evaluate firmware instructions to be used by various hardware components of IHS  100  against reference signatures for these components, thus validating the firmware in use by these components. In some embodiments, workspace operations supported by workspace orchestration service  206  may require such root of trust validations by remote access controller  341  prior to initiating deployment of workspaces to IHS  100 . In some embodiments, remote access controller  341  may include a secure object store  344  for use in storing reference signatures used by root of trust  342  module. As described with regard to  FIG.  1   , reference signatures utilized by root of trust  342  module may alternatively or additionally be stored in a secure memory of IHS  100 . In some embodiments, an IHS attestation  343  module of remote access controller  341  may interface with workspace orchestration service  205  in providing confirmations of root of trust validations of the hardware components of IHS  100 . 
     In some embodiments, remote access controller  341  may also include a secure communications support module  350  that may be used to facilitate secure communications with workspaces  331 A-N in providing these workspaces with access to local resources of IHS  100  that have been registered for use in this manner with workspace orchestration service  206 , such as capabilities of interfacing with audio controls supported by IHS  100 . As described in additional detail below, configuration of a local resource for use by a workspace  331 A-N may include workspace orchestration service  206  providing remote access controller  341  with a handle for use in interfacing with an individual workspace  331 A-N in providing the workspace with a selected local resource of IHS  100 . As described, an IHS may concurrently support multiple different workspaces  331 A-N, each operating according to a separate workspace definition. Each workspace  331 A-N may utilize multiple local resources of IHS  100 . Each instance of a workspace utilizing a local resource of IHS  100  may be supported by a separate handle that supports secure communications between a workspace and the remote access controller  341 . In turn, each handle may include a token and may specify various conditions for the validity of the token, such as a time limit on the validity of a token. The secure communications support module  350  of the remote access controller  341  may manage the various handles in use at any one time in providing workspaces  331 A-N with access to local resources of the IHS. In some embodiments, secure communications support module  350  may be configured to evaluate the conditions provided in each handle for the validity of the handle&#39;s token in order to determine whether to continue providing a workspace with access to the local resource specified by the handle. 
     As illustrated, each workspace  331 A-N may include a local resource service  335 A-N that configures use of available resources of the IHS by a respective workspace, such as use of audio controls of the IHS that are not directly accessible by workspaces  331 A-N. As described in additional detail below, a local resource service  355 A-N may interoperate with workspace orchestration service  206  in order to configure a respective workspace  331 A-N for use of resources of the IHS  100  that have been registered with the workspace orchestration service  206  as being available for use by workspaces  331 A-N. In some instances, such resource of IHS  100  that are available for use by workspaces  331 A-N may be identified for workspace orchestration service  206  by remote access controller  341  via out-of-band signaling pathways that are independent from operating system  360  of IHS  100 , such as described with regard to  FIG.  1   . 
     Once a local resource service  355 A-N has negotiated use of available IHS resources, workspace orchestration service  206  may provide a respective local resource service  355 A-N with a handle that supports a secure means for accessing a local resource of IHS  100 . As described in more detail below, in embodiments where local resource service  355 A-N is used to support use of local audio capabilities of IHS  100 , each workspace  331 A-N may also include an audio client  375 A-N that may operate within an induvial workspace in capturing audio related events from applications running within a workspace and in adjusting workspace audio inputs and outputs based on workspace context information provided by an audio agent  365  of the IHS. 
     As illustrated in  FIG.  3 B , IHS  100  may also include an audio controller  370 . As described with regard to  FIG.  1   , in various embodiments, audio controller  370  may be a dedicated hardware component or a function of a multi-function hardware component and may interface with audio control  360   a  capabilities of the operating system of the IHS  100 . As described in additional detail below, an audio agent  365  may utilize a handle provided by the workspace orchestration service  206  in order to communicate with audio clients  375 A-N in the management of audio sessions that include audio inputs or outputs from workspaces  331 A-N. Utilizing communications conducted using the provided handle, an individual audio client  375 A-N may relay user adjustments to audio settings within a particular workspace. Based on notification of such user adjustments, the audio agent  365  may operate audio controls provided by the audio controller  370  and/or by the operating system audio controls  360   a  in order to adjust the audio of that workspace. In addition, audio agent  365  may provide each audio client  375 A-N with audio context information that is used by each audio agent to determine how to configure the audio inputs and outputs of each workspace  331 A-N. For instance, audio agent  365  may utilize information provided by the operating system  360  and/or the local management agent  332  in order to identify which of the workspaces  331 A-N is currently active, such as based on which workspace is the topmost of the displayed workspaces and based on which workspace has most recently received inputs from the user. Using the provided handle, such audio context information may be relayed by the audio agent  365  to each of the audio clients  375 A-N for use in adjusting the audio input and outputs of each workspace. 
       FIG.  4    is swim lane diagram describing the operation of certain components of a system according to some embodiments, in configuring orchestrated audio session management for workspaces operating on an IHS. Embodiments may begin with the initialization of an IHS that is configured according to the embodiments described above. As described, in some embodiments, initialization procedures of an IHS may include validation of instructions utilized by various hardware components of the IHS. For instance, firmware instructions to be loaded by a remote access controller  410  of the IHS may be used to generate a hash value that is compared to a digital signature stored in a secure memory of the IHS, where the digital signature corresponds to authentic firmware instructions stored for use by the remote access controller during a trusted manufacturing process of the IHS, or during another trusted administrative process. In this same manner, the firmware instructions utilized by various hardware components of the IHS may be successively validated against stored reference signatures in order to iteratively expand a root of trusted hardware components of the IHS. In some embodiments, the firmware instructions of the remote access controller  410  that are validated in this manner may include instructions used by the remote access controller to determine resources of the IHS that may be utilized by workspaces operating on the IHS and to transmit such local resource information to a remote workspace orchestration service  420 . 
     As indicated at  425  in  FIG.  4   , once the instructions utilized by the remote access controller  410  have been validated, the remote access controller may utilize these instructions to communicate with a remote workspace orchestration service  420  in registering for secure use of IHS resources by one or more workspaces  405  operating on the IHS. In some embodiments, the validated firmware instructions utilized by the remote access controller  410  may include instructions for securely determining resources of the IHS that may be used by workspaces operating on the IHS and for transmitting a registration of these available IHS resources to the workspace orchestration service  420 . In such instances, the remote access controller  410  thus utilizes validated instructions for configuring operation with workspaces and in communicating with the workspace orchestration service  420 , where these instructions are provided during a trusted process for manufacture of an IHS, or during a trusted administrative process. 
     At  425 , the remote access controller  410  provides the workspace orchestration service  420  with a listing of IHS resources that are available for use by workspaces  405  operating on the IHS. As described, such list of available resources may include capabilities supported by hardware or software components of the IHS, but are not accessible to workspaces  405  due to their isolation from the underlying hardware and software of the IHS. For instance, available resources may include ACPI (Advanced Configuration and Power Interface) capabilities for querying and configuring power management settings of an IHS. In some instances, available resources may include WMI (Windows Management Instrumentation) capabilities for management of IHSs that operate using a Windows operating system. Embodiments provide use of audio session management functions of the IHS that are otherwise not accessible by workspaces  405  due to virtualization of the hardware and operating system of the IHS by workspace  405 . Embodiments may also support functions that consolidate management of audio inputs and outputs in use by different workspaces  405  operating on the IHS, thus addressing issues resulting from each workspace operating in isolation from the other workspaces on the same IHS. Through the use of the provided consolidated audio management, workspaces  405  may avoid situations with interfering, concurrent audio inputs and/or outputs by different workspaces and may also avoid inconsistencies that may result from each workspace  405  utilizing audio capabilities of the IHS in isolation from other workspaces. 
     As indicated at  430 , in response to receiving a list of available IHS resources, the workspace orchestration service  420  transmits an authorization token to the remote access controller  410 . This authorization token may be used by the remote access controller  410  to establish secure communications between a workspace  405  and the audio agent  418  in providing the workspace with access to the audio session management capabilities of the IHS. In some embodiments, the authorization token provided to the remote access controller  410  may be calculated based on a unique identifier of the IHS, such as an identifier provided by an IHS identification  348  function of the IHS, where this unique identifier may be a service tag or other unique code assigned to an IHS upon its manufacture. By generating the authorization token based on a unique identifier of the IHS, the token is thus bound to that particular IHS such that any attempts to utilize the token by other IHSs are detectable. 
     In some instances, the identification of available resources by the remote access controller  410  and the receipt of an authorization token from the workspace orchestration service  420  is completed upon initialization of the remote access controller  410  and prior to the user commencing actual use of the IHS. Once the IHS has been initialized and is in use, a workspace may be initialized or reinitialized. In some instances, a workspace may be initialized in response to a user requesting access to a protected resource via a launch point operating on the IHS, such as described with regard to  FIG.  2   . As described with regard to  FIGS.  3 A and  3 B , an IHS supporting the use of workspaces may operate using a workspace management agent, represented as  415  in  FIG.  4   , that is used to deploy and manage workspaces operating on the IHS. 
     In response to a user initiating a request for use of a protected resource through operation of a workspace, at  435 , the workspace management agent  415  transmits a request to the workspace orchestration service  420  for a workspace for use of the protected resource. At  440 , the workspace orchestration service  420  generates a workspace definition for generating and operating a workspace that provides the user with access to the protected resource. As described above, a workspace definition may be selected based on factors such as the security context and productivity context of the IHS that will host the workspace, the user making the request and/or the logical and physical environment in which the workspace will operate. Various types of context information may be provided to the workspace orchestration service  420  as part of the request from the workspace management agent  415 . Additional context information may be collected by the workspace orchestration service  420  from the remote access controller  410 . Based on evaluation of the context information, at  445 , the workspace orchestration service  420  transmits the workspace definition and other data for generating a workspace to the workspace management agent  415 . 
     Using the received workspace definition, at  448 , the workspace management agent  415  instantiates and deploys the workspace  405  that will provide the user with access to the protected resource. With the workspace  410  deployed and in use, at  450 , the workspace  410  registers a request for use of available IHS resources with the workspace orchestration service  420 . As described with regard to  FIG.  3 B , each workspace  331 A-N that is configured and deployed according to embodiments may include a local resource service  335 A-N that is configured to provide a respective workspace with access to local resources of the IHS that are otherwise unavailable due to the isolation of the workspace from all or part of the hardware and software of the IHS. As described, a workspace may provide access to a protected resource within a virtualized, logical environment that relies on abstractions from the underlying hardware and the operating system of an IHS, thus isolating the workspace from these local resources of the IHS. 
     Upon receipt of a registration request from workspace  405 , at  455 , the workspace orchestration service  420  responds by providing workspace  405  with a list of the available resources of the IHS that are available for use by workspaces, as specified, at  425 , by the remote access controller  410 . In some embodiments, the workspace orchestration service  420  may validate the registration request received from workspace  405 . In some embodiments, the workspace  405  may include a unique identifier in its registration request transmitted to the workspace orchestration service  420 . In such instances, this unique identifier presented by the workspace  405  is an identifier that was included in the workspace definition that was generated by the workspace orchestration service  420  and used to deploy the workspace  405 . By presenting this unique identifier in its registration request, the workspace orchestration service  420  may validate that the request originates from an authentic workspace that is operating using a workspace definition generated by the workspace orchestration service  420 . In some embodiments, this unique identifier included in a workspace definition may be digitally signed using a private key of the orchestration service  420 , thus allowing the workspace management agent  415  to authenticate the received workspace definition and for the orchestration service to validate communications received from the instantiated workspace  405 . Once the workspace  405  has been validated, at  455 , the workspace orchestration service  420  provides the workspace  405  with an authorization token for use in authenticating the workspace  405  in its use of IHS resources made available via the remote access controller  410 . In some embodiments, the token provided to the workspace  405  may be calculated by the orchestration service  420  based on the unique identifier of the workspace, thus binding the token for use by that particular workspace such that any attempts to utilize the token by other workspaces are detectable. 
     As indicated at  455  of  FIG.  4   , the workspace orchestration service  420  also provides the workspace  405  with the list of IHS resources that have been made available by the remote access controller  410  for use by workspaces. In some embodiments, the workspace  405  may evaluate the list of available IHS resources against its workspace definition in order to determine the available IHS resources that are compatible with the operating constraints specified by the workspace definition. For instance, a required minimum security score associated with a workspace definition may prohibit the use of certain IHS resources. For instance, the minimum security score associated with a workspace may allow for audio playback capabilities, but may prohibit the use of audio recording capabilities. At  460 , the workspace  405  selects from the list of available IHS resources based on compatibility with the workspace definition in order to gain access to audio session management capabilities that are otherwise not available to workspace  405 . At  465  of  FIG.  4   , the workspace  405  notifies the workspace management agent  415  and the workspace orchestration service  420  of its selection of the IHS audio session management capabilities that have been made available by the remote access controller  420 . 
     In response to the selection of audio session management capabilities by workspace  405 , as indicated at  470 , the workspace management agent  415  may initiate an IHS audio agent  418  that interfaces with the audio controls  419  supported by the IHS. In some embodiments, the IHS audio agent  418  may be implemented as a special-purpose workspace that operates one or more applications for interfacing with the various IHS audio controls  419  on behalf of the workspaces  405  that are operating on the IHS. In such embodiments, the IHS audio agent  418  is thus instantiated and operated according to a workspace definition provided by the orchestration service  420 . In some embodiments, the IHS audio agent  418  may be an application that is operated by the remote access controller  410 . For instance, IHS audio agent  418  may operate within a secure operating environment of the remote access controller  410  that is separate from the operating system of the IHS, such as described with regard to  FIG.  1   . In such embodiments, the IHS audio agent  418  thus relies on capabilities of the remote access controller  410  in interfacing with the IHS audio controls  419 . Once the IHS audio agent  418  is initialized, at  475 , the audio agent may configure use of the IHS audio controls  419 , such as by cataloging the audio inputs, outputs and controls that are supported by the hardware and software of the IHS. 
     In various embodiments, the IHS audio controls  419  may include any audio input and output capabilities supported by an IHS, such as enabling and disabling a microphone, external speakers, or internal speakers of the IHS and such as modifying settings such as privacy modes. The IHS audio controls  419  may also include capabilities to enable or disable streaming of live or pre-recorded audio, where the audio stream may originate from a remote source or locally from the IHS. The IHS audio controls  419  may also include configuration of various privacy controls, such as controls disabling the microphone of the IHS until a user has expressly authorized enabling the microphone or until the microphone is enabled for an authorized purpose by the IHS audio agent  418 . In some embodiments, privacy controls may be modified through operation of a remote access controller, such as described with regard to  FIG.  1   , that interfaces with a microphone or audio controller via out-of-band communication channels in order to enable power delivery to the microphone or audio controller circuits that enable use of a microphone. In this manner, a remote access controller may enable hardware-level configuration of a microphone, thus providing reliable privacy with regard to voice service capabilities, while allowing privacy modes to be disabled based on the context in which workspaces are operated by a user. As described with regard to  FIG.  3 B , the IHS audio controls  419  may include audio capabilities supported by an audio controller  370  of the IHS and/or audio controls  360   a  supported by an operating system  360  of the IHS. 
     As indicated at  480 , once the IHS audio controls  419  have been identified, the IHS audio agent  418  may update the workspace definition of workspace  405  to re-route audio input and output commands from applications running in the workspace to the IHS audio agent  418 . In some instances, such updates to the workspace definition of workspace  405  may be implemented using workspace definition update capabilities of the workspace management agent  415 . Also as indicated at  480 , the workspace  405  may respond by initiating a workspace audio client  408  that is an application running with the workspace  405  that monitors the audio inputs and outputs of the various applications that may operate within workspace  405  and interfaces with the IHS audio agent  418  in configuring the audio inputs and outputs by these applications. 
     In response to the selection of audio session management capabilities by workspace  405 , as indicated at  482 , the workspace orchestration service  420  provides the IHS audio agent  418  with a handle to the requested IHS audio resources, where this handle specifies the IHS audio resources to be provided, a mechanism for invoking the IHS audio controls and any constraints that may limit the duration of the workspaces&#39; use of the IHS audio session management capabilities. Also as indicated at  482 , this same handle may be provided by the workspace orchestration service  420  to the workspace audio client  408  that is managing audio sessions on behalf of workspace  405 . In some embodiments, the handle provided by the workspace orchestration service  420  may specify various aspects of the audio session management capabilities that are being made available to the workspace  405  by the IHS audio agent  418 . In addition to identifying the audio session management capabilities, the handle may also specify an API (Application Programming Interface) that is to be supported by the IHS audio agent  418  for use by the workspace audio client  408  in invoking the audio session management capabilities. The API included in the handle may specify a list of audio session management methods that are supported by the IHS audio agent  418 , where the specified audio session management methods may be identified by signatures that specify method arguments that must be supplied by the workspace audio client  408  and corresponding responses that will be provided by the IHS audio agent  418 . 
     In providing a means by which the audio session management API included in the handle may be invoked, the handle may also include a reference to an IPC (Inter-Process Communications) resource of the IHS that is to be used in the API communications between the IHS audio agent  418  and the workspace audio client  408 . For instance, the handle may include a pointer to a memory location or data buffer that is to be used in the transmission of data between the IHS audio agent  418  and the workspace audio client  408 . In other instances, the handle may include a reference identifying a socket or pipe by which data maybe transmitted by the workspace audio client  408  to the IHS audio agent  418  and by which responsive data resulting from execution of an API call may be provided to the workspace audio client  408  by the IHS audio agent  418 . 
     In addition to specifying the API that is supported and a reference to an IPC resource of the IHS, the handle provided by the workspace orchestration service  420  may also include a token that may be used to specify constraints on the duration of the validity of the handle. In some embodiments, the token included in a handle may be generated based on the token provided to the remote access controller  410 , which may be based on a unique identifier of the IHS, and may also be generated based on the token provided to the workspace  405 , which may be based on a unique identifier of the workspace. In this manner, the token included in the handle may be bound to the IHS and to the workspace  405  such that use of the handle on another IHS or by another workspace is detectable. 
     In some instances, a token specified in a handle may be valid for the duration of the lifespan of the workspace  405 . Accordingly, in such instances, no limitations or conditions on the token are specified in the handle. However, in other instances, the validity of a token may be limited according to various conditions specified in the handle. In such instances, the token included in the handle is thus a session token with a limited term of validity. For example, conditions set forth in the handle may specify that the session token is only valid until a certain time. As described with regard to  FIG.  1   , an IHS according to embodiments may include sensors capable of determining whether a user is in proximity to the IHS. In some instances, conditions set forth in the handle may specify that a session token becomes invalid upon detecting that the user of the IHS can no longer be detected in proximity to the IHS. In another example where the IHS is a laptop computer, the conditions set forth in the handle may specify that the session token is only valid until the lid of the laptop is closed. In another example, the conditions set forth in the handle may specify that the session token becomes invalid if the IHS is moved to a different location, or is moved outside of a specific location. In another example, the conditions set forth in the handle may specify that the session token becomes invalid if an audio stream that is not from a particular source is detected. For instance, a session token may be valid for use in a virtual meeting as long as audio from all participants is being provided via a particular server system. In other instances, a session token may be valid as long as certain audio privacy controls are not modified. 
     As describe above, a workspace definition may be associated with a security score that is measure based on the security context in which the workspace is deployed. In some embodiments, a session token specified in a handle may be limited based on conditions requiring a minimum security score in order for the token to remain valid. In such embodiments, the workspace management agent  415  may monitor for changes in the security context of the workspace  405 . Examples of detected changes in the security context may include a change in the source of audio data being accessed, a change in the participants in an interactive audio session, a change in the antivirus software in use by the IHS, a change in the network access point used by the IHS, a change in the location of the IHS from a corporate environment to a public location, and/or a change of the individual that is using the IHS. Upon detecting such changes in the security context, a new security score may be calculated for the workspace. If the security score drops below a certain threshold, a session token included in a handle may become invalid. 
     With the IHS audio agent  418  and the workspace audio client  408  both provided with the handle generated by the workspace orchestration service  420 , use of the audio session management capabilities specified in the handle may commence. As described above, an issue arising from an IHS hosting multiple workspaces operating in isolation from each other is the inevitable contention for an IHS resource by two or more workspaces. For instance, a user of an IHS may utilize two different workspaces for participating concurrently in two different virtual meetings. In such a scenario, the user may switch between participating in the two different virtual meetings by switching between use of the two different workspaces. A user may be able to properly reconfigure audio inputs and outputs of the IHS in order to switch between the two different virtual meetings, but only via cumbersome and slow manual configuration of the IHS audio capabilities. In another scenario, a user may be using a workspace for playback of streaming audio, but may initiate a second workspace to begin participation in a virtual meeting. In order to switch between the streaming audio in the virtual meeting, the user must manually configure the IHS audio settings and/or separately configure the audio settings in each of the workspaces. Without proper configuration of workspace audio settings, the user may face the playback of the streaming audio from one workspace being picked up by the microphone in use by the other workspace and broadcast within the virtual meeting. Embodiments provide capabilities for automatic configuration of IHS audio inputs and outputs in response to such changes in context. 
     As indicated at  484  of  FIG.  4   , the IHS audio agent  418  may monitor user activity in order to determine which workspace is being actively used and reports this context information to the workspace audio client  408 . In some embodiments, the IHS audio agent  418  may rely on the workspace management agent  415  in order to determine which workspace is actively in use. 
     In such embodiments, the workspace management agent  415  monitors for user inputs to the various workspaces and interfaces with the operating system of the IHS in order to determine which workspace is being displayed in the foreground of the IHS display. For instance, in a scenario where multiple workspaces are operating on an IHS and each workspace is separately displayed in its own operating system window, the IHS audio agent  418  may determine the workspace corresponding to the topmost window and/or which window is currently receiving mouse and keyboard inputs from the user. 
     Using the API and IPC resource provided handle, the IHS audio agent  418  may transmit such workspace context information to the workspace audio client  408 . At  485 , the workspace audio client  408  may utilize the received workspace context information to configure the audio inputs and outputs of the workspaces  405  operating on the IHS. For instance, the configurations by the workspace audio client  408  may disable audio inputs and outputs by all workspaces other than the workspace reported as the topmost of the multiple workspaces operating on the IHS. In other instances, the configurations by the workspace audio client  408  may disable audio inputs and outputs by all workspaces other than the workspace reported as receiving the most recent user inputs, such as the workspace that has most recently received a mouse input from the user. In some embodiments, rather than disable audio inputs and outputs in nonactive workspaces, the workspace audio client  408  may instead operate audio controls in nonactive workspaces, such as by pausing playback of streaming audio session in the nonactive workspace or by pausing in active recording session in the nonactive workspace. In another example, the workspace audio client  408  may disable voice command capabilities in all nonactive workspaces in response to context information provided by the IHS audio agent  418 , such as based on the IHS detecting that an individual other than the user has been detected in proximity to the IHS. 
     During the user&#39;s ongoing operation of multiple workspaces  405 , the user may operate the available audio controls provided by applications running in each of the workspaces. For instance, in a workspace  405  that is being used to run a virtual meeting application, a user may manually configure the audio controls provided by that virtual meeting application, such as by muting microphone inputs to the application or by muting speaker outputs from the application. The user may similarly operate audio controls provided by various types of applications running within one of multiple workspaces  405  operating on an IHS, such as stopping playback of a streaming audio source or by terminating an application altogether. As indicated at  487 , the workspace audio client  408  may detect any such user configurations of audio related application events within workspace  405 . In some embodiments, the workspace audio client  408  detects such audio related events based on the configuration of the workspace, at  480 , to reroute audio configurations in specific applications, such as media playback and virtual meeting applications, to be reported to the workspace audio client  408 . 
     Upon the detection of such audio related events within a workspace  405 , at  490 , the audio events are relayed to the IHS audio agent  418 . In relating these audio events, the workspace audio client  408  generates a command that invokes the appropriate audio configuration commands supported by the IHS by generating an API call that is specified in the provided handle. In some embodiments, these API calls may be generated by a local resource service  335 A-N, as described with regard to  FIG.  3 B , of the workspace  405  that may be configured to manage operations for requesting and managing use of a local resource on behalf of the workspace  405 . Using handle information provided by the local resource service, the workspace audio client  408  may transmit the API call to the IHS audio agent  418  using the IPC resource that is included in the handle for communications between the two components. 
     The API call relaying the audio command is issued via the IPC resource specified in the handle and is received by the IHS audio agent  418 . As described, a handle may include a token that uniquely identifies a workspace within a set of workspaces supported by a particular workspace orchestration system  420 . Upon receipt of the audio command from the workspace audio client  408 , the IHS audio agent  418  may utilize such token information to validate the request. As described with regard to  FIG.  3 B , remote access controller  410  may include a secure communication support module  350  that is configured to manage communications with workspaces. In some embodiments, this secure communication support module of the remote access controller  415  may conduct these communications with individual workspaces via an IPC resource specified in a handle on behalf of the IHS audio agent  418 , where the remote access controller  415  may utilize out-of-band pathways described with regard to  FIG.  1    to access the IPC resource specified in the handle, such as a location in the system memory  105  of the IHS or a socket supported by a network controller  125 . 
     Upon receipt of the audio command API call from a workspace  405  via the IPC resource, the IHS audio agent  418  the audio command is processed by the IHS audio agent  418  by operation the IHS audio controls  419 . In some instances, the IHS audio agent  418  may be able to fulfill the audio command by manipulation of audio controls provided by the operating system or by the audio controller of the IHS, such as a command that results in disabling of all audio outputs to all speakers. In other instances, the IHS audio agent  418  may interface with the audio controller of the IHS, such as described with regard to  FIG.  1   , in order to modify an audio stack maintained by the audio controller for playback. For example, in a scenario where audio output from one workspace is being maintained and audio from another workspace is being muted, the IHS audio agent  418  may remove audio from the muted workspace from the audio stack maintained by the audio controller. Utilizing such operations, at  495 , the audio controls  419  of the IHS may be manipulated in order to adjust the audio outputs from each of the different workspaces  405  operating on the IHS. Once the audio command invoked on behalf of the workspaces  405  has been completed, at  497 , the IHS audio agent  418  utilizes the IPC resource provided in the handle to provide the workspace audio client  408  with a responsive communication specified by the API call made by the workspace audio client  408 . 
     It should be understood that various operations described herein may be implemented in software executed by processing circuitry, hardware, or a combination thereof. The order in which each operation of a given method is performed may be changed, and various operations may be added, reordered, combined, omitted, modified, etc. It is intended that the invention(s) described herein embrace all such modifications and changes and, accordingly, the above description should be regarded in an illustrative rather than a restrictive sense. 
     The terms “tangible” and “non-transitory,” as used herein, are intended to describe a computer-readable storage medium (or “memory”) excluding propagating electromagnetic signals; but are not intended to otherwise limit the type of physical computer-readable storage device that is encompassed by the phrase computer-readable medium or memory. For instance, the terms “non-transitory computer readable medium” or “tangible memory” are intended to encompass types of storage devices that do not necessarily store information permanently, including, for example, RAM. Program instructions and data stored on a tangible computer-accessible storage medium in non-transitory form may afterwards be transmitted by transmission media or signals such as electrical, electromagnetic, or digital signals, which may be conveyed via a communication medium such as a network and/or a wireless link. 
     Although the invention(s) is/are described herein with reference to specific embodiments, various modifications and changes can be made without departing from the scope of the present invention(s), as set forth in the claims below. Accordingly, the specification and figures are to be regarded in an illustrative rather than a restrictive sense, and all such modifications are intended to be included within the scope of the present invention(s). Any benefits, advantages, or solutions to problems that are described herein with regard to specific embodiments are not intended to be construed as a critical, required, or essential feature or element of any or all the claims. 
     Unless stated otherwise, terms such as “first” and “second” are used to arbitrarily distinguish between the elements such terms describe. Thus, these terms are not necessarily intended to indicate temporal or other prioritization of such elements. The terms “coupled” or “operably coupled” are defined as connected, although not necessarily directly, and not necessarily mechanically. The terms “a” and “an” are defined as one or more unless stated otherwise. The terms “comprise” (and any form of comprise, such as “comprises” and “comprising”), “have” (and any form of have, such as “has” and “having”), “include” (and any form of include, such as “includes” and “including”) and “contain” (and any form of contain, such as “contains” and “containing”) are open-ended linking verbs. As a result, a system, device, or apparatus that “comprises,” “has,” “includes” or “contains” one or more elements possesses those one or more elements but is not limited to possessing only those one or more elements. Similarly, a method or process that “comprises,” “has,” “includes” or “contains” one or more operations possesses those one or more operations but is not limited to possessing only those one or more operations.