Please test!

Hi @hselasky this is an awesome feature, I am not an expert but I am interested in the subject.

I applied the 3 reviews (with a buildworld/kernel) and installed espeak-ng yesterday, How could I test? Some list of commands?

Hi @asiciliano

After you've installed and booted the new kernel you simply can do the following commands to skip the buildworld:

cd /usr/src
make -C usr.bin/beep clean
make -C usr.bin/beep all install
make -C usr.bin/vtspeakd clean
make -C usr.bin/vtspeakd all install

Then run:

vtspeakd -sB

Or for very chatty output:

vtspeakd -scB

Then switch to the console, if you are in X11 or wayland.

--HPS

Thanks for the reply, It seems all right.

Tested: asiciliano

I listened man ls in English with "row" and "column" after vtspeakd -sB.
(I' ll test also in Italian and with www/edbrowse).

I had to unplug the hdmi cable and to use only the laptop, I don't know if it is useful for others.

Sorry for the late testing, I tested also with edbrowse and espeak in Italian[*] , it is all right.

[*]like proof of concept, I did a small addition to getopt() and execv() to pass "-v it" to espeak, ("vtspeak" -sB -l it" -> "espeak -v it").

Should we pass arguments to espeak using an environment variable perhaps?

I just got your e-mail and will have a look at it!

In D35776#817747, @hselasky wrote:

Should we pass arguments to espeak using an environment variable perhaps?

I just got your e-mail and will have a look at it!

Of course an environment variable can be a good idea (so vtspeakd can choose the current language).
I looked for an env and a config file in the espeak doc but it seems to get only the "-v" option for language/voice.

Preliminary testing shows that vtspeakd only speaks out text when run as root. Is that intended?

In D35776#841976, @pauamma wrote:

Preliminary testing shows that vtspeakd only speaks out text when run as root. Is that intended?

Yes, that is intended.

--HPS

In D35776#841982, @hselasky wrote:

In D35776#841976, @pauamma wrote:

Preliminary testing shows that vtspeakd only speaks out text when run as root. Is that intended?

Yes, that is intended.

I also need to test switching VTYs:
1- will vtspeakd still speak out content?
2- will I still be able to control it from the keyboard? (I expect I won't.)

In D35776#846168, @pauamma wrote:

In D35776#841982, @hselasky wrote:

In D35776#841976, @pauamma wrote:

Preliminary testing shows that vtspeakd only speaks out text when run as root. Is that intended?

Yes, that is intended.

I also need to test switching VTYs:
1- will vtspeakd still speak out content?
2- will I still be able to control it from the keyboard? (I expect I won't.)

1. vtspeakd speaks the contents of the currently selected console. By using the key combination ALT+F1 .. FX you can switch the console.
2. Can you be more specific about this.

All comments are noted @gbe . Just trying to find some time to work on it.

In D35776#847906, @hselasky wrote:

In D35776#846168, @pauamma wrote:

I also need to test switching VTYs:
1- will vtspeakd still speak out content?
2- will I still be able to control it from the keyboard? (I expect I won't.)

1. vtspeakd speaks the contents of the currently selected console. By using the key combination ALT+F1 .. FX you can switch the console.
2. Can you be more specific about this.

I meant using control-B to skip to the next line. If I'm not in the VTY running vtspeakd, does it do anything? (Going to try in the morning.)

Control-B seems to have no effect when displaying ttyv0 and vtspeakd was started on ttyv1. With that same vtspeakd VTY, control-B works on ttyv2.

There's a LOR that may be related, which I think I got by typing control-B:

lock order reversal: (sleepable after non-sleepable)
1st 0xfffff80006782408 ttymtx (ttymtx, sleep mutex) @ /usr/src/sys/kern/tty_ttydisc.c:489
2nd 0xfffff80001647e60 pidhash (pidhash, sx) @ /usr/src/sys/kern/kern_proc.c:450
lock order ttymtx -> pidhash attempted at:
#0 0xffffffff80c5df4d at witness_checkorder+0xbfd
#1 0xffffffff80bf7ad7 at _sx_slock_int+0x67
#2 0xffffffff80bcc4dc at pfind+0x6c
#3 0xffffffff80a345e7 at vt_access_hup+0x17
#4 0xffffffff80a3a4c3 at vtterm_bell+0x13
#5 0xffffffff80c52a14 at termtty_outwakeup+0x134
#6 0xffffffff80c8148e at ttydisc_write+0x36e
#7 0xffffffff80c7be0f at ttydev_write+0x13f
#8 0xffffffff80a7c268 at devfs_write_f+0xf8
#9 0xffffffff80c63661 at dofilewrite+0x81
#10 0xffffffff80c63190 at sys_write+0xc0
#11 0xffffffff810ce3be at amd64_syscall+0x12e
#12 0xffffffff810a167b at fast_syscall_common+0xf8

I'm going to apply the patches to a more recent -CURRENT snapshot and retry, unless someone with a faster world+kernel time (and or not going to bed soon) beats me to it.

Thanks for noticing that LOR. I'll try to reproduce when I find some time.

In D35776#851429, @hselasky wrote:

Thanks for noticing that LOR. I'll try to reproduce when I find some time.

Still there with the Nov 11 -current amd64 snapshot. Same LOR traceback displayed on ttyv0.

Tangentially, I don't know whether it's espeak-ng or my hearing, but when reading out the LOR backtrace, ffffffff (in addresses) sounds like eh-eh-eh-eh-eh-eh-eh-eh to me, which is disconcerting. (Trying other voices changed the sound output slightly but not in ways that help.)

I am interested to take/continue this feature. Are others already working?

In D35776#943183, @asiciliano wrote:

I am interested to take/continue this feature. Are others already working?

There are some testers (me included) but no developer.

In D35776#943183, @asiciliano wrote:

I am interested to take/continue this feature. Are others already working?

I think no one has worked on this still, so feel free to take this. You can add me as a reviewer if you want.