Meeting-Notetaker ohne Bot bauen: Anleitung

Kurz gesagt: Lass die Meeting-Plattform links liegen und nimm den Computer auf. Erfasse zwei lokale Streams, das Mikrofon und das Systemaudio, das der Call abspielt (ScreenCaptureKit oder Core Audio Taps auf macOS, WASAPI-Loopback auf Windows, ein PulseAudio- oder PipeWire-Monitor auf Linux), schick sie an eine Speech-to-Text-API und fasse das Transkript mit einem LLM zusammen. Kein Teilnehmer tritt dem Call bei.

Diese Anleitung richtet sich an Entwickler, die so etwas bauen wollen, oder die verstehen möchten, was ihr bezahlter Notetaker eigentlich tut. Sie behandelt die zwei Architekturen, die lokale Aufnahme auf jedem Betriebssystem samt der jeweils nötigen Berechtigung, dann Transkription, Zusammenfassungen, Speicherung und Einwilligung. Jede genannte API stammt aus der Dokumentation des Herstellers, am Ende aufgelistet und am 2026-10-21 geprüft.

Es gibt zwei Wege an Meeting-Audio. Ein Bot ist ein serverseitiger Client, der dem Call als Teilnehmer beitritt und die Medien von der Plattform erhält. Lokale Aufnahme läuft auf dem Computer der Person und nimmt auf, was dieser Computer ohnehin hört: das Mikrofon für die eigene Stimme und die Systemausgabe für alle anderen. Eine neuere Zwischenlösung sind Medien-APIs der Plattformen, die ein Meeting an deinen Server streamen, aber jede gilt nur für eine Plattform.

• Zoom: Das Meeting SDK tritt Meetings bei und gibt auf nativen Plattformen direkten Zugriff auf rohes Audio und Video. Laut Zooms Doku müssen Apps, die ab dem 2. März 2026 Meetings außerhalb ihres eigenen Kontos beitreten, mit ZAK- oder OBF-Tokens autorisiert sein oder RTMS nutzen.
• Zoom RTMS (Realtime Media Streams) liefert Live-Audio, Video und Transkriptdaten ohne Teilnehmer-Bot an deine App und läuft über bei Zoom gekaufte Credits. Es gilt nur für Zoom.
• Microsoft Teams: Echtzeit-Audio braucht einen application-hosted media bot in C# oder .NET, im Produktivbetrieb auf Windows Server in Azure, mit einer öffentlichen IP-Adresse pro VM-Instanz. Microsoft bezeichnet seine Echtzeit-Medienplattform weiterhin als Developer Preview.
• Google Meet: Die Meet Media API liefert Echtzeit-Audio, Video und Teilnehmerdaten, ist aber in der Developer Preview und nimmt laut Googles Doku keine neuen Anmeldungen mehr an. Jemand im Call muss zustimmen, und verschlüsselte oder mit Wasserzeichen versehene Meetings können sich nicht verbinden.

Nichts davon ist falsch. Es sind nur drei Integrationen mit drei Freigabewegen, und die Teilnehmenden sehen einen Bot oder einen Zustimmungsdialog. Wer einen Aufnahmeweg will, der auf jeder Plattform gleich funktioniert, dazu bei Präsenzmeetings und Telefonaten am Laptop, nimmt lokal auf.

Ein lokaler Notetaker nimmt zwei Eingänge gleichzeitig auf: das Mikrofon (die Person selbst) und einen Loopback der Systemausgabe (die anderen, so wie die Meeting-App sie abspielt). Halte beide so lange wie möglich als getrennte Kanäle. Die Trennung ist kostenlose Sprechertrennung, denn alles auf dem Mikrofonkanal ist die Person selbst. Sie hilft auch gegen Echo: Laut Microsofts Doku gibt es den WASAPI-Loopback vor allem für die akustische Echounterdrückung. Läuft der Call über Laptop-Lautsprecher, hört das Mikrofon die entfernten Stimmen mit, also brauchst du Echounterdrückung auf dem Mikrofon (im Browser das echoCancellation-Constraint von getUserMedia), sonst steht jeder Satz der Gegenseite doppelt im Transkript.

