Ok, John,
Thanks to your help, I feel that I’m getting closer…
So I looked up for a code to open a tcp socket and setup a simple code
for it, of course not working…
< server >
1 s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
2 host = ‘’ # can leave this blank on the server side
3 port = 1234
4 s.bind((host, port))
5 tcp = gr.file_descriptor_source(pkt_size, s) # (pkt_size,fd) park
6 sink = audio.sink(sample_rate)
7 self.connect(tcp, sink)
< client >
1 s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
2 host = ‘’ # can leave this blank on the server side
3 port = 1234
4 s.bind((host, port))
5 tcp = gr.file_descriptor_sink(pkt_size, s) # (pkt_size,fd) park
6 src0 = gr.sig_source_f (sample_rate, gr.GR_SIN_WAVE, 350, amplitude)
7 thr = gr.throttle(gr.sizeof_float, sample_rate)
8 self.connect(src0, thr, tcp)
Sorry to bother you again, but
any recommendations would help me a lot.
Johnathan C. wrote:
On Wed, Jul 22, 2009 at 07:45, Yc Park[email protected] wrote:
ece$ python ./from_udp.py
gr_block_executor: source <gr_block udp_source (3)> returned 0 from
work. �We’re marking it DONE.
This is essentially a bug in the design of gr.udp_source() that sort
of worked okay back in the single-threaded scheduler days, but not now
with the multi-threaded scheduler. Basically, returning 0 samples
from a source block work function will cause the scheduler to
immediately call it again, resulting in 100% utilization of a
processor core until the source block can produce data. The
thread-per-block scheduler enforces this now by terminating the block.
The fix is fairly easy (the original problem returning 0 was supposed
to solve can be fixed in another way), but not sure when it can be
done.
A work around is to open the network socket in Python, then pass the
file descriptor to gr.file_descriptor_source(item_size, fd).
Johnathan