Read the Axis audio plugin schema before changing its settings

Bottom line: Use the installed plugin’s own schema as the setting contract. Keep the exact device, input or output and plugin identity together so a familiar threshold name does not substitute for the correct property definition.

Source fact: documented behavior

Axis’s Audio Analytics gives each audio plugin its own settings object and provides getPluginsSchemas to describe those settings.

getPluginsSettings retrieves configured audio-plugin settings across audio sources; the source says their properties are plugin specific and defined by the returned JSON schema.

The documentation separates Audio Analytics configuration from Audio Device Control, which configures the hardware devices.

What the source does not establish

Do not infer that two plugins share property names, units, valid ranges or detection performance. Treat sample settings as examples rather than a compatibility list. Keep microphone power and other hardware changes outside this plugin-setting procedure, and do not describe a valid settings object as proof of an accurate analytic result.

Applicability questions

• Which installed plugin and actual input or output are being changed?
• Which schema describes that exact plugin’s settings?
• What current property, type, unit and permitted value are relevant?
• What approved acoustic observation will assess the intended result separately from configuration acceptance?

DSE recommendation: controlled next steps

The following steps are DSE recommendations based on the cited source.

DSE recommends reviewing the current settings against the matching plugin schema before constructing an update.

1. Retrieve the supported schema and settings responses from the target device. Match the device, input or output and plugin identifiers before reviewing individual properties. Record the intended change and preserve the current settings. If the plugin or property cannot be matched to its schema, stop and resolve that identity issue rather than borrowing a nearby example.
2. Have the integration owner review the selected property’s type, limits and description from the actual schema. Use a harmless proposed value within the documented requirements for a pilot. Keep unit interpretation explicit; avoid assuming that a number meaningful to another analytic or interface has the same meaning here. Construct the supported update without changing unrelated hardware settings.
3. Apply the approved plugin change and retrieve its settings again. Compare the readback with the intended update before evaluating acoustic behavior. Use the owner’s authorized harmless input and an appropriate observation window for the separate functional check. If configuration or behavior is unresolved, retain the discrepancy and use the supported restoration process instead of experimenting across several plugins simultaneously.

Verification and evidence

Retain the schema revision or complete returned schema, exact plugin path, previous and requested settings, sanitized operation result and readback. Keep acoustic observations separately attributed to the actual test conditions. Have a reviewer explain the chosen unit and limit from the correct schema rather than from memory.

Include a proposed desk case with a property copied from a different plugin and require the reviewer to identify the mismatch. Record actual outcomes only after the approved pilot. This article supplies no universal threshold, supported-plugin inventory or measured classification or detection accuracy.

Official references

• Audio Analytics — Axis Communications; official VAPIX documentation.

Source review completed October 29, 2026. Recheck the official documentation and the deployed device’s capabilities before changing production settings.