Emacspeak discussion list

[Bart Bunting <bart AT bunting.net.au>]

Hi Ľuboš,

Thanks for the detailed report and measurements. I reproduced the half-speed 
onset in a playback regression test, and a fix is now released in Omnivox 
1.14.0.

Your channel-count suspicion was correct. The playback queue reported mono 
while idle, and that format could carry into the start of a stereo source. 
This reproduced the stretch you described: 256 stereo frames became 512 mono 
frames. The fix keeps the queue’s format consistently at stereo, 44.1 kHz 
across idle transitions. Both normal speech and --play-wav use the corrected 
path.

The regression tests reproduce the failure with the old queue behaviour and 
pass with the fix. I haven’t independently reproduced the separate initial 
256-frame loss or the tick-followed-by-zeros lead-in collapse, so I can’t yet 
claim those are resolved.

Could you try 1.14.0, restart Omnivox, and repeat your loopback comparison 
with the helper’s lead-in disabled? It would be particularly useful to know 
whether either of those two effects remains.

Thanks again for narrowing this down so precisely.

Bart

Ľuboš Pinteš (via emacspeak Mailing List) <emacspeak AT emacspeak.net>
writes:

> When Omnivox starts playing after a period of silence, the beginning of 
> the utterance is corrupted. On 1.13.0, measured at the 44.1 kHz stereo 
> pipeline rate:
>
> 1. About the first 256 frames of the utterance never reach the device.
> 2. The next 256 frames are played at half speed, an octave lower. They 
> look like interleaved stereo samples being read as mono: 512 samples 
> come out as 512 frames.
> 3. After that, playback is sample-exact.
>
> This is about 12 ms, but it sits right on the onset. With short 
> utterances such as character echo while typing, it is clearly audible: 
> vowels sound rough and "thick" instead of clean.
>
> The same half-speed stretch also happens with `omnivox --play-wav FILE` 
> on the first sound after idle. That path loses nothing, but its first 
> 256 frames are still played at half speed. So the problem seems to be in 
> the playback stage, not in helper streaming. My unconfirmed guess is a 
> channel-count mismatch in the output queue or mixer when a new source 
> starts on an idle stream.
>
> `--dump-wav` output is correct. The damage only shows in live playback, 
> so I measured it with WASAPI process loopback of the Omnivox process 
> tree and compared it with `--dump-wav` output.
>
> **Reproduction:** Let the server go idle for about a second, send `l 
> {e}` (any short utterance with a sharp onset), and repeat. Every 
> repetition after idle shows the same pattern.
>
> **A second observation from the workaround:** As a workaround, my helper 
> prepends 20 ms of low-level lead-in to each utterance, so the damaged 
> window falls on the lead-in instead of speech. The lead-in only survives 
> if every sample of it is above the 0.01 silence-trim threshold. With a 
> short tick followed by zeros, the live path collapses the lead-in to 
> about 253 frames regardless of its length (20 or 60 ms): the zeros after 
> the first non-zero sample get discarded. `--dump-wav` keeps the full 
> lead-in. The workaround is therefore fragile, and a fix in Omnivox would 
> let me remove it.
>
> Emacspeak discussion list -- emacspeak AT emacspeak.net
> To unsubscribe send email to:
> emacspeak-request AT emacspeak.net with a subject of: unsubscribe