• ScreenCaptureKit streamt Bildschirminhalte und Audio. Setze capturesAudio in SCStreamConfiguration auf true (ab macOS 13); captureMicrophone nimmt ab macOS 15 das Mikrofon im selben Stream mit. Nötig sind die Berechtigung zur Bildschirmaufnahme und ein NSScreenCaptureUsageDescription-Schlüssel in der Info.plist.
• Core Audio Taps (ab macOS 14.2) erfassen ausgehendes Audio eines Prozesses, einer Prozessgruppe oder des ganzen Systems. Beschreibe den Tap mit CATapDescription, erzeuge ihn mit AudioHardwareCreateProcessTap, füge ihn einem mit AudioHardwareCreateAggregateDevice erstellten Aggregatgerät hinzu und lies dieses Gerät wie ein Mikrofon.
• Taps brauchen einen NSAudioCaptureUsageDescription-Schlüssel. Beim ersten Aufnehmen von einem Aggregatgerät mit Tap fragt macOS nach der Berechtigung zur Aufnahme von Systemaudio. Verwaltet wird sie unter Systemeinstellungen, Datenschutz & Sicherheit, Bildschirm- & Systemaudioaufnahme, wo eine App auch nur für Audio freigegeben werden kann.
• Das Mikrofon ist eine eigene Berechtigung mit eigenem Hinweistext. Plane das Onboarding für beide Dialoge, und für die Person, die einmal auf Ablehnen geklickt hat und jetzt nichts hört.

• Öffne den Wiedergabe-Endpunkt (eRender statt eCapture in GetDefaultAudioEndpoint) und initialisiere einen Aufnahmestream im Shared Mode mit AUDCLNT_STREAMFLAGS_LOOPBACK. Streams im Exclusive Mode können nicht im Loopback laufen.
• Der Loopback enthält den gesamten Mix dieses Endpunkts, nicht nur die Meeting-App, also landen auch Benachrichtigungstöne und Musik in der Aufnahme.
• Ereignisgesteuerter Loopback funktioniert ab Windows 10 Version 1703; ältere Builds brauchen einen von Microsoft dokumentierten Umweg über einen Wiedergabestream.
• Process Loopback (AUDIOCLIENT_ACTIVATION_TYPE_PROCESS_LOOPBACK über ActivateAudioInterfaceAsync) schließt das Audio eines Prozesses und seiner Kindprozesse ein oder aus, etwa um die Töne deiner eigenen App herauszuhalten. Mindestens nötig ist Windows 10 Build 20348, also per Feature-Erkennung prüfen und sonst auf Endpunkt-Loopback zurückfallen.
• Ein vertrauenswürdiger Audiotreiber lässt keinen Loopback von DRM-geschützten Streams zu. Microsofts Loopback-Doku beschreibt keinen Nutzerdialog wie auf macOS, deshalb sind deine eigene Aufnahmeanzeige und dein Einwilligungsablauf umso wichtiger.

• In PulseAudio hat jedes Ausgabegerät (Sink) eine Monitor-Quelle, die trägt, was der Sink abspielt. Nimm den Monitor des Standard-Sinks für das Call-Audio auf und die Standardquelle für das Mikrofon.
• Die meisten aktuellen Distributionen nutzen PipeWire mit pipewire-pulse, laut PipeWire-Doku ein Drop-in-Ersatz für den PulseAudio-Daemon, also funktioniert Code gegen die PulseAudio-API weiter.
• Nativ in PipeWire liest ein Aufnahmestream die Monitor-Ports eines Sinks, wenn du stream.capture.sink = true setzt und target.object auf den Namen des Sinks richtest, wie die Beispielkonfiguration des Loopback-Moduls zeigt.
• Zwei Probleme aus der Praxis: Ein System mit reinem ALSA ohne Soundserver hat gar keinen Monitor, und eine stummgeschaltete Ausgabe kann einen Monitor voller Stille liefern. Miss den Pegel und warne die Person, statt Stille zu transkribieren.

Schick das Audio während des Meetings über einen WebSocket an eine Streaming-Speech-to-Text-API, dann ist das Transkript am Ende fertig. Batch-APIs sind einfacher und reichen, wenn niemand Live-Text braucht. Diese Entscheidungen zählen mehr als die Wahl des Anbieters:

