> > Underflows occur on transmit, nothing can drop because this is a lack > > of samples.
That's true! But I don't want the rest of the samples to be delayed due to the underrun. > > If I understand correctly, the transmit situation that Patrik > describes is behaviour _after_ the underflow. For a > continuous stream, the effect to subsequent samples is an > added time offset - equal to the duration of the underflow - > relative to the original start of the stream. > Yes you understood me correct and it is this offset I want to be zero again after an underrun. But I have a continuous stream. For example: if I expect that eth-packets (1) should be moved to the USRP2 and then transmitted, but if I get an underrun the sequence can be like this (2) then there is a offset between the real-time for p2 and the actual transmitting time. The solution is then to drop p2 (and maybe p3) in the host so the sequence becomes (3)(if we also drop p3 p1,U,E,p4,p5 E=empty) where p4,p5 are transmitted at the original expected time(compare (1) with (3)). p1,p2,p3,p4,p5 (1) excpected sequence p1,U ,p2,p3,p4,p5 (2) with underrun p1,U ,p3,p4,p5 (3) with underrun and dropping > For certain real-time applications, paired spectrum TDMA for > example, this makes underruns devastating. In these cases, > samples that were supposed to be transmitted when the > underrun occurred, but didn't for whatever reason, are > irrelevant and need to be dropped rather than transmitted > best effort. AFAIK, the only way to currently handle this is > to catch the underrun at the host and drop a handful of > packets so that the next start-of-burst reaches the USRP2 > ahead of the deadline. > > >> I've been looking in the source code and tried to find out where to > >> implement the sample dropping. My thoughts so far is that it should > >> be somewhere in vrt_packet_handler.hpp and/or io_impl.cpp in the send > >> functions and get_send_buffs function. > >> > > > > Is there something that you think the streaming API is missing please > > let me know. I think you can accomplish what you need with the API > > without modifying the underlying implementation. Yes, sure I could probably solve this with the API. But I utilize that the send-function in the API fragments the payload(samples) to fit in eth-packets to the usrp2. For example: if I send 25Msamp @ 25Msamp/s with one call to the send function those samples will be split into several eth-packets and transmitted during 1 second if we don't get any underruns (if we get underruns they are transmitted but it takes more time than 1 second), correct? If I handle the underruns with the API, I have to drop some samples and wait for some part of 1 second to get synchronized alignment on the next second after that. This creates a gap of some part of second where I'm not transmitting. It would be really nice if the send-function in the API have a TDMA mode where fragments of samples are dropped when an underrun occur so that the majority of the samples are aligned to the start_of_burst_time (see above example (1) and (3)). With this feature it is not necessary for the programmer to know if an underrun has occurred and how to handle this. Instead the programmer knows that if an underrun occurred some samples are dropped but the rest of the sample are transmitted at the expected time without any offset. Is this doable? -Patrik _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio