We see this issue a lot with applications that only transmit, and which transmit continuously. The problem is that you end up generating samples far in advance of when you really know what you want to transmit, because there is no rate-limiting on the production side.
Some general principles -- Large buffers *allow* you to deal with high latency. Large buffers do not *create* high latency unless the application is not designed properly. A properly designed application will work with infinitely large buffers as well as it does with minimally sized ones.
Shrinking buffers may allow your application to work, but that isn't really the best way to solve this problem. The best way to solve the problem is to modify your head-end source block to understand wall-clock time. The easiest way to do that if you are using a USRP is to instantiate a UHD source (i.e. a receiver) at a relatively low sample rate and feed it into the source you have created.
Your source block should then look at timestamps on the incoming samples (it can throw the samples themselves away). It should generate only enough samples to cover the maximum latency you want, and it should timestamp those transmit samples. For example, if it receives samples timestamped with T1, it should generate samples with timestamps from T1+L1 to T1+L1+L2, where L1 is the worst-case flowgraph and device latency, and L2 is the worst case reaction time you are looking for. Thus, if you suddenly get a message from your operator to send a message, you know that you will never need to wait for more than L2 seconds. Thus, you can bound your worst case reaction time.
It should be noted that in two-way application like GSM or LTE, you would never run into these problems and they are naturally avoided because you won't generate samples until you've seen what you receive. It only is an issue in TX-only apps.
I think we should generate an example app to do this, because the issue comes up periodically, especially among the space communications crowd. It is a design pattern we really should document.