In an effort to simplify this a bit, I created two flow graphs. One as the server (dial tone frequencies sent to socket PDU) and a client (unpack the socket data and send it to wav file sink). I was able to recreate the issue with these simplified blocks when their TCP/IP path traverses the internet. In order to post images and a better description I posted the issue on SO: https://stackoverflow.com/questions/50119704/wavfile-sink-value-nan-can-not-be-represented-in-the-target-integer-type
On Mon, Apr 30, 2018 at 1:33 PM, Müller, Marcus (CEL) <muel...@kit.edu> wrote: > 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 > > Discuss-gnuradio@gnu.org > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
