Re: [Discuss-gnuradio] nan error from wavfile sink coupled with delayed input data

[CEL]

Huh, no, barring great undiscovered bugs, the delay involved shouldn't
have anything to do with the data, and the error pretty certainly has
something to do with invalid input data.
Are you sure the data is always the same?

Best regards,
Marcus

On Thu, 2018-04-12 at 11:03 -0400, Brad Hein wrote:
> 
> error: 
> thread[thread-per-block[22]: <block wavfile_sink (5)>]: Error in function 
> boost::math::round<f>(f): Value nan can not be represented in the target 
> integer type.
> 
> I have a flow graph that's connecting to a remote host on a TCP port using 
> the socket PDU. The flow graph is relatively simple and outputs a derivative 
> of the stream that it gets to a wav file sink. 
> 
> [data source (48khz floating point data stream using socket PDU)] ---> 
> TCP/internet ---> [destination flowgraph] ---> wavfile sink (stdout).
> 
> When I run the flow graph against the source locally (<5ms ping time) it 
> works fine. But when I run the flow graph against a remote host that's 20ms 
> away I get the above error 99% of the time. 
> 
> I have a hunch that what's happening is that the flow graph initializes and 
> starts to try and send data to the wavfile sink BEFORE the socket PDU starts 
> receiving data from the remote host. If this is the case, I would like to 
> adapt the flowgraph to better handle the arbitrary delay of data coming into 
> the flow graph. 
> 
> I'm looking for suggestions for what sort of block or blocks I can add to 
> help the flow graph better handle the delayed start of data coming into the 
> flowgraph from the socket pdu block. 
> 
> Thanks!
> 
> 
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

smime.p7s
Description: S/MIME cryptographic signature