Re: espeakup stops speaking bookworm arm64
On Apr 13, 2023, at 14:26, Sam Hartman <hartmans@debian.org> wrote:
>
>>>>>> "Frank" == Frank Carmickle <frank@carmickle.com> writes:
>
> Frank> Good day all, I'm pretty certain now that speech stops when
> Frank> doing screen review by character.
>
> Frank> Does anyone know what would be different about this that
> Frank> would make this happen?
>
> This is just a guess, but you might run into trouble if the amount of
> speech produced by one character is less than some sound fragment size.
> I.E. something is setting up to deliver interrupts when a buffer gets
> empty, but the buffer never gets full enough to trigger that.
> So a bug in the sound stack within the vm or a bug in the emulated sound
> card or a bug in the sound stack in the host OS
> or a bug in how the emulator interacts with the sound stack in the host
> os.
> By sound stack I include things like pulseaudio and pipewire.
Any recommendations on looking at interrupts?
> You could play around with adding/subtracting pulseaudio/pipewire within
> the guest and different approaches for how the emulator talks to the
> host OS sound stack to explore whether this is the case.
I have as minimal a setup as possible, no pulseaudio or pipewire. Alsa reports the card as running at 48k and every time the qemu starts the system it sets the guest to 44.1k. We know then that qemu is resampling. I did start some discussion about this on the qemu list.
Any tips on debugging alsa and the interface from espeak to it, and kernel to the emulated audio hardware?
> I want to stress that this is only my guess, although I have run into
> such problems over the years.
I'm guessing the problem is somewhere other than the emulated hardware to the kernel, as I see this behavior under the vmware hypervisor on x8664 as well as qemu arm64. When I can get some other hardware spun up, I can try qemu on x8664 with Linux as the host instead of macOS.
Thanks for the discussion.
--FC
Reply to: