{"slug": "measuring-voice-agents-turn-taking-tool-calls-and-expressive-speech", "title": "Measuring voice agents: turn-taking, tool calls and expressive speech", "summary": "A benchmark comparison published on Hugging Face's full-duplex leaderboard measured voice agents on three separate abilities — end-of-turn detection (TurnBench), command/action selection (SLURP), and expressive speech (InstructTTSEval) — running local models on an Apple M5 Pro with 48 GiB of memory alongside cloud API configurations. On TurnBench's 5 development conversations and 238 turn ends, Neosapience Nunchi v2 and Vox Maru v1 each caught 96.6% of real turn endings with false-positive rates of 6.4% and 7.9%, while OpenAI GPT-Realtime-mini with server VAD (1.8 s silence) reached 82.3% recall at 4.5% FPR and Mimi endpointer hit the lowest FPR at 2.0% with 81.1% recall. The leaderboard ranks models by recall minus FPR, placing any configuration with an FPR above 15% below those meeting that limit.", "body_md": "# Measuring voice agents: turn-taking, tool calls and expressive speech\n\nA voice agent has to choose when to speak, which action to take, and how its reply should sound. We measured those decisions separately, using local models and cloud API configurations. The results help us choose components for private voice applications.\n\nIn our [earlier survey of full-duplex speech and tools](https://blog.ivan.digital/nvidia-nemotron-voicechat-on-apple-silicon-full-duplex-speech-with-tools-6165625d55c4), we followed a spoken request through listening, interruption, tool execution and synthesis. This post adds measurements. You can inspect the complete [leaderboard](https://huggingface.co/spaces/aufklarer/full-duplex-leaderboard) and the [saved snapshot behind these tables](https://huggingface.co/spaces/aufklarer/full-duplex-leaderboard/tree/b2eee60701b7d512312fdc5b83e71a2b6c45adf4).\n\n## Three measurements for three decisions\n\nTurnBench\n\n### When to speak\n\nTurn ends caught, false alarms and decision latency.\n\nSLURP commands\n\n### Which action to take\n\nCorrect action selection and argument accuracy.\n\nInstructTTSEval\n\n### How to sound\n\nFollowing a voice description, delivery direction or role.\n\nWe measure these three abilities separately. An assistant can wait for you to finish speaking and still choose the wrong tool. It can also speak clearly while missing the emotion or style you asked for.\n\nWe ran the local models on an Apple M5 Pro with 48 GiB of memory. For cloud services, we tested the model versions and settings listed in the results.\n\nEach section explains how many recordings we used, which languages we tested and any results still being checked. These details help you compare the scores.\n\n## TurnBench: when a pause is a turn end\n\n[TurnBench](https://www.sesame.com/journal/turnbench) distinguishes a speaker finishing from a pause inside a turn. It also distinguishes an interruption from a backchannel such as “mm-hmm.” Our table below focuses on end-of-turn detection.\n\nWe used TurnBench’s public development recordings and its own scoring code. The table shows the run size for each model. The official leaderboard uses a separate test set.\n\n**Recall** is the share of real turn endings the model detects. **FPR (false-positive rate)** is the share of labelled pauses within a turn that it incorrectly treats as the speaker finishing.\n\nOur leaderboard orders models by recall minus FPR. The [official test leaderboard](https://turnbench.sesame.com/) ranks models by recall, placing those with an FPR above 15% below those that meet the limit.\n\n| Our TurnBench development slices. Recall and FPR are percentages; latency is the median signed delay on detected events, in milliseconds. |  |  |  |  | \n|---|---|---|---|---|\n| Configuration | Recall ↑ | FPR ↓ | Median ms | Scope | \n|---|---|---|---|---|\n| Neosapience Nunchi v2Published predictions · rescored | 96.6% | 6.4% | 355 | 5 conversations; 238 turn ends · published predictions | \n| Vox Maru v1Published predictions · rescored | 96.6% | 7.9% | 830 | 5 conversations; 238 turn ends · published predictions | \n| p99 TurnBench system · published predictionsPublished predictions · rescored | 98.3% | 9.9% | 777 | 5 conversations; 238 turn ends · published predictions | \n| Zero Runtime Echo Omni DuplexPublished predictions · rescored | 98.3% | 12.9% | 867 | 5 conversations; 238 turn ends · published predictions | \n| VAPLocal CPU | 88.2% | 7.4% | 641 | 5 conversations; 238 turn ends | \n| Mimi endpointerLocal CPU | 81.1% | 2.0% | 1,011 | 5 conversations; 238 turn ends | \n| OpenAI GPT-Realtime-mini, server VAD (1.8 s silence)Cloud API | 82.3% | 4.5% | 2,005 | 5 conversations; 238 turn ends | \n| OpenAI GPT-Realtime-mini, semantic VAD (high eagerness)Cloud API | 83.6% | 7.4% | 2,437 | 5 conversations; 238 turn ends | \n| Parakeet EOU 120M + Silero VADOn device | 92.9% | 17.8% | 1,315 | 5 conversations; 238 turn ends | \n| Silero VAD + silence timeoutOn device | 92.4% | 17.8% | 1,317 | 5 conversations; 238 turn ends | \n| Smart Turn v3.2 + Silero VADOn device | 87.4% | 16.3% | 1,639 | 5 conversations; 238 turn ends | \n| ElevenLabs AgentsCloud API | 86.5% | 20.4% | 831 | 3 conversations; 193 turn ends | \n| Smart Turn v3On device | 88.2% | 24.3% | 1,031 | 5 conversations; 238 turn ends | \n| OpenAI GPT-Live-1Cloud API | 63.0% | 6.9% | 1,589 | 5 conversations; 238 turn ends | \n| Gemini 3.8 LiveCloud API | 60.1% | 10.9% | 1,239 | 5 conversations; 238 turn ends | \n| WavLM-Base causalLocal CPU | 54.6% | 13.9% | 573 | 5 conversations; 238 turn ends | \n| WavLM-Large causalLocal CPU | 53.4% | 17.3% | 586 | 5 conversations; 238 turn ends | \n\nWe added four TurnBench submissions by rescoring their published predictions on the same five conversations, without changing their decisions or rerunning their models. Nunchi v2 has the highest recall-minus-FPR score on this slice: 96.6% recall and 6.4% FPR. VAP reaches 88.2% recall with 7.4% FPR; Mimi makes fewer false detections, at 2.0%, but catches fewer turn endings and takes longer to decide.\n\n[VAP (Voice Activity Projection)](https://github.com/ErikEkstedt/VoiceActivityProjection) listens to both speakers on separate audio channels and predicts their upcoming speech activity. It uses the recent conversation to estimate whether the current speaker will continue or hand over to the other person. [Research on VAP](https://arxiv.org/abs/2209.05161) shows that it learns to use cues in the voice, such as pitch and rhythm.\n\nThe version we ran was trained further on 104 hours of conversational audio from [otoSpeech](https://arxiv.org/abs/2608.25218). Our interpretation is that this training and its view of both speakers help explain its strong result in our comparison.\n\n### New local exports: p99 and VAP\n\nWe tested three downloadable exports on two TurnBench development conversations: 148 turn endings and 94 pauses inside a turn. Each run used a fixed decision policy.\n\n| Matched export pilot · two conversations · Apple M5 Pro, 48 GiB · CPU |  |  | \n|---|---|---|\n| Export | Turn endings caught ↑ | False detections ↓ | \n|---|---|---|\n| [p99 turn-1-mini 5.3M (CoreML FP32) + Silero VAD](https://huggingface.co/aufklarer/P99-Turn-1-Mini-CoreML) | 90.5%134/148 | 16.0%15/94 | \n| [VAP OTO (CoreML FP32)](https://huggingface.co/aufklarer/VAP-OTO-CoreML) | 83.8%124/148 | 2.1%2/94 | \n| [VAP OTO (ONNX FP32)](https://huggingface.co/aufklarer/VAP-OTO-ONNX) | 83.8%124/148 | 2.1%2/94 | \n\nAt these settings, p99 caught ten more turn endings, while VAP made thirteen fewer false detections. We got the same event decisions from each export and its original checkpoint on the same audio. The [pilot protocol](https://huggingface.co/spaces/aufklarer/full-duplex-leaderboard/blob/b2eee60701b7d512312fdc5b83e71a2b6c45adf4/protocol/turn-exports.md) records the inputs and cutoffs.\n\nBoth models now have [speech-swift](https://github.com/soniqo/speech-swift) APIs. We also added VAP to the [C++](https://github.com/soniqo/speech-core) and [Android](https://github.com/soniqo/speech-android) runtimes. The [integration guide](https://soniqo.audio/guides/turn-models) covers downloads and audio inputs. Your application sets the response policy.\n\n## SLURP: choosing an action from spoken commands\n\n[SLURP](https://github.com/pswietojanski/slurp) contains spoken home-assistant requests with an annotated action and argument values. In our routing test, each recording comes with ten candidate actions and a no-action option.\n\nOur 1,000-recording setup includes 810 requests with the correct action available and 190 with that action withheld. We expect no action on those 190 requests. This checks whether the model declines a request when its action is unavailable.\n\nMost systems use 1,000 recordings, including close-talk and far-field audio. Far-mic accuracy measures correct choices on recordings made from farther away, when the requested tool is available. **Calls despite a missing tool** counts requests where the system returned an action even though the annotated tool was absent. It pools close-talk and far-field recordings, and does not measure activation from background speech or silence. The table shows the exact counts.\n\n| Our SLURP routing protocol. Far-mic accuracy uses supported far-field requests; missing-tool call rates pool headset and far-field requests with the annotated intent withheld. Argument match is shown only for systems returning arguments. |  |  |  |  | \n|---|---|---|---|---|\n| System | Far-mic accuracy ↑ | Calls despite missing tool ↓ | Arguments exact ↑ | Run size | \n|---|---|---|---|---|\n| OpenAI gpt-audio-1.5Cloud API | 83.0% | 42.6%81/190 | 44.7% | 1,000 recordings | \n| Amazon Nova 2.5 SonicCloud API | 75.9% | 18.9%36/190 | 45.4% | 1,000 recordings | \n| Parakeet → Gemma 4 E2BOn device | 75.2% | 46.3%88/190 | — | 1,000 recordings | \n| Parakeet → TypeSafe Jev 1.13Cloud API | 73.5% | 11.6%22/190 | — | 1,000 recordings | \n| Parakeet → GLiNER2.5-DecideOn device | 73.5% | 39.0%74/190 | — | 1,000 recordings | \n| Gemini 2.5 FlashCloud API | 73.0% | 17.4%33/190 | 40.6% | 1,000 recordings | \n| Liquid d1-omni 600MOn device | 72.8% | 69.0%131/190 | — | 1,000 recordings | \n| ElevenLabs AgentsCloud API | 66.7% | 28.6%2/7 | 41.9% | 50 recordings | \n| Mistral Voxtral Mini 3BOn device | 61.7% | 16.3%31/190 | 35.1% | 1,000 recordings | \n| NeuDecide 55MOn device | 56.5% | 89.5%170/190 | 34.9% | 1,000 recordings | \n| Parakeet → MiniLM routerOn device | 50.8% | 5.8%11/190 | — | 1,000 recordings | \n| Parakeet → FunctionGemma 270MOn device | 36.4% | 34.7%66/190 | 17.6% | 1,000 recordings | \n\nThe local Parakeet → Gemma 4 E2B pipeline reaches 75.2% far-mic accuracy, close to Nova’s 75.9% and behind GPT Audio’s 83.0%. But on the 190 requests whose correct tool was unavailable, Gemma still chose an action 88 times: its 46.3% false-activation rate. One example was “delete item”: with list removal unavailable, it chose calendar removal. It also rejected 88 requests whose correct tool was available and selected the wrong tool on another 69.\n\nJev and GLiNER both choose the correct tool on 311 of the 423 supported far-mic requests, giving 73.5% accuracy. Their behaviour changes when the correct tool is missing: Jev still chooses an action on 22 of 190 requests (11.6%), while GLiNER does so on 74 (39.0%). For example, GLiNER interpreted a request to lower speaker volume as dimming a light when the volume tool was absent. These examples selected a different action from the one requested. Broader tool descriptions can also overlap: a recipe request may be sent to a general cooking tool. Our count follows the annotated intent, so it does not establish that every alternative was semantically unreasonable.\n\nNova has the highest score for matching both the tool and all required argument values: 45.4%, or 368 of 810 supported requests. It chose the correct tool on 643 requests, but the arguments failed the match on 275 of those. In 147 cases the values differed from the reference; another 128 omitted at least one argument, sometimes alongside value differences.\n\nThe most frequent value mismatch was a time, appearing in 34 of those cases. We also saw missing dates and misnamed fields. For an alarm request that included “this week,” Nova returned the time but left out the date. Some failures are wording differences: “lasagna” does not match the reference’s “lasagne” under this strict text comparison. The score counts both kinds of mismatch.\n\n## InstructTTSEval: delivery has its own failure modes\n\nFor [InstructTTSEval](https://arxiv.org/abs/2506.16381), we keep the spoken script fixed and generate separate clips using three types of instruction:\n\n- **APS (Acoustic-Parameter Specification)** gives detailed voice settings, such as pitch, pace, volume and vocal texture. For example: “Low pitch, slow pace, soft volume and a slightly breathy voice.”\n- **DSD (Descriptive-Style Directive)** describes the delivery in natural language, leaving some voice traits open. For example: “Speak warmly and reassuringly.”\n- **RP (Role-Play)** gives a character or situation and asks the model to infer how to sound. For example: “You’re a doctor comforting an anxious patient.”\n\nThe percentage for each type shows how often the generated speech followed that instruction.\n\nThe larger cohort contains 25 English and 25 Chinese source lines, three checks each: 150 clips per system. Nova covers the 25 English lines, with 75 checks. Overall is total passes divided by total checks; with equal task sizes, it is the mean of APS, DSD and RP. A saved Gemini Pro judge supplies the style verdicts, while transcription checks the spoken words separately.\n\n**Original recordings** are the benchmark’s human source audio. We score them with the same instructions and judge used for the 150-check runs to give the synthesized voices a reference point. Their 73.3% means the judge accepted 110 of 150 instruction checks.\n\n| InstructTTS results from the linked leaderboard. Each row shows its run size and review status. The 30-check pilots use different judge settings from the 150-check cohort. |  |  |  |  |  | \n|---|---|---|---|---|---|\n| System | Overall | APS | DSD | RP | Scope / status | \n|---|---|---|---|---|---|\n| Qwen3-TTS 1.7B VoiceDesign (speech-swift)On device | 76.7%23/30 | 70.0%7/10 | 100.0%10/10 | 60.0%6/10 | 5 English + 5 Chinese lines; 30 style checks Pilot · different judge setting | \n| Original recordingsHuman reference audio | 73.3%110/150 | 84.0%42/50 | 94.0%47/50 | 42.0%21/50 | 25 English + 25 Chinese lines; 150 style checks Reference | \n| Google Gemini 3.8 Flash TTSCloud API | 67.3%101/150 | 76.0%38/50 | 78.0%39/50 | 48.0%24/50 | 25 English + 25 Chinese lines; 150 style checks Measured | \n| Breeze TTS 2 (speech-swift, BF16)On device | 66.7%20/30 | 60.0%6/10 | 80.0%8/10 | 60.0%6/10 | 5 English + 5 Chinese lines; 30 style checks Pilot · different judge setting | \n| FireRedTTS3-Instruct (speech-swift, FP32)On device | 65.3%98/150 | 68.0%34/50 | 78.0%39/50 | 50.0%25/50 | 25 English + 25 Chinese lines; 150 style checks Provisional · 1 judge response under review | \n| ElevenLabs v4Cloud API | 63.3%95/150 | 68.0%34/50 | 76.0%38/50 | 46.0%23/50 | 25 English + 25 Chinese lines; 150 style checks Input adapter under review | \n| VoxCPM2 2B (speech-swift)On device | 59.3%89/150 | 64.0%32/50 | 68.0%34/50 | 46.0%23/50 | 25 English + 25 Chinese lines; 150 style checks Provisional · 1 judge response under review | \n| MOSS-VoiceGenerator (speech-swift, BF16 + FP32 codec)On device | 56.0%84/150 | 52.0%26/50 | 76.0%38/50 | 40.0%20/50 | 25 English + 25 Chinese lines; 150 style checks Provisional · 1 judge response under review | \n| Qwen3-TTS 1.7B CustomVoice (speech-swift)On device | 52.7%79/150 | 54.0%27/50 | 64.0%32/50 | 40.0%20/50 | 25 English + 25 Chinese lines; 150 style checks Measured | \n| Qwen3-TTS 0.6B CustomVoice (speech-swift)On device | 48.0%72/150 | 48.0%24/50 | 60.0%30/50 | 36.0%18/50 | 25 English + 25 Chinese lines; 150 style checks Experimental input · 1 judge response under review | \n| Amazon Nova 2.5 Sonic (speech generation)Cloud API | 40.0%30/75 | 32.0%8/25 | 56.0%14/25 | 32.0%8/25 | 25 English lines; 75 style checks English only | \n| CosyVoice3 0.5B (speech-swift)On device | 34.7%52/150 | 4.0%2/50 | 60.0%30/50 | 40.0%20/50 | 25 English + 25 Chinese lines; 150 style checks Input conditioning and judge response under review | \n| Fish Audio S2 Pro (speech-swift, BF16)On device | 34.7%52/150 | 28.0%14/50 | 50.0%25/50 | 26.0%13/50 | 25 English + 25 Chinese lines; 150 style checks Provisional · 2 judge responses under review | \n\nOn the matched 150-check cohort, FireRedTTS3-Instruct scores 65.3% and MOSS-VoiceGenerator scores 56.0%. Google’s TTS run scores 67.3%. On the 75 English checks, FireRed scores 72.0%, MOSS 52.0% and Google 72.0%. VoxCPM2’s BF16 run remains at 59.3%; its role-play result, 46.0%, is weaker than its voice-description and direction results. The larger Qwen CustomVoice checkpoint scores 52.7%, versus 48.0% for the smaller experimental-input run. Size alone did not determine the score.\n\nOur ElevenLabs instruction-to-tag conversion dropped requested singing and some emotion changes. CosyVoice3 failed the word-content check on 48 of 50 APS clips; its generation setup also omitted reference conditioning present in the official implementation. These issues still need corrected-input validation. Fish’s corrected run and several other rows contain judge responses that claimed audio was unavailable; we preserve those verdicts and mark the affected rows provisional. These are results for our ports, input adapters and judge, rather than a finding that an upstream model has the same limits in every implementation.\n\nMost failures on the human recordings are in role-play: 29 of 50 checks fail, compared with eight for APS and three for DSD. A real recording can fit a detailed voice description yet not match the role assigned to it, and the judge can also make mistakes. The reference row helps us interpret instruction scores; it does not rate the quality of human speech.\n\n## Voice design can be a synthesis backend\n\n[Qwen’s VoiceDesign checkpoint](https://github.com/QwenLM/Qwen3-TTS) generates a voice from a written description. CustomVoice instead applies directions to a selected preset voice. The checkpoint and control channel matter: a field named “instruction” does not give a model a capability it was never trained to use.\n\nWe tested Qwen3-TTS 1.7B VoiceDesign and Breeze TTS 2 on the same five English and five Chinese sources, giving 30 checks per model. Four calibration checks are outside their scores. We retained all outputs, including one spoken-word flag per model.\n\nVoiceDesign passed 23/30 checks and Breeze passed 20/30. With ten source recordings shared across the three tasks, this is a development screen. The paired 10-point difference has a wide source-cluster interval that includes zero. The judge setting also differs from the larger cohort, so the pilot does not establish that VoiceDesign outperforms Google’s 67.3% result.\n\nA voice-design request, not a benchmark result\n\n**Spoken text:** “Your delivery is scheduled for Friday morning.”\n\n**Voice brief:** “An adult British English narrator with a warm tone, clear articulation and an unhurried pace.”\n\nKeep the script unchanged when trying another delivery. A designed voice and a clone from an authorised reference are different inputs; test consistency across the whole passage.\n\nFireRedTTS3-Instruct and MOSS-VoiceGenerator now each have 150 style checks in the table above. The separate content check flagged 0/150 FireRed clips and 12/150 MOSS clips for word error above 30%. Their short-script runtime samples remain in the Space. First available PCM was about 4.50 s for FireRed and 0.47 s for MOSS on the warm English script; FireRed returns a complete waveform while MOSS streams. Those timings do not establish instruction quality or a matched quality-speed ranking. Existing-model latency and memory certification remains inconclusive.\n\n## Turn-taking research now asks for more than an endpoint\n\nResearch snapshot: **30 October 2026**. The [official TurnBench held-out board](https://turnbench.sesame.com/) includes newer submissions beyond the paper’s original baselines. p99’s [system write-up](https://github.com/P99Lab/turn-1-mini) describes 6.1 million learned parameters, extra classification heads and a turn policy that uses both audio channels. Its [Apache 2.0 download](https://huggingface.co/p99lab/turn-1-mini) contains the 5.3-million-parameter mono model. We measured that downloadable checkpoint in the export pilot above.\n\n[LiveKit’s eot-bench](https://github.com/livekit/eot-bench) complements this with real human-to-agent turns in 14 languages. It sweeps endpointing policies and compares latency at a fixed false-cutoff budget, including the full tradeoff curve. That is a useful next step for a multilingual product because a threshold that works in English need not suit another language.\n\n[MultiPartyTurnBench](https://arxiv.org/abs/2610.20172), submitted this month, expands floor control to two to five speakers. Its authors report strong turn-entry performance alongside near-chance selective interruption handling for the evaluated agents. Its generated conversations provide controlled tests, with real-audio checks needed alongside them. Meetings and shared rooms require more than extending a two-speaker endpoint rule.\n\n[Full-Duplex-Bench v3](https://arxiv.org/abs/2604.04847) pairs real disfluent speech with chained tool calls, exposing self-corrections and multi-step failures. [DuplexAct](https://arxiv.org/abs/2610.17738), also submitted this month, evaluates interaction actions and whether the agent follows through. We see these as complementary tests for the gap between detecting an event and completing a useful interaction. We have not run these newer benchmarks in this post.\n\n## Private synthesis, directed dubbing and English voice choices\n\nSoniqo’s [private runtime and on-device SDKs](https://soniqo.audio/sdk) provide building blocks for speech applications in your own environment. We work with teams building expressive synthesis and emotionally directed dubbing pipelines: retain the intended words, choose a voice, supply a delivery brief, then review the result in context.\n\nYou can plug a voice-design backend into the synthesis stage while keeping turn policy and tool execution separate. For a narrated scene, the application can specify calm reassurance or rising urgency rather than infer an emotion and change the performance without a director’s control. A dubbing workflow also needs timing, speaker continuity and a listening review; the three benchmarks above do not certify that complete workflow.\n\nEnglish voice choices include [American and British preset voices](https://soniqo.audio/guides/kokoro) in the Kokoro catalogue. Style-aware backends add natural-language voice briefs. Preset selection, voice design and cloning are distinct controls, and support varies by model. A requested regional accent needs evaluation with listeners familiar with that variety; transcription accuracy and speaker similarity do not establish authenticity.\n\nWith a local backend and model assets provisioned, synthesis can stay in the deployment environment. The exact deployment and model choice depend on the target hardware and the model’s terms. Research-only benchmark data and restricted model weights are not a blanket commercial licence.\n\n### Build a voice workflow on your infrastructure\n\nBring the target platform, language and accent requirements, voice permissions, and examples of the delivery you need. We can scope the runtime, synthesis backend and evaluation around that workload.\n\n[Explore private speech deployment](https://soniqo.audio/sdk)\n\n## The choices these measurements support\n\n- **Choose a turn policy by its operating point.** In our dev slice, VAP and Mimi offer different recall, false-alarm and delay tradeoffs. Current held-out research has moved beyond those original baselines.\n- **Count complete tool requests.** In our ten-action setup, Nova chose the correct tool on 643 supported requests; 368 also had matching arguments. Wrong values and missing fields accounted for the gap.\n- **Test delivery by instruction type.** Role-play is a weaker area in several runs. The VoiceDesign pilot warrants a larger matched comparison, rather than a claim of a new overall winner.\n\nOur next useful measurements are a larger VoiceDesign cohort with matched judging, multilingual endpointing at fixed cutoff rates, and interaction tests that carry a correction through to the final tool call. Human review of accent, naturalness and performance continuity belongs alongside the automatic scores for production voice work.\n\nRead the [live results and protocols](https://huggingface.co/spaces/aufklarer/full-duplex-leaderboard), explore [speech-swift](https://github.com/soniqo/speech-swift), or discuss a [private deployment](https://soniqo.audio/sdk). The tables above retain the run sizes and settings from the linked snapshot.", "url": "https://wpnews.pro/news/measuring-voice-agents-turn-taking-tool-calls-and-expressive-speech", "canonical_source": "https://soniqo.audio/blog/voice-agent-benchmarks", "published_at": "2026-10-31 09:17:23+00:00", "updated_at": "2026-10-31 09:48:37.010931+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "machine-learning", "ai-research"], "entities": ["TurnBench", "SLURP", "InstructTTSEval", "Neosapience Nunchi v2", "Vox Maru v1", "OpenAI GPT-Realtime-mini", "Mimi endpointer", "Apple M5 Pro"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/measuring-voice-agents-turn-taking-tool-calls-and-expressive-speech", "markdown": "https://wpnews.pro/news/measuring-voice-agents-turn-taking-tool-calls-and-expressive-speech.md", "text": "https://wpnews.pro/news/measuring-voice-agents-turn-taking-tool-calls-and-expressive-speech.txt", "jsonld": "https://wpnews.pro/news/measuring-voice-agents-turn-taking-tool-calls-and-expressive-speech.jsonld"}}