I'm afraid the buffering is not going to change a lot. With standard PCs and not real time OSes you do need a lot of buffering to absorb the effective rate changes on the USB bus and the CPU. While it can overall sustain the rate it is not at all regular in the details. If you want to reduce buffering and thus latency you have to use a complete different setup with FPGAs and direct access to the data bus of the LMS7002. I think all Tx SDR software that run on commodity hardware and desktop type OSes face this problem or they lie to you.
Another point: I am confident on my dot and dashes but if you use large sampling rates like the maximum of 30 MS/s as I saw on some screenshots (that was Rx and I am already amazed that it works) then packet drops can occur which completely ruins the code you are trying to send. If it was voice you would notice a lot of hickups. Bear in mind that you need such high rates only if your baseband signal requires it which would be the case if you were trying to send WiFi signals for example and SDRangel does not do that. At its very maximum 13.5 MS/s would be required to send an ATV signal at 30 FPS 625 lines and 720 pixels per line.
The Lime has the great feature of hardware upsampling up to 32 times so you don't need to push it hard on the sampling rate on the software side to get a clean signal. I usually never go above ~5MS/s. I noticed on the Rx side that you cannot get lower than 2.8 MS/s without having libusb warning messages so around 3 MS/s would be fine for most usages.
BTW my Lime is stable at ~50C without active cooling. I mean just heatsinks and an aluminium case, no fans.