Hello list! I'm using named pipes to stream data that I want modulated to gnuradio and I'm receiving modulated samples back using the same named pipes method. I then forward the modulated samples to a SDR via some low latency C implementation I wrote and perform the same operations in reverse at the receiving end.
I'm for now experimenting with a simple FSK modulator/demodulator running at 50 kbaud/s, with 20 samples per symbol and 16 bytes (128 symbols) packet sizes. By embedding a timestamp in the packets before sending them I'm measuring an end to end latency ranging from 50 to 250 milliseconds (with a lot of jitter). This should mean that I have at least 300-1500 KB worth of buffers in my application (this was calculated using the data rate of the input/output data, it would be a much bigger number if I considered the modulated signal). My understanding is that most of the latency is coming from my input/output pipes/sinks, as once the signal is modulated each byte of my data in/out becomes 8 (bits per byte) * 20 (samples per symbol), so that each gnuradio block working with the modulated signal, in a worst case scenario where 4096 samples are processed at the time, only corresponds to 25 bytes worth of buffered, unmodulated data at any given time (4096/(8*20)). Since that my buffer is at least 100 times that and I don't have 100 blocks, that shouldn't be the issue. Now on to my ideas on how to decrease latency for the input/output pipes/blocks: 1) Add padding bytes after the packet before sending it to the pipe/input file source block. Add a block after the file source dropping those padding bytes, that would probably require writing a custom block but should effectively eliminate any latency due to pipes and the file source block. A similar method can be used for the file sink block. 2) Use gr-eventstream to implement some version of the above. Not sure if this would be of any use though, I haven't spent much reading about it. 3) Hack the input/output sink blocks to (for example) allow a maximum output buffer lower than 4096 (I'm met with an error when I try to set the output buffer of my file source block to anything less than that). 4) Same as the first idea, but don't drop the padding bytes/data. Instead leave the blocks running with junk at the end, so that the output will be what you want and junk there after. This isn't a problem at the receiver because of how packet synchronisation works, but you would need to somehow know what's going on with your output IF pipe in your transmitter stream. This would also get rid of all the buffers/latency from all of gnuradio. Any other ideas, or suggestions on what is the most feasible path? I hope this email isn't too confusing, I know I don't have a gift for writing. Thank you. _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
