Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Support for workloads with response time requirements (realtime)

Aperta
  • Qualcosa non va?
#898 4 commenti 3 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
8/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Ferma
Ambito
audio-video-rtc, performance

Direzione di ricerca

This is a spec-level design discussion in the Bikeshed source of the WebNN specification, not a code task. It proposes workload priority or periodicity hints on the WebNN context or graph execution path, and asks whether the change needs spec text or only an API addition. Reading the issue thread and the existing scheduling-related spec sections is the first step; done would mean a maintainer-agreed design direction, which needs spec-level expertise.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Consider an RTC-style web app concurrently running a collection of ML workloads of various response requirements. Assume that there aren't capacity issues (the system as a whole has enough HP to execute the workload on average).

Workload Period/response requirement Job completion delay
Audio capture processing (denoising etc) 50 Hz 25%
Video capture processing (eg background blur) 30 Hz 10-30%
WebSpeech 500ms? (continuous)
LLM Bursty Bursty

Without proper WebNN consideration of these requirements there are concerns that the UA will make poor scheduling decisions, causing the system to miss deadlines. The effects:

  • robo-sound
  • audio glitches
  • dropped video frames
  • janky video
  • increased end-to-end delay (since receiver jitterbuffers need to bump target delay to account for the problems).

The ideal state is that the system manages to understand the requirements. With the right scheduling decisions, LLM queries will be belated a little and possibly the latency of WebSpeech will go up, but as a whole it manages to meet the expectations in a good way.

Assuming the backend frameworks are capable of supporting workload prioritization, I see some options to help this case

  1. Equip the WebNN API with hints on the workload passed.
  2. Auto-detect the type of processing. For example, when audio or video capture wakes a worker it could transport a token containing periodicity info and let that influence scheduling decisions in the WebNN backend.

My guess is both need spec updates? Or maybe just the first option?

See also crbug.com/456006123 for repros of related issues with other tech than WebNN. Also note this issue is not asking for ways to understand total system capacity as this is impossible to compute without trying workloads out.

Lingua principale
Bikeshed
Stelle
566
Fork
72
Merge medio
6g 5h
PR unite (30g)
1

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di webmachinelearning/webnn

Tutte le issue di webmachinelearning/webnn

Issue simili

Altre issue su Audio/Video & RTC

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.