Windows on Arm: In box USB Audio 2 Driver with Native ASIO

Microsoft’s move to build a native, low‑latency USB Audio Class 2 driver that exposes an ASIO interface for Windows on Arm marks one of the most consequential platform-level changes for music production on Windows in years — it promises plug‑and‑play ASIO on Arm64 systems while changing how vendors, DAWs, and end users will approach driver support and compatibility.

Background / Overview​

Microsoft’s engineering team announced a project to create a brand‑new, in‑box USB Audio Class 2 driver for Windows that includes both WaveRT endpoints and a native ASIO interface, developed in collaboration with Qualcomm and Yamaha. The stated aim is to deliver an option optimized for low‑latency musician scenarios and high I/O counts, with the first target being Arm64 devices and x86‑64 to follow after maturity checks. For decades, professional audio on Windows has relied on ASIO (Audio Stream Input/Output) to achieve predictable, low round‑trip latencies for DAWs, live monitoring, and instrument performance. Historically, ASIO access on Windows required vendor‑supplied kernel drivers, which created friction for plug‑and‑play workflows and left many class‑compliant devices reliant on third‑party wrappers or legacy drivers. Microsoft’s plan is to reduce that friction by providing a robust platform implementation that can be shipped in‑box with Windows.

---

What Microsoft announced (the technical summary)​

The driver architecture — what to expect​

• A USB Audio Class 2 class driver that continues to support existing class‑compliant devices while offering a low‑latency mode targeted at musicians.
• An ASIO interface alongside WaveRT so DAWs can access hardware with minimal intermediate buffering.
• Implementation built using the ACX framework (modern Windows driver model), with attention to power management on modern Arm CPUs — an important consideration for mobile laptops.

Microsoft also committed to publishing the class driver source on GitHub, mirroring recent open approaches for other music subsystems like the new MIDI stack. That open‑source release is intended to be a learning and collaboration scaffold for hardware vendors and the community.

Key capabilities Microsoft has signalled​

• Support for class‑compliant USB Audio Class 2 devices out of the box.
• An option or driver mode optimized for low round‑trip latency and high channel counts.
• The ability, where possible, for Windows and a DAW to use the same interface concurrently (reducing the long-standing single‑app lock that made some workflows painful).

---

Why this matters: the practical implications for musicians and studios​

Lower friction onboarding​

For many musicians and engineers, the most immediate benefit is simplified setup: plug in a USB Audio Class 2 device and get ASIO‑grade access without hunting vendor installers. That changes field‑recording, live‑performance, and second‑machine workflows where quick setup is essential. Reduced friction could also improve the adoption rate of Arm‑based laptops for on‑the‑road creatives.

Reduced driver fragmentation​

Publishing a high‑quality, open reference reduces the burden on smaller vendors who historically lacked resources to produce and maintain kernel drivers across architectures. Vendors can still ship optimized drivers for advanced features or absolute lowest latency, but baseline compatibility should rise significantly. This is a platform‑level win for long‑tail and legacy devices.

Better multi‑app and live workflows​

Microsoft’s design explicitly contemplates scenarios where system audio and a DAW share the device simultaneously — useful for streaming musicians who need system sounds, conference audio, or browser playback to coexist with a DAW session without device‑hand‑offs. This will reduce the number of workflow workarounds professionals currently depend on.

---

Ecosystem response: hardware vendors and DAWs​

Vendors shipping Arm64 support now​

Several major audio vendors have already published Arm64 drivers or previews to align with the platform shift. Focusrite, for example, published Arm64 drivers across its USB interface lineup and explicitly called out Windows on Arm compatibility as available via downloads and release notes, illustrating vendor readiness to support Arm‑native drivers. Steinberg (Yamaha) also posted Arm64 preview builds for key DAW software and signaled driver previews, reflecting a coordinated industry effort to make Arm64 a first‑class citizen for audio production workflows.

DAW support and the plugin matrix​

Early Arm64 previews of major DAWs (Cubase, Nuendo, REAPER, Bitwig, and other ports) reduce emulation overhead and unlock platform efficiency, but plugin compatibility remains the biggest wild card. Many plugins — especially older or non‑updated binaries — may still run under emulation or require bridging. That means studios should continue validating plugin chains on Arm64 before committing mission‑critical sessions.

Claims to treat carefully​

There are repeated industry mentions that Ableton Live will launch an Arm64 version in 2026. that claim has proliferated in coverage, but at the time of writing there is no public, verifiable Ableton announcement explicitly committing to a 2026 Arm64 Windows release. Treat the Ableton 2026 claim as plausible industry speculation rather than a confirmed shipping date, and confirm directly with Ableton for production timelines.

---

Timeline and what “in‑box” means​

Microsoft’s stated milestones​

Microsoft has said previews of the new in‑box driver will appear throughout 2025, with the initial target being Arm64 devices and follow‑up x86‑64 ports after quality validation. The company has been careful not to hard‑commit to an exact retail ship date, instead promising to ship the driver in‑box “when we reach our quality targets.”

Why 2026 shows up in coverage​

Independent outlets and analyst timelines have reasonably tied broader OEM preload or retail prominence to 2026, linked to the next wave of Arm silicon and Windows refresh cycles (for example new Snapdragon X Elite platforms and Windows 11 refreshes). Those retail timing ties are plausible — OEM image refresh schedules and silicon launches commonly determine when a new in‑box component appears on shipping hardware — but they are not an explicit Microsoft promise of a 2026 date. In short: previews in 2025, wider OEM preload or retail presence likely in 2026, but not guaranteed as a single global ship date.

---

Technical tradeoffs and performance realities​

Latency vs. battery life and thermal envelope​

Achieving single‑digit millisecond round‑trip latency requires frequent small buffer fills, which increases CPU wakeups and power draw — a real constraint on battery‑focused Arm laptops. The kernel, driver, scheduler, and SoC power management layers must be tuned to balance latency with practical battery life and thermal limits. Microsoft acknowledges these tradeoffs and plans to expose options optimized for musician scenarios rather than a single one‑size‑fits‑all mode. Expect per‑device tuning and vendor guidance for optimal results.

Why vendor drivers will still matter​

An in‑box class driver aims to cover the majority of class‑compliant features and ensure broad compatibility, but premium vendor drivers can and will deliver the “last mile” of performance: firmware‑assisted monitoring, DSP offload, proprietary routing, and highly tuned interrupt handling. For pro rigs and broadcast/live use, vendor drivers and hardware control panels will remain essential for achieving absolute lowest latency and deterministic behavior.

ASIO is a tool, not a panacea​

ASIO is a highly effective block‑level interface for low‑latency audio, but it does not natively address features like device aggregation, complex routing, or multi‑client orchestration. Microsoft’s approach is pragmatic — provide ASIO support where musicians already rely on it, then iterate on APIs and drivers for the advanced scenarios. Expect additional platform work to follow for those advanced use cases.

---

Security, update cadence, and maintainability​

Shipping a kernel driver in‑box makes Microsoft responsible for its maintenance surface area: code quality, security patching, and Windows servicing cadence all matter. The plan to publish the class driver source on GitHub improves transparency and allows vendor feedback and audits, but it doesn’t remove the need for rigorous QA and fast update paths when regressions are discovered. In‑box drivers will be updated via Windows servicing channels, which helps distribution but amplifies the importance of pre‑release testing to avoid systemic regressions.

---

How professionals and studios should prepare — a practical checklist​

• Inventory audio gear and confirm whether your interfaces are USB Audio Class 2 compliant. Class‑compliant devices are the prime candidates for the in‑box driver.
• For mission‑critical live and broadcast setups, retain vendor drivers and test them against preview drivers—don’t rely on a single new stack until it’s verified end‑to‑end.
• Prioritize Arm64 systems with proven thermal design and high‑performance SoCs (for example Snapdragon X‑class family) for sustained low‑latency workloads.
• Start testing now with vendor Arm64 preview drivers and Arm‑native DAW builds where available to identify plugin compatibility gaps and performance hotspots. Steinberg and Focusrite have already published previews and drivers to help with validation.
• Measure round‑trip latency, CPU load, and stability under real projects. Use consistent test patches and buffering scenarios to compare vendor drivers vs. the in‑box preview.

---

Developer and vendor opportunities​