• Zwei Kanäle rein, zwei Transkripte raus. Transkribiere Mikrofon und Systemaudio getrennt (oder als einen Mehrkanal-Stream, falls deine API das kann) und füge sie per Zeitstempel zusammen. Billiger bekommst du Sprechertrennung nie.
• Sprechertrennung liefert Nummern, keine Namen. Die Doku von Deepgram etwa gibt pro Wort einen nummerierten Sprecher zurück (Sprecher 0, Sprecher 1) und überlässt die Zuordnung zu Personen deiner App; im Streaming-Modus gibt es keine Konfidenz pro Wort. Für Namen brauchst du ein zweites Signal: Der Mikrofonkanal ist die Person selbst, die Kalendereinladung listet die Teilnehmenden, und die Oberfläche der Meeting-App weiß, wer spricht.
• Sprechertrennung läuft auf dem Systemkanal, also einem gemischten Signal aller entfernten Stimmen nach dem Codec der Meeting-App. Rechne mit zusammengelegten Sprechern, wenn zwei Personen ähnlich klingen oder durcheinanderreden.
• Sprachen: Prüfe die Sprachliste und ob die automatische Erkennung mitten im Meeting funktioniert. Ein falscher Sprachhinweis schadet einem Transkript mehr als ein etwas schwächeres Modell.
• Wiederverbindung: Netze brechen ab. Puffere Audio lokal und sende es nach dem Wiederverbinden nach, sonst fehlt genau die Minute, in der entschieden wurde.

• Schick das vollständige Transkript mit Zeitstempeln und Sprecherlabels, keinen gekürzten Auszug. Aktuelle Modelle haben große Kontextfenster; teile nur, wenn ein Meeting länger ist als das Fenster.
• Fordere eine prüfbare Struktur an: Entscheidungen, Aufgaben mit verantwortlicher Person und Datum, offene Fragen. Jeder Punkt sollte sich auf einen Zeitstempel zurückführen lassen.
• Bewahre Transkript und Audio neben der Zusammenfassung auf. Eine LLM-Zusammenfassung kann etwas behaupten, das niemand gesagt hat; die Lösung ist eine schnelle Prüfung, nicht Vertrauen ins Modell.
• Erzeuge die Zusammenfassung nach dem Meeting und markiere sie als veraltet, wenn jemand das Transkript bearbeitet.

• Audio und Transkripte sind personenbezogene Daten. Verschlüssele sie im Ruhezustand, mach Notizen standardmäßig privat und lege die Aufbewahrung vor dem Start fest, inklusive wie eine Person eine Aufnahme löscht.
• Bei Nutzern in der EU: Wisse, wo Audio und Transkripte liegen und welche Auftragsverarbeiter (Speech-to-Text, LLM) sie sehen, und schreib das in deine Datenschutzerklärung.
• Kein Bot heißt: Niemand wird angekündigt. Zeig eine deutliche Aufnahmeanzeige, erinnere die Person daran, die Teilnehmenden zu informieren, und biete einen Hinweis in einer Zeile an, den sie in den Meeting-Chat kopieren kann. Mehrere US-Bundesstaaten verlangen die Zustimmung aller Beteiligten, und viele Länder haben eigene Regeln. Das ist keine Rechtsberatung.
• Verkaufe lokale Aufnahme nicht als lokale Verarbeitung. Wenn Audio an eine Cloud-Speech-to-Text-API geht, sag das.

1. Erkenne ein Meeting (ein Kalendertermin beginnt oder eine Meeting-App nutzt das Mikrofon), oder lass die Person auf Aufnahme drücken.
2. Frage beim ersten Mal nach Mikrofon- und Systemaudio-Berechtigung und erkläre in einem Satz, warum.
3. Starte zwei Aufnahmen: Mikrofon und System-Loopback. Miss beide Pegel und warne, wenn einer länger als ein paar Sekunden stumm bleibt.
4. Wandle das Audio in das Format um, das dein Speech-to-Text-Anbieter erwartet (Abtastrate und Kodierung stehen in seiner Doku), und streame es, mit lokalem Puffer für Wiederverbindungen.
5. Zeig das Live-Transkript: Füge beide Kanäle per Zeitstempel zusammen und kennzeichne den Mikrofonkanal als die Person selbst.
6. Beim Stoppen die Puffer leeren, den Stream schließen und das Audio mit dem fertigen Transkript speichern.
7. Schick das ganze Transkript an das LLM für Zusammenfassung und Aufgaben und speichere sie mit Verweisen auf die Zeitstempel.
8. Stell das Ergebnis bereit: eine Oberfläche, eine API, Webhooks oder einen MCP-Server, damit KI-Assistenten es lesen können.

• Die Berechtigungsführung auf macOS, und Personen, die einmal Nein gesagt haben.
• Gerätewechsel mitten im Call: Kopfhörer eingesteckt, Bluetooth wechselt ins Headset-Profil, die Standardausgabe ändert sich.
• Codesignierung und Notarisierung für Installer unter macOS und Windows, dazu automatische Updates.
• Ruhezustand, zugeklappter Deckel und zweistündige Meetings, plus Speicher- und Plattenverbrauch bei langen Calls.
• Echo über Laptop-Lautsprecher, und Stille bei stummgeschalteter Ausgabe.

Wenn du Meeting-Notizen brauchst und kein Notetaker-Projekt, Reline (reline.so) setzt genau diese Architektur bereits um. Die Desktop-App für macOS, Windows und Linux (Beta) nimmt Mikrofon und Systemaudio lokal auf, ohne Bot im Call, und die Web-App erfasst das Call-Audio in Chrome oder Edge am Desktop über das Audio der Bildschirmfreigabe. Transkription (über 60 Sprachen), KI-Zusammenfassungen und Speicherung laufen in der Cloud: ohne Bot, aber nicht auf dem Gerät.

Für Entwickler, die die Daten wollen statt der App: Reline betreibt einen MCP-Server unter https://mcp.reline.so/mcp, über den Claude, ChatGPT, Cursor und andere Clients Notizen durchsuchen, Transkripte und Aufgaben lesen und Notizen anlegen, angemeldet per OAuth oder mit einem Workspace-API-Schlüssel. Signierte Webhooks feuern bei sechs Ereignissen, etwa note.created, note.summarized und action_items.extracted, mit einer HMAC-SHA256-Signatur über Zeitstempel und unveränderten Body.

• Apple, Capturing system audio with Core Audio taps: https://developer.apple.com/documentation/coreaudio/capturing-system-audio-with-core-audio-taps
• Apple, ScreenCaptureKit: https://developer.apple.com/documentation/screencapturekit
• Apple Support, Control access to screen and system audio recording on Mac: https://support.apple.com/guide/mac-help/mchld6aa7d23/mac
• Microsoft, Loopback Recording (WASAPI): https://learn.microsoft.com/windows/win32/coreaudio/loopback-recording
• Microsoft, AUDIOCLIENT_ACTIVATION_TYPE: https://learn.microsoft.com/windows/win32/api/audioclientactivationparams/ne-audioclientactivationparams-audioclient_activation_type
• Microsoft, Build application-hosted media bots (Teams): https://learn.microsoft.com/microsoftteams/platform/bots/calls-and-meetings/requirements-considerations-application-hosted-media-bots
• MDN, MediaDevices.getDisplayMedia(): https://developer.mozilla.org/docs/Web/API/MediaDevices/getDisplayMedia
• PulseAudio, pa_sink_info (monitor_source): https://freedesktop.org/software/pulseaudio/doxygen/structpa__sink__info.html
• PipeWire, pipewire-pulse: https://docs.pipewire.org/page_man_pipewire-pulse_1.html
• PipeWire, Loopback module: https://docs.pipewire.org/page_module_loopback.html
• Zoom, Meeting SDK: https://developers.zoom.us/docs/meeting-sdk/
• Zoom, Realtime Media Streams (RTMS): https://developers.zoom.us/docs/rtms/
• Google, Meet Media API overview: https://developers.google.com/workspace/meet/media-api/guides/overview
• Deepgram documentation (speaker labels per word): https://developers.deepgram.com/docs