Chap

@Kenster - if I'd read your post more carefully I'd have seen you mentioned home directory permissions, which turned out to be the problem (777 rather than 755). Since I made that change a year or two ago, I'm unable to explain why it just recently began to be a problem for ssh.

@Giacomo1968 -- calling your attention to my Update 3 to original question, which seems to have solved the problem.

@Kenster - thanks - I mistyped in my question. The perms indeed are, and have been, 700. Corrected.

@Giacomo1968 - thanks for your efforts! Will take another look in the morning -- including learning to read the verbose ssh output, and investigating ed25519 which sounds like a likely culprit.

@Giacomo1968 - 14.2.1 was applied Dec. 19. However, I note several more recent "XProtectPlistConfigData" Apple updates, the latest being Feb 1.

@Giacomo1968 - update#2 has been added. Problem still occurring after adding .ssh/config (mode 644).

@Giacomo1968 - don't remember when I applied 14.2.1. I ssh from Air to Pro multiple times a day, first saw problem yesterday and am pretty sure last OS update was more than a couple of days ago (any way to check?)

@Giacomo1968 - requested verbose mode output has been added to question.

I noticed earlier today that on the MacBook Air, the default for ssh-keygen is to generate an 'ed25519' public/private key pair by default now, rather than RSA. Wondering if this is relevant.

@Giacomo1968 - done (removed ~/.ssh/known_hosts file from Air). Still being prompted for password when ssh'ing into Pro.

Just tested with -f and with a heredoc. Both work fine.

Might also note that 'afconvert outputfilename.caf -f adts' will convert to outputfilename.aac with nearly 20:1 compression.

(Steps 1-3 are also needed for authorize_terminal to run)

At this point I usually find that Live Speech via say -v MyVoice ... is producing nothing but silence. I pull down the Live Speech menu, enter a word, and it produces silence. Enter a word again, it says it in the default system voice. Enter it a third time and it says it in my voice, and now the say -v command works correctly.

1. From Terminal, run: sudo nvram boot-args="-arm64e_preview_abi amfi_get_out_of_my_way=0x1"

Question: currently the speech is sent to both the speakers (in real time) and to the -e file.caf, which slows the overall operation to that of speech. I don't see any say options (other than -o) that bypass the audio production; is there a way for this solution to render the sound file without concurrently speaking it?

Success on all counts! (Yes, am on Macbook Air 2020 M1.) This is great; thanks for all your efforts.

I tried to understand the difference between arm64 and arm64e but it's way beyond me, so don't assume I'm doing the right thing! :-)

Above was from DYLD_INSERT_LIBRARIES=./mysay.dylib say -v Chap "text to speak" -e path.caf

Useful? dyld[1760]: tried: './mysay.dylib' (fat file, but missing compatible architecture (have 'x86_64,arm64e', need '')), '/System/Volumes/Preboot/Cryptexes/OS./mysay.dylib' (no such file), './mysay.dylib' (fat file, but missing compatible architecture (have 'x86_64,arm64e', need '')),

Grepping nvram -p doesn't find 'boot-args', 'arm64e', or 'amfi'. I Booted into recovery mode and successfully issued csrutil disable, and rebooted. Still getting same results from ./authorize_terminal.

Scratch the above. Sound input setting was set to Transcriptions Text to Speech, hence it wasn't hearing anything. Set it back to Mac Mic and all is well for training.

(And of course I've restarted)

it seems to note that I've finished; the record button returns to its original state; and then nothing further happens: previously it would either complain of background noise, or proceed to record the first training sentence. I even created a new user and tried to create a personal voice, and the same thing happened.

Good q. re: your authorize tool running successfully at first. Here is some "FWIW" info: the training function of Personal Voice has stopped working: when I get to the point where it's checking for a quiet environment, it listens to me read the sentence;

(Transferred discussion to chat)

arch => arm64. Have rebuilt from github (but I'm definitely on M1 MBA). Have restarted (same experience w/random failures). say -v Chap Hello works correctly. Both authorize_terminal and DYLB say ... fail as before. Settings > Privacy&Security > Developer Tools > Terminal = allow/on. What have I missed?

Air$ ./authorize_terminal Killed: 9 Air:$ DYLD_INSERT_LIBRARIES=./mysay.dylib say -v Chap "text to speak" -e path.caf say: invalid option -- e Usage: say [-v voice] [-o out] [-f in | message] (Have already authorized byt wanted to show the kill 9) FWIW I use bash but also tried zsh.

We're getting slightly different results. I don't get any message in system.log about being unable to use Personal Voices, and it writes a 4.1K file that plays nothing. I dl'ed your code, built it, and tried to save some personal voice speech, but got the same 4.1K file. (Also, note typo in Makefile, -e should be -o)

@markp - that is certainly my preference. Without clear, complete, and unambiguous documentation about what will cause a deadlock, though, it's hard to know how! :-)

@markp - I don't know - I'm out of my depth here. I'm surprised it's so hard to get a definitive answer. I guess that, in lieu of any statement asserting that this statement is guaranteed not to deadlock, I have to code for that possibility and retry the transaction if it occurs.

@markp I hadn't really considered it, since the column in my example is indexed. But I see your point - clearly if they can't all be locked "quickly" they'd have to be locked separately. (Which is just my guess)

Not surprisingly, the above code deadlocks, because there are two threads that are acquiring two separate resources in the reverse order. The question is, when you execute the single statement SELECT FOR UPDATE..WHERE..IN(list), are you effectively acquiring a single "resource" (a row set) or many resources (multiple rows)? If you are effectively acquiring a single resource (all rows in the set in a single atomic operation), then no deadlock can occur. If you're getting multiple resources (each row separately, in unknown order), deadlock can occur. Seems like the latter is the case.

@terdon Thanks for response, and - no problem :-)

@terdon - please consider replacing the phrase "formatting abuse" with "excessive formatting." Maybe it's just me, but the word "abuse" is not only "excessively" dramatic, but carries with it some serious, unnecessary connotations. Thanks. :)