• Publishing the in‑box class driver source provides a reference implementation vendors can study and adapt. This lowers the barrier for smaller manufacturers and hobbyist projects that previously could not maintain kernel drivers for multiple architectures.
• DAW and plugin developers should prioritize Arm64 native builds or Arm64EC bridge strategies for critical plugin chains to avoid emulation performance cliffs. Microsoft’s initiative reduces one layer of friction — the audio driver — but plugin compatibility remains a developer task.
• Driver authors can use the published implementation as a starting point for device‑specific optimisations, focusing QE for power‑vs‑latency tradeoffs and advanced routing features that a generic class driver can’t provide.

---

Risks, limitations, and open questions​

• Timing uncertainty: Microsoft committed to previews in 2025 and Arm64 first, but the notion that the driver will fully appear in shipping retail images in 2026 is an industry inference tied to hardware and OS refresh cycles, not a formal Microsoft ship date guarantee. Plan purchases and critical rollouts conservatively.
• Power and thermals: Achieving the lowest possible latency on a thin, battery‑conscious laptop will require tradeoffs; expect per‑device guidance from OEMs and SoC partners.
• Plugin compatibility: The heterogeneity of VST/AU/AAX ecosystems means many plugins require explicit porting or testing; legacy x86‑only binaries may run under emulation but with potential performance/behavior differences. Comprehensive compatibility testing remains essential.
• Vendor ecosystems: Some vendors may still prefer shipping their own kernel drivers for parity and features; the in‑box driver is not a forced replacement but a baseline solution. Expect a hybrid world where both in‑box and vendor drivers coexist.
• Unverified claims: Repeated press statements and aggregators have suggested Ableton Live will ship a native Arm64 Windows version in 2026; that claim appears in secondary coverage but lacks an official Ableton public confirmation at the time of reporting and should be treated as speculative. Validate such major app roadmaps directly with vendors before relying on them for project planning.

---

Early hands‑on expectations and recommended test scenarios​

• Use a simple latency measurement chain: DAW → Direct monitor off → audio loopback (if hardware supports) → measure round‑trip using a known test patch. Compare vendor Arm64 drivers vs. Microsoft preview driver under identical buffer sizes.
• Stress test high channel counts (multi‑mic capture, multi‑output monitoring) to identify CPU scaling and thermal throttling thresholds on candidate Arm64 laptops.
• Test mixed multi‑app workflows (DAW + streaming encoder + Teams/Zoom) to ensure the driver’s multi‑client semantics match real user scenarios.
• For live use, run the driver through a full‑performance dress rehearsal on battery power and AC power to observe differences in CPU frequency scaling and audio stability.

---

Verdict: meaningful progress with pragmatic caveats​

Microsoft’s in‑box low‑latency USB Audio Class 2 driver with a native ASIO interface is a strategic and pragmatic move that removes a major usability hurdle for Windows on Arm. The partnership with Qualcomm and Yamaha, the public GitHub intent, and vendor Arm64 drivers from players like Focusrite and Steinberg together paint a picture of coordinated ecosystem maturation. For many users, this reduces friction, improves plug‑and‑play expectations, and strengthens Arm64’s position as a viable platform for professional audio work. At the same time, the professional audio ecosystem is complex. Ultra‑low latency, absolute determinism, and advanced routing features still favor vendor drivers and careful per‑device QA. The path to broad retail availability will likely be staged, with previews in 2025 and wider OEM preorder/retail visibility likely clustered around 2026 platform refreshes — a plausible but not guaranteed timeline tied to hardware and OS refresh cycles.

---

Final recommendations for audio professionals and IT managers​

• Begin lab validations now: install vendor Arm64 drivers and early DAW previews where available, and run representative sessions to expose plugin and driver edge cases.
• Keep vendor drivers available as fallbacks for mission‑critical shows and recordings. The in‑box driver will lower friction but won’t eliminate the need for device‑specific optimizations.
• For procurement, prioritize Arm64 systems with robust thermal designs and high‑performance SoCs if you plan to rely on low‑latency workloads on battery.
• Track the Microsoft preview releases and GitHub repo as they appear; early feedback from professionals can materially shape stability and features before the in‑box ship.

Microsoft’s strategy addresses a longstanding pain point for professional audio on Windows and creates a clear runway for Arm64 to become a credible, studio‑capable platform — but the transition will be iterative, and studios should proceed with testing, fallbacks, and conservative rollout plans until the ecosystem fully matures.

---

Source: Windows Report Windows on Arm to Get Microsoft’s New Low-Latency Audio Driver in 2026

 

[ChatGPT]

Microsoft’s newest developer toolkit shifts the safety burden from individual studios to the platform level, promising built‑in controls for cheating, harassment, and inauthentic accounts while folding AI‑assisted moderation into the game stack so teams — from indie developers to AAA publishers — can scale trust and fairness across Xbox, Windows PC, and cloud play.

Background​

Online multiplayer games are no longer niche social experiments; they are large‑scale social platforms where millions gather, compete, cooperate, and — sometimes — harass and cheat. The result is a persistent operational problem for studios: policing text and voice chat; blocking cheaters, smurf accounts and botnets; responding quickly to abuse reports; and doing all of this without diverting engineering and community teams away from core game development.
Microsoft’s new Safety Tools are presented as a toolkit that addresses those pain points with four core pillars: trust signals at the account level, native reporting and player controls, moderation workflows for human teams, and small AI models to flag harmful voice and text early in the pipeline. The company positions this set of features as both an operational shortcut for developers and a trust guarantee for players — a move consistent with other platform‑level safety work Microsoft has published about enforcement and proactive moderation.

---

Why platform‑level safety tools matter​

The challenge studios face is both technical and economic. Large publishers can field dedicated trust & safety teams and build custom anti‑cheat infrastructure; most indie and mid‑sized teams cannot. A shared, well‑integrated set of safety primitives reduces duplicated effort, provides consistent user experiences, and raises the baseline cost for attackers.

• Platform tools cut integration time: developers can add native reporting and account signals rather than invent systems from scratch.
• Safety at scale needs automation: AI can triage obvious violations so human moderators focus on nuanced or high‑impact cases. Evidence from Xbox’s moderation programs shows automated systems can reduce human workload substantially when paired with human review.
• Fair play requires stronger signals: hardware and platform attestation (TPM, Secure Boot, VBS, remote attestation) provide stronger evidence about a client state than heuristics alone, making anti‑cheat systems harder to spoof.

These are the design tradeoffs Microsoft is addressing with the Safety Tools: give developers curated, battle‑tested primitives that solve the most common problems while allowing publishers to keep ownership of policy and enforcement choice.

---

What’s in the Safety Toolkit — feature breakdown​

Stronger account‑level trust signals​

Microsoft is exposing account‑level signals that developers can use to judge the level of trust to place in a player’s identity and device. These signals are intended to help with rapid enforcement decisions — for example, identifying multi‑account abusers, detecting account tampering, or surfacing suspicious behavior patterns earlier.

• Signals may include attestation of hardware/boot integrity (TPM, Secure Boot) and account provenance flags.
• These signals are usable at the server side so studios can apply progressive policies (soft restrictions, warnings, or outright bans) based on cumulative evidence.

Why this matters: stronger, cryptographically anchored indicators raise the technical cost for persistent cheat authors and make enforcement decisions more defensible. Microsoft and other major publishers have already begun requiring platform security baselines for competitive play; exposing these signals to developers accelerates that trend.

Native reporting and player controls​

Reporting is the front line of community health. Microsoft’s update emphasizes native, embeddable reporting primitives so developers don’t need third‑party tooling to accept and transmit player reports.

• Reports can carry structured metadata (timestamps, chat logs, voice context pointers) to speed human review.
• Players will get clearer choices to opt out of unwanted interactions (text, invites, friend requests), reducing friction for victims or vulnerable players.

This design reduces latency between an incident and action, and standardizes the format of evidence that moderation teams consume — a genuine win for both small teams and large studios that need consistent intake formats.

Moderation workflows and human review tools​

Automation is useful, but the hardest decisions still require humans. Microsoft’s toolkit includes tools for moderation teams to:

• Queue and triage reports in real time.
• See context‑rich incidents (chat transcripts, voice flags, account signals).
• Escalate severe abuse (hate speech, threats, scams) quickly to human investigators.

The underlying idea is a human + machine workflow: small models and heuristics remove the noise and highlight the highest‑risk items, while humans adjudicate edge cases and apply policy nuance. Evidence from Xbox’s moderation data shows such automation can dramatically improve removal speed for high‑volume categories and surface the incidents that warrant human attention.

AI‑powered, lightweight moderation models​

Microsoft specifically calls out the use of small AI models designed to run close to the game environment and flag harmful voice/text early.

• These models are intended for flagging rather than final enforcement: they prioritize recall for critical categories and feed human review.
• The company emphasizes that AI augments — not replaces — human teams, reducing reviewer workload while improving throughput.

Context and constraints: lightweight models are a pragmatic choice for real‑time pipelines (low latency, lower compute costs). But the tradeoffs include potential false positives, language coverage gaps, and the general limitations seen in toxicity detection research (bias, contextual mistakes). Multiple academic and industry projects show that adding contextual features (chat history, speaker metadata) improves moderation accuracy — a lesson Microsoft’s approach appears to incorporate.

---

Fair play — anti‑cheat integration and device attestations​

Cheating is often technical: kernel drivers, firmware hooks, and sophisticated toolchains can hide user‑mode cheats from traditional detection. Microsoft’s toolkit links safety signals with fair‑play systems so developers gain better evidence for enforcement:

• Platform attestation (TPM, Secure Boot, VBS) provides cryptographic measurements about boot and runtime integrity.
• Remote attestation to cloud services makes spoofing those signals more difficult and provides defensible forensic trails.
• The platform-level controls allow studios to tune enforcement thresholds — from soft mitigations to hard gates for competitive modes.

This approach is part of a wider industry movement: major publishers increasingly require platform security baselines for multiplayer titles. Making attestation signals available to developers reduces rework and helps smaller teams adopt the same protections as larger competitors. However, that same approach risks excluding players whose hardware or OS configuration cannot meet those baselines, and that exclusion must be managed thoughtfully.

---

Transparency, privacy, and the player experience​

Microsoft’s messaging stresses more transparency for players: visible safety rules, privacy choices, and clearer reporting flows. But important governance questions remain:

• How long are reported screenshots/audio retained and who can access them?
• Are account signals and attestation metadata logged long‑term, and how are they de‑identified?
• Do moderation models or flagged data feed back into model training, and what are opt‑out controls?

Microsoft’s broader Copilot and AI rollout experience shows these are not theoretical questions; platform teams must publish clear retention policies, consent and opt‑out settings, and documentation for account‑level telemetry. Players and community managers will expect granular controls and visible assurances about how data is used. Early platform features have been gated by age and region for a reason: risk management and regulatory variance across jurisdictions.

---

Independent verification and evidence​

Multiple independent outlets and platform documents back the key technical claims behind Microsoft’s Safety Tools:

• Xbox’s recent moderation reporting shows large numbers of proactively blocked messages and faster human review when AI triage is used, supporting the claim that automation materially reduces moderator workload.
• Platform enforcement (strike systems) is an established Xbox mechanism that complements the proposed developer controls, and public descriptions of enforcement‑strike systems demonstrate Microsoft’s operational playbook for graduated sanctions.
• Microsoft’s platform rules already permit automated checks for cheating/tampering; that contractual baseline explains how account/device signals can be collected and used for enforcement.

Academic work and industry tools further corroborate the technical feasibility and limitations of automated toxicity detection and voice moderation — outcomes Microsoft’s announcement references by design.

---

Strengths — what this announcement gets right​

• Operational leverage for developers. Providing out‑of‑the‑box reporting primitives and moderation workflows reduces duplicated engineering effort and lets studios focus on gameplay rather than building safety plumbing.
• A realistic AI posture. Microsoft frames AI as a triage and detection layer, not an adjudicator — the right balance to scale while keeping humans in control.
• Stronger evidence for fair play. Exposing attestation and hardware signals will blunt many cheat tactics and improve forensic capability, a clear long‑term win for competitive integrity.
• Accessibility for small teams. The toolkit lowers the barrier for safety, enabling indies to ship with modern moderation and reporting without building costly pipelines.

---

Risks, limits, and real‑world tradeoffs​

• Privacy and retention hazards. AI flagging and screenshot/voice capture create data custody questions. Without strong retention, access, and de‑identification policies, platforms risk user trust and regulatory scrutiny. Flag: request explicit retention and access documentation.
• False positives and context loss. Small models running in isolation can mislabel context‑dependent speech or in‑game banter. Human review reduces harm, but false positives still impose moderation cost and potential player churn. Flag: designers must tune thresholds and provide appeal paths.
• Hardware and inclusion gaps. Platform attestation advantages players on modern hardware and can disadvantage users with older or non‑Windows setups. Publishers should avoid hard gating for casual modes to prevent fragmentation.
• Performance on constrained devices. Real‑time voice capture and on‑device spotters can add CPU and battery overhead on handhelds and low‑end PCs — an important practical effect for many players.
• Platform lock‑in and ecosystem power. Deep integration with Xbox account signals and Microsoft services may increase platform lock‑in. Smaller platform‑agnostic middleware options still have a role for cross‑store titles. Flag: studios should plan for multi‑platform portability.

---

Practical guidance for developers (recommended checklist)​

• Inventory what you need: define the abuse vectors that most harm your title (toxic text, voice abuse, cheating, scams).
• Map Microsoft’s tools to your threat model: choose which account signals and reporting flows will be meaningful for your game.
• Start with non‑blocking deploys: roll AI triage into a human review queue first, then progressively automate low‑risk enforcement.
• Tune models with in‑game context: incorporate chat history and match metadata to reduce false positives.
• Communicate clearly to players: publish your moderation policy, retention times for evidence, and appeal processes.
• Provide accessible options: enable mute defaults, safe chat/friend limits, and a visible reporting path for victims.
• Measure and iterate: collect metrics (time‑to‑action, false positive rate, recidivism) and refine thresholds monthly.

These steps help teams adopt the tools quickly while protecting players and preserving developer control.

---

Implementation roadmap — a practical rollout approach​

• Enable native reporting primitives in a non‑production environment to validate data formats and retention.
• Connect account‑level signals and define enforcement tiers (warning → temporary social ban → feature ban).
• Add small model triage to flag high‑risk voice/text and pipeline flags into a moderator dashboard.
• Run a soft launch with community moderators and trusted players; collect telemetry on false positive/negative rates.
• Publish public safety rules and opt‑out settings before broad rollout.
• Expand to live enforcement once model performance and moderator workflows show stable error rates.

This incremental plan balances speed with caution, keeping human oversight central while reducing moderator load.

---

What to watch next (and where the unclear claims need scrutiny)​

• Rollout timing and regional availability: Microsoft has signaled staged rollouts for similar features; developers should confirm exact availability windows and age gating for Safety Tools in official documentation before planning launch dependencies. This kind of schedule can vary by region and is often updated; verify with Microsoft’s developer site.
• Technical details about on‑device inference vs. cloud processing: the privacy and performance implications hinge on whether small models run locally, in the cloud, or in hybrid mode. Microsoft’s public notes for other Copilot features reveal a hybrid approach is common, but explicit per‑feature documentation is required. Unverifiable claim: exact inference locality for the Safety Tools at general availability.
• Evidence and appeals mechanics: studios must ensure players have visible appeals and documentation about strikes and bans; the specifics of how an account signal contributes to a permanent enforcement action should be transparent to avoid fairness disputes.

---

Bigger picture — Microsoft’s long‑term safety bet and industry implications​

Microsoft’s move signals a broader platform shift: safety, fairness, and trust are becoming first‑class platform services rather than optional add‑ons. That has several implications:

• For players: better baseline protections, faster action on abusive behavior, and consistent reporting UX across titles.
• For small studios: access to enterprise‑grade safety tooling without building a trust & safety org from scratch.
• For anti‑cheat ecosystem: platform attestation will raise the bar for cheat authors, and third‑party anti‑cheat vendors must adapt to richer platform signals.
• For regulators and privacy advocates: increased platform data collection requires clear governance and transparency to avoid policy backlash.

If executed with robust transparency and player controls, these tools can meaningfully raise community health across millions of players. If executed without clear retention and consent rules, they risk eroding trust and drawing regulatory attention.

---

Conclusion​

Microsoft’s Safety Tools represent a pragmatic, platform‑level response to the twin problems of toxicity and cheating in online games. By combining account‑level trust signals, native reporting, human‑centric moderation workflows, and lightweight AI triage, the toolkit can materially reduce developer overhead while improving the speed and quality of enforcement. The approach is technically credible — platform attestation raises the cost of cheating and AI triage has demonstrable benefits for moderator throughput — but the real test will be in the details: data retention policies, transparency around model use, fairness of enforcement, and accommodations for players on older or alternative hardware. Developers should welcome the operational advantages while demanding precise documentation and clear player controls before making Safety Tools a central pillar of their community strategy.

---

Source: Techgenyz Microsoft Unveils Powerful New Safety Tools for Safer Gaming Communities