I've been looking for a good way to TTS longer PDFs and EPUBs into recordings so I may listen to them on the go.
I'd like to take advantage of high quality TTS models but I'd prefer it to be one I may host myself.
I use Librera Reader [1] for this, it handles both ePub as well as PDF and then some. The quality of the TTS output is dependent on what you have on your (Android) device since that is what it uses. I tend to use Google's TTS with a male UK voice which I tune down (as in deeper voice) and speed up a bit. It mostly works fine, probably better for nonfiction than fiction but that is what I mostly use it for anyway. You can swap between reading on-screen and listening since it keeps position in the document while reading aloud.
You can also have it read into an audio file is so desired which can be listened to later.
It was a formal Show HN <https://news.ycombinator.com/item?id=39316019> from a while back, so I think that's within bounds but I also agree that it should be one top-level comment and let it go, not replying every time with the same text
> HPN-SSH is a series of modifications to OpenSSH, the predominant implementation of the ssh protocol. It was originally developed to address performance issues when using ssh on high speed long distance networks (also known as Long Fat Networks: LFNs). By taking advantage of automatically optimized receive buffers HPN-SSH could improve performance dramatically on these paths. Later advances include; disabling encryption after authentication to transport non-sensitive bulk data, modifying the AES-CTR cipher to use multiple CPU cores, more detailed connection logging, and peak throughput values in the scp progress bar. More information can be found on HPN-SSH page on the PSC website.
SSH started out with a maximum window size of 128K, which was bumped to 2M in the mid-2000s. It'd be entirely reasonable to bump this to the 64M to 128M range; it's not a fixed buffer allocated for each channel, and the peers explicitly manage the window size, so there really shouldn't be any compatibility issues. This would already solve most of these issues, the more complicated parts of HPN-SSH aren't really needed, and things like multithreaded crypto are entirely unnecessary with modern CPUs unless you need to saturate a 100G link with one connection.
> unless you need to saturate a 100G link with one connection
Maybe not 100gig, but I routinely transfer data over 10gig links. I used to be a heavy user of HPN, but Gentoo pretty much stopped supporting it because the multithreading is supposedly broken.
