Audio Plug-in Processing via Distributed Computing

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

Digital audio workstations are limited by computationally expensive audio processing plug-ins that consume significant processor cycles and memory, hindering simultaneous execution and creativity, while also facing challenges in development, distribution, and piracy.

Innovation Solution

Executing audio processing plug-ins in a remote distributed computing environment, where a plug-in shim on the user's device transmits audio streams to a network service for processing, allowing for more efficient resource use and reduced distribution needs.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Speed

If audio processing plug-ins are executed on the musician's computing device, then the plug-ins can process digital audio in real-time, but the computing resources (processor cycles and memory) are significantly consumed, limiting the number of simultaneous plug-ins

Engineering Contradiction:

Improvereal-time audio processingVSAvoidprocessor cycles and memory consumption

Core Design Contradiction:

SpeedVSUse of energy by moving object

Solution Approach 1:

A network service acts as an intermediary between the musician's computing device and the audio processing plug-ins. The plug-in shim on the user's device transmits audio streams to the network service, which then routes them to plug-ins executed on remote server computers. This mediator architecture allows real-time processing while offloading computational burden from the local device.

Inventive Principle:

Principle #24Intermediary (Mediator)

Solution Approach 2:

The system transitions from a single-location execution model to a distributed computing environment across multiple dimensions (local device, network infrastructure, remote servers). By distributing plug-in execution across multiple geographic and computational dimensions, the system achieves both real-time responsiveness and reduced local resource consumption.

Inventive Principle:

Principle #17Another dimension (Dimensionality change)

2Adaptability or versatility

If multiple versions of the same plug-in are developed for different operating systems and architectures, then the plug-ins can be compatible with various platforms, but the development time and computing resources are inefficiently utilized

Engineering Contradiction:

Improveplatform compatibilityVSAvoiddevelopment time

Core Design Contradiction:

Adaptability or versatilityVSLoss of time

Solution Approach 1:

The network service provides a universal execution environment that can run plug-ins regardless of the musician's local operating system or hardware architecture. A single plug-in binary can be executed on the server side, which abstracts away platform-specific differences, thereby achieving multi-platform compatibility without developing separate versions for each OS or architecture.

Inventive Principle:

Principle #6Universality (Multi-functionality)

3Ease of operation

If plug-ins are widely distributed to individual musicians, then the plug-ins can be accessed by users, but significant network bandwidth is consumed and piracy becomes a major issue

Engineering Contradiction:

Improveplug-in accessibilityVSAvoidnetwork bandwidth

Core Design Contradiction:

Ease of operationVSLoss of energy

Solution Approach 1:

Instead of distributing physical or downloadable copies of plug-ins to each user, the system creates virtual copies through cloud-based execution. The plug-in code remains centralized on the server, and users access functionality through network connections to the service, eliminating the need for widespread distribution while maintaining accessibility.

Inventive Principle:

Principle #26Copying

4Reliability

If anti-piracy program code is included in plug-ins, then piracy can be reduced, but additional processor cycles and memory are consumed that could be used by the plug-in or host application

Engineering Contradiction:

Improvepiracy protectionVSAvoidprocessor cycles and memory

Core Design Contradiction:

ReliabilityVSUse of energy by moving object

Solution Approach 1:

The anti-piracy protection mechanism is extracted from the plug-in code itself and implemented as part of the network service infrastructure on the server side. This separates the protection logic from the audio processing functionality, allowing the plug-in to execute with full performance while security measures operate independently in the distributed environment.

Inventive Principle:

Principle #2Taking out (Extraction)

Data Source

PatentUS11789689B2Processing digital audio using audio processing plug-ins executing in a distributed computing environment

Publication Date: 2023.10.17 MICROSOFT TECHNOLOGY LICENSING LLC

AI summary

An audio processing plug-in shim operates in conjunction with a plug-in host application executing on a computing device. The plug-in shim receives a stream of digital audio from the plug-in host application and transmits the digital audio to a network service executing in a network accessible remote distributed computing environment. The network service receives the digital audio and routes the digital audio to one or more audio processing plug-ins, also executing in the distributed computing environment. The audio plug-ins process the digital audio, such as by applying digital signal processing techniques to the digital audio, and return processed audio to the network service. The network service returns the processed audio to the plug-in shim executing on the remote computing device. The plug-in shim, in turn, receives the processed audio from the network service and provides the processed audio to the plug-in host application.