[Discuss-gnuradio] Re: Re: Please help me out with udp_sink

[Yc Park]

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 Corgan wrote:
> On Wed, Jul 22, 2009 at 07:45, Yc Park<address@hidden> 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

-- 
Posted via http://www.ruby-forum.com/.