On Sun, Apr 13, 2008 at 11:08 PM, Chuck Hutton <<a href="mailto:charlesh3@msn.com">charlesh3@msn.com</a>> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
***** High Performance Software Defined Radio Discussion List *****<font color="navy" face="Arial" size="2"><span style="font-size: 10pt; font-family: Arial; color: navy;"></span></font></blockquote><div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<font color="navy" face="Arial" size="2"><span style="font-size: 10pt; font-family: Arial; color: navy;">For archiving sections of RF bandwidth,
why do we even need to use cycles by having it go through DttSP? My idea is
simply that we would take the post-CIC samples and do file I/O immediately.</span></font></blockquote></div><br clear="all">As you think best. This sounds to me like simply kicking the can further down throad, where processing can be done offline, and that's fine. But in practical terms the best I think you're going to do is pinning down specific buffers to avoid copying of the sample buffers on which looks like the structural gag behind "direct-n, direct-out" bandwidth processing.<br>
<br>-- <br>The only thing we have to fear is whatever comes along next. -- Austin Cline