[Discuss-gnuradio] virtual sound card driver
As there is alot of software that takes the soundcard as default source for doing digital processing, do you think it would be possible to build a virtual sound card device driver to be used as sink from gnuradio and as signal source from one of these softwares? I mean, a virtual sound card driver that has a line in with the real part on left channel and complex part on the right channel. Same thing could be true for the output... As far as you know is there anything like these already around? regards MAtteo iz2eeq ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Rational resampler
I'm trying to re-sample signals, ranging from 0.5Hz up to about 40Hz, sampling them at some small integer multiple of their frequency. Simple decimation isn't getting close enough, in many circumstances, leaving a significant phase erorr. I'm thinking that I can get closer using the rational resampler block, but I need more guidance than the online documentation can give me. Any clues? My input sampling rate is from the audio card--16Khz to 48Khz. My output sampling rate should be a small multiple (16 or 32) of the desired pulse frequency (0.5Hz to 40Hz, depending on which object I'm trying to observe). ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Simulateous transmission from two daughterboards
Yes, an example will be very helpful. Thanks, Satashu Eric Blossom wrote: On Sun, Mar 05, 2006 at 02:21:55AM -0500, Satashu Goel wrote: I am trying to find some information on how to use the two Tx daughterboards to transmit independent data streams? In one of the posts, http://lists.gnu.org/archive/html/discuss-gnuradio/2005-10/msg00142.html Eric said that this can be done by using a "stream with two interleaved channels of I & Q data". Does anyone know how to do this using the existing blocks? It will be great if someone can post an example. Thanks, Satashu Do you still need the example? Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] SCHED_FIFO and NPTL
Eric Blossom wrote: Bottom line, it hasn't actually been proved that running SCHED_FIFO will squash the existing latency and continuity problems, so I'm not at all sure much is missing without that capability. Frank, is this a statement or a question? It's a statement. I don't have any real proof at the moment but I suspect SCHED_FIFO is a bit of a red herring. I haven't got proof because the couple of times I tried to actually measure a difference I tripped over additional activity that needed to be accounted for, like, for example, periodic journaling filesystem updates. The other unfortunate consequence was that some kinds of X action on the desktop, like switching between multiple desktops, would get deferred -- it got real sluggish -- and then all the display activity would happen in a burst. Sometimes that would choke the audio worse than an occasional xrun. Oh, and the interaction with audio subsystem buffer sizes was unpredictable. I'm suggesting that the current non-RT scheduling is very delicately balanced and there's no single, universal fix. What's more, I conjecture that the worst culprit is disk activity, specifically paging, and that the cost/benefit fix for that is running off ramdisk :-) It would be *wonderful* to be wrong about this. As I said, it's just a strong hunch. I'm not sure if the JACK FAQ is up to date or not. Usually not :-) Do you have data on the success or failure of folks running JACK on ALSA using NPTL and if they are able to get sufficiently good performance? I guess Ardour users would be a good test case. How about the dttsp stuff under Linux? Again, it ain't conclusive, but it looks like xruns are not a problem with DttSP under Linux. You're absolutely right, Ardour users are the ones to ask. I finally have it installed here and can check it out first hand, at long last. Frank ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] frequency tuning word quantization
On Wed, Mar 08, 2006 at 05:42:56PM +0100, Matteo Campanella wrote: > I also meant a gnuradio example, eg. some block that does this already or > almost ;-) > > On Wed, Mar 08, 2006 at 08:45:04AM +0100, Matteo Campanella wrote: > >> great... this should mean we should be able to test alot of examples > >> removing the xlating filter from the chain... I hope to run some tests > >> asap; in the meanwhile Eric, what is a good starter example to > >> understand > >> how to decode/encode digital signals as, for example, FSK g3ruh? the fsk > >> or psk ones? Oh, that ;) Take a look at gnuradio-examples/python/gmsk2 and gnuradio-core/src/python/gnuradio/blksimpl for the guts. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] SCHED_FIFO and NPTL
On Wed, Mar 08, 2006 at 09:46:54AM -0500, Frank Brickle wrote: > Eric Blossom wrote: > > >>Bottom line, it hasn't actually been proved that running SCHED_FIFO will > >>squash the existing latency and continuity problems, so I'm not at all > >>sure much is missing without that capability. > > > > > >Frank, is this a statement or a question? > > It's a statement. I don't have any real proof at the moment but I > suspect SCHED_FIFO is a bit of a red herring. I haven't got proof > because the couple of times I tried to actually measure a difference I > tripped over additional activity that needed to be accounted for, like, > for example, periodic journaling filesystem updates. I've been screwed by ext3 journaling in the past. We may want to experiment with Reiser and/or XFS. I can understand why journaling would stop filesystem activity, but there's no good reason for it to suck down all CPU (or go non-preemtable). > The other unfortunate consequence was that some kinds of X action on the > desktop, like switching between multiple desktops, would get deferred -- > it got real sluggish -- and then all the display activity would happen > in a burst. Sometimes that would choke the audio worse than an > occasional xrun. Oh, and the interaction with audio subsystem buffer > sizes was unpredictable. Hmmm. If the "real time" code is using, say 50% of the CPU, and is doing it in small quanta, this *shouldn't* be a problem. > I'm suggesting that the current non-RT scheduling is very delicately > balanced and there's no single, universal fix. Could be. > What's more, I conjecture that the worst culprit is disk activity, > specifically paging, and that the cost/benefit fix for that is > running off ramdisk :-) The paging problem is fixable with mlock. [EMAIL PROTECTED] doc]$ size /usr/local/lib/libgnuradio-core.so /usr/local/lib/libusrp.so textdata bss dec hex filename 1175774 329521660 1210386 127812 /usr/local/lib/libgnuradio-core.so 9699919161044 99959 18677 /usr/local/lib/libusrp.so The total code + statically allocated data is under 2MB. If we also locked down the buffers and the top 1MB of each stack, I think we'd eliminate that problem. I could also ensure that the C++ "new" allocator allocated from an mlock'd area. (This only happens at startup.) No need to worry about the 10's of MB of Python, it's not on the critical path. The signal processing code never blocks waiting for it. And RAM is currently running at about $100/GB ;) > It would be *wonderful* to be wrong about this. As I said, it's just a > strong hunch. > > >I'm not sure if the JACK FAQ is up to date or not. > > Usually not :-) > > >Do you have data > >on the success or failure of folks running JACK on ALSA using NPTL and > >if they are able to get sufficiently good performance? I guess Ardour > >users would be a good test case. How about the dttsp stuff under Linux? > > Again, it ain't conclusive, but it looks like xruns are not a problem > with DttSP under Linux. You're absolutely right, Ardour users are the > ones to ask. I finally have it installed here and can check it out first > hand, at long last. Let me know what you find out! Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] virtual sound card driver
On Wed, Mar 08, 2006 at 09:12:58AM +0100, Matteo Campanella wrote: > As there is alot of software that takes the soundcard as default source > for doing digital processing, do you think it would be possible to build a > virtual sound card device driver to be used as sink from gnuradio and as > signal source from one of these softwares? > > I mean, a virtual sound card driver that has a line in with the real part > on left channel and complex part on the right channel. Same thing could be > true for the output... > > As far as you know is there anything like these already around? > > regards > MAtteo iz2eeq JACK and ALSA both support this under GNU/Linux Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Simulateous transmission from two daughterboards
I am trying to find some information on how to use the two Tx daughterboards to transmit independent data streams? In one of the posts, http://lists.gnu.org/archive/html/discuss-gnuradio/2005-10/msg00142.html Eric said that this can be done by using a "stream with two interleaved channels of I & Q data". Does anyone know how to do this using the existing blocks? It will be great if someone can post an example. Thanks, Satashu ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Rational resampler
On Wed, Mar 08, 2006 at 07:56:11AM -0500, Marcus Leech wrote: > I'm trying to re-sample signals, ranging from 0.5Hz up to about 40Hz, > sampling them at some small > integer multiple of their frequency. Simple decimation isn't getting > close enough, in many circumstances, > leaving a significant phase erorr. > > I'm thinking that I can get closer using the rational resampler block, > but I need more guidance than the online documentation can give me. Any > clues? Did you see gnuradio-examples/python/audio/test_resampler.py? It just works ;) > My input sampling rate is from the audio card--16Khz to 48Khz. My > output sampling rate should be > a small multiple (16 or 32) of the desired pulse frequency (0.5Hz to > 40Hz, depending on which object > I'm trying to observe). Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] frequency tuning word quantization
On Wed, Mar 08, 2006 at 08:45:04AM +0100, Matteo Campanella wrote: > great... this should mean we should be able to test alot of examples > removing the xlating filter from the chain... I hope to run some tests > asap; in the meanwhile Eric, what is a good starter example to understand > how to decode/encode digital signals as, for example, FSK g3ruh? the fsk > or psk ones? Take a look at http://comsec.com/wiki?SuggestedReading Here are a couple of specific suggestions: ''Digital Signal Processing in Communication Systems'' by Marvin E. Frerking. Practical engineering focus. Lots of great examples. Frerking often provides mulitiple solutions for a given transmitter or receiver design problem. ISBN 0442016166 ''Wireless Digital Communications: Design and Theory'', by Tom McDermott?, N5EG. Good high level overview of the basics of digital comms. Published by TAPR, available at http://www.tapr.org. ISBN 0-9644707-2-1 > the other thing is that the tvrx has some error in tuning, in my case > about 4KHz, that is within the specs - obviously this is a problem in the > case of narrowband where 4KHz matter... any idea to quickfix this? A PLL to track the real signal? Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: USRP Update -- Daughterboard News March 2006!
Stephane Fillod wrote: > Out of curiosity, will we be able to have a peek at the schematics of > the LFRX&LFTX boards like it is possible for the Basic RX&TX boards at > http://www.ettus.com/Download.html ? All the schematics will be up on my web site by Friday. > Also, there's no pressure intended, but what is coming up next? FLEX1200 ? The Flex900 will be next. At this time I don't think that there is enough demand to warrant building a Flex1200. Instead I will provide instructions on how to modify a Flex2400 to work on 1200-1300 MHz. It will only involve changing a few passives. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] am reception examples
I digged into the usrp c code, and I have found the following code, that
basically says we could use 32 bits for tuning on the fpga, but we truncate
it to 14 - unless there's a good reason for that, we could be much more
precise in tuning the NCO... again, unless Matt has a good reason for that.
ciao
Matteo
// The FPGA NCOs use a signed 32-bit frequency tuning word,
// but we keep only the most significant 14 bits.
static unsigned int
compute_freq_control_word_fpga (double master_freq, double target_freq,
double *actual_freq, bool verbose)
{
static const int NBITS = 14;
int v = (int) rint (target_freq / master_freq * pow (2.0, 32.0));
// v += 1 << (32 - NBITS - 1);// add 1/2
v = (v >> (32 - NBITS)) << (32 - NBITS); // keep only top NBITS
*actual_freq = v * master_freq / pow (2.0, 32.0);
if (verbose)
fprintf (stderr,
"compute_freq_control_word_fpga: target = %g actual = %g
delta = %g\n",
target_freq, *actual_freq, *actual_freq - target_freq);
return (unsigned int) v;
}
- Original Message -
From: "Eric Blossom" <[EMAIL PROTECTED]>
To: "Matteo Campanella" <[EMAIL PROTECTED]>
Cc:
Sent: Sunday, March 05, 2006 3:22 AM
Subject: Re: [Discuss-gnuradio] am reception examples
On Fri, Mar 03, 2006 at 12:06:01AM +0100, Matteo Campanella wrote:
In another script, usrp_wfm_rcv.pl, another method has been used, the
usrp.tune, that, according to the tests, does not need any successive
adjustment - is there any reason why the am receiver is not written using
this method?
usrp_wfm_rcv was written later in the game, and uses the prefered
method (works with all daughterboards). Whether or not you need to
the final software DDS depends on how precisely you need to be on
frequency. The WFM signal is > 100 kHz wide, thus an offset of a few
kHz makes no difference. For narrow band FM, or AM, etc, you probably
want to be closer. Take a look at usrp_nbfm_rcv.py, it uses the
preferred technique. Note that if you really are trying to handle AM
properly you're probably better off building a synchronous receiver or
some other method that tracks the carrier.
Another doubt is about optfir.low_pass versus gr.firdes.low_pass - from
the
tests I have run, the first one is much faster of the second - is there
any
reason to use the second instead of the faster optfir?
optfir uses the Remez / Parks-McClellan design method.
gr.firdes.low_pass designs filters using the window method. It all
depends on what you want. See any DSP book for details.
Eric
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] SCHED_FIFO and NPTL
It was **specifically* * the Reiserfs that ran us away from it to the less troublesome (at the time) EXT3. Isn't XFS deprecated because of all the problems associated with it? I might be wrong but that is what I recall. Bob -- snip, Eric wants to leave EXT3 for ReiserFS - -- AMSAT VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats, NJQRP/AMQRP, QRP ARCI, QCWA, FRC. ARRL SDR Wrk Grp Chairman Laziness is the number one inspiration for ingenuity. Guilty as charged! ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] SCHED_FIFO and NPTL
On Wed, Mar 08, 2006 at 01:59:49PM -0500, Robert McGwier wrote: > It was **specifically* * the Reiserfs that ran us away from it to the > less troublesome (at the time) EXT3. Isn't XFS deprecated because of > all the problems associated with it? I might be wrong but that is what I > recall. > > Bob > I was burned by ext3 with regard to streaming disk throughput. I ended up remounting the relevant filesystem as ext2 to avoid the problem. I have no info regarding CPU and/or preemption issues during journal posting. If we never go to the disk, it might not matter at all. I installed the Reiser FS on my new laptop. I'll let you know if I see anything hinky. Haven't tried XFS. I suspect it's OK. SGI built truely *monstrous* media servers using it. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] SCHED_FIFO and NPTL
On Wed, Mar 08, 2006 at 02:52:14PM -0500, Frank Brickle wrote: > Eric Blossom wrote: > > >... > >I ended up remounting the relevant filesystem as ext2 to avoid the > >problem...If we never go to the disk, it might not matter at > >all. > > ... > > It's been a long time since I looked at these pages: > > http://ardour.org/requirements.php > http://ccrma.stanford.edu/planetccrma/software/tunesystem.html > > however they're very informative and probably required reading. The key > point in connection with what we've been grousing about today is this. > The essential thing isn't altering the scheduler. It's getting the > scheduler to run often enough. Thanks. > Also I haven't been able to track it down but the other (d'oh) point is, > if you're streaming to disk, why write to a journaling filesystem? They > seem to be big fans of external FireWire drives for this kind of thing. Good point. I guess that's consistent with my switching from ext3 to ext2 for the data logging ;) FWIW, I was running RAID-0 stripped across 3 drives. That configuration using fancy IBM Ultrastar 10K SCSI drives would sustain 100+ MB/s. I suspect that you could get close today using a couple of el-cheapo 7200 RPM SATA drives. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] SCHED_FIFO and NPTL
Eric Blossom wrote: ... I ended up remounting the relevant filesystem as ext2 to avoid the problem...If we never go to the disk, it might not matter at all. > ... It's been a long time since I looked at these pages: http://ardour.org/requirements.php http://ccrma.stanford.edu/planetccrma/software/tunesystem.html however they're very informative and probably required reading. The key point in connection with what we've been grousing about today is this. The essential thing isn't altering the scheduler. It's getting the scheduler to run often enough. Also I haven't been able to track it down but the other (d'oh) point is, if you're streaming to disk, why write to a journaling filesystem? They seem to be big fans of external FireWire drives for this kind of thing. 73 Frank AB2KT ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Ubunto and GnuRadio, Lovely together
On Tue, Mar 07, 2006 at 08:34:12PM -0500, Frank Brickle wrote: > Dave Dodge wrote: > >You can expect to have to > >run synaptic several times and keep enabling/installing yet more > >packages before you'll finally have a reasonably complete set of > >headers, tools, and documentation -- unless there's some meta-package > >that grabs everything at once, and I just haven't noticed it yet. > > build-essentials A quick glance suggests that this gives you a couple of major things such as make, patch, and gcc, but not much else. What I really hoped for was a single target to give me at a minimum -dev and -doc packages for everything in the base installation -- something more the equivalent of a full install on other distributions. > >...The kernel and drivers supplied by the > >"Breezy" release are also showing their age... > > ...unlike SuSE, of course ;-) True enough. I tried an amd64 port of Slackware on the same machine and X couldn't even start. Ubuntu might be slimmer than I'd like, but it did mostly work. -Dave Dodge ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] SCHED_FIFO and NPTL
On Wed, Mar 08, 2006 at 12:26:07AM -0800, Eric Blossom wrote: > On Wed, Mar 08, 2006 at 02:18:35AM -0500, Frank Brickle wrote: > > Eric Blossom wrote: > > > > >Using LD_ASSUME_KERNEL=2.4.19 effectively forces the old (pre-NPTL) > > >behavior, which means that acquiring an uncontested mutex requires a > > >trip to the kernel. I believe it also means that mutexes won't work > > >in shared memory across process boundaries. Those seem like total > > >losers to me... Who has measured the cost of pre-NPTL(aka LinuxThread) mutexes in a typical GNU Radio application ? Right now, do we need mutexes across process boundaries (mutexes across thread are fine) ? > > This adds up to: futexes don't work (yet). Is that right? > > I guess that's the real question. > > My understanding is that they work, it's just a question of how they > work vis-a-vis real time. In our case I'm not worried about issues > such as priority inversion on mutexes. I assume all our signal > processing threads will be running at the same pri and waking up > anybody who's waiting will be fine. I just want to ensure that I run > before the X-server. SCHED_FIFO is necessary but not enough for stuff like X-server. Indeed, some badly written video drivers can call cli/sti directly from user-space on x86 systems (provided iopl succeeded). Binary-only drivers can hurt the same way. Unfortunately, hard-RT solutions like Xenomai can't do much in that case, because they can't virtualize the masking. Otherwise Xenomai is doing great, even with loaded X-server and knee-bending activity. cli/sti pairs are not the only latency killers. This page[3] tries to list them for hard-RT systems. One big culprit encountered by hard-RT developers on common PCs is the SMI subsystem. The interrupt handler for a System Management Interrupt (SMI) runs from a protected memory space (SMRAM), so the OS has no access to this handler code. SMI is primarily used for ACPI and APM support. It can be used for USB legacy support (USB keyboard, disk, etc.). It has been seen SMI eating up several *hundred* of *milliseconds* ! [3] http://rtai.dk/cgi-bin/gratiswiki.pl?Latency_Killer > > > I'm still confused about a couple of things. On one hand the holy grail > > appears to be getting the number of frames in a jack buffer down to 64 > > so as to minimize the roundtrip latency. On the other hand you want to > > eliminate xruns. They aren't the same by any means. > > Definitely. In a hard-real-time world, this problem is solvable. Indeed. > At this point, I've got my eye more on minimizing the USRP latency > since it determines the tightest MAC loop we can build on the host. > Basically, I want to make sure that I'm running at a better pri than > the X-server and friends. (This all assumes that I've got sufficient > cycles to actually get the work done in real time.) > > The smallest chunk of work we can conveniently get across the USB is > 128 complex samples (512 bytes). Assuming we're running at 4MS/s > that's 32uS of samples. If we're able to get N uS of CPU every > 32uS, then solving the audio problem shouldn't be a problem ;) I assume you meant 'us' (micro-second), and not micro sample or micro Siemens :-) Talking about getting to the 32us area, this is what the Xenomai/RTAI guys are doing, turning Linux+average PCs into convenient DSP. On non- flawed hardware, one can get better than 10us latency. However, taking only 50% of a 32us period is not going to lead to linear consumption (think context switch, and not only register file). Besides, the bigger the chuncks of data, the more efficient the optimization of data crunching loops, let alone the depth (history necessary for feedback) required by some filtering algorithms. But you know the drill already ;) > (I'm also reviewing chapter 5 of the USB 2.0 spec to see how often > the h/w arbitrates for access to the USB.) Oh btw, the regular Linux USB stack probably won't be able to guarantee 32us latencies. The best bet here, is the usb4rt[3] project for Xenomai, a rewrite of USB stack with hard-RT in mind. [4] http://developer.berlios.de/projects/usb4rt > > It's not clear that minimizing roundtrip latency means much when you're > > using DSP buffers of 512 frames or more. By the same token, in what I've > > observed, the chief culprit for the xruns is the X window system. There > > is a very delicate balancing act going on in the process priorities > > between the audio subsystem and the video subsystem. I'm not convinced > > that running SCHED_FIFO is going to routinely enable the audio subsystem > > to slide in under the video action under all circumstances. > > Taking a look at the output of > > $ ps -eo pid,tid,class,rtprio,ni,pri,comm > > on my system indicates that the X-server is not running with real time > scheduling. Only the migration tasks are. I assume these migrate > tasks across CPUs (this output is from a dual core machine). The > stuff with negative niceness (
Re: [Discuss-gnuradio] SCHED_FIFO and NPTL
On Thu, Mar 09, 2006 at 12:24:30AM +0100, Stephane Fillod wrote: > On Wed, Mar 08, 2006 at 12:26:07AM -0800, Eric Blossom wrote: > > I assume you meant 'us' (micro-second), and not micro sample or micro > Siemens :-) Definitely micro Siemens! > Talking about getting to the 32us area, this is what the Xenomai/RTAI > guys are doing, turning Linux+average PCs into convenient DSP. On non- > flawed hardware, one can get better than 10us latency. However, taking > only 50% of a 32us period is not going to lead to linear consumption > (think context switch, and not only register file). Besides, the bigger > the chuncks of data, the more efficient the optimization of data > crunching loops, let alone the depth (history necessary for feedback) > required by some filtering algorithms. But you know the drill already ;) Yep. > > (I'm also reviewing chapter 5 of the USB 2.0 spec to see how often > > the h/w arbitrates for access to the USB.) Summary: since we're using BULK transfers, as long as we're not competing with a web cam or something, things should work out OK. The h/w is free to execute multple transactions per micro frame. > Oh btw, the regular Linux USB stack probably won't be able to guarantee > 32us latencies. The best bet here, is the usb4rt[3] project for Xenomai, > a rewrite of USB stack with hard-RT in mind. > > [4] http://developer.berlios.de/projects/usb4rt No sign of EHCI, bummer. Since they don't keep a real ChangeLog, it's a bit difficult to see what they're been working on. > Lucky you, dual CPU systems(SMP) have an easy solution. One dedicated CPU > bind to the time critical tasks, the other CPU for Linux, X-server, etc. Yes, assuming that there's not some stupidity in the kernel or some driver that kills the second processor ;) > Whatever the solution, we're going to need to be able to evaluate its > "fitness" for our particular GNU Radio load. IMO, we should check > that by ourselves. Agreed. For the usrp latency test, I was thinking about a custom FPGA build that would generate a series of packets, all zeros except the first 16-bits of each. The first 16-bits would contain a sequence number, and a non-zero high bit. Then run a detector in the FPGA with its output wired to some d'board pins, that monitors the data coming and going across the GPIF bus. When it sees the non-zero high bit it would output a flag and the sequence number -- independently for the incoming and outgoing data. The host code would just loop back the packets it received from the usrp. Using a logic analyzer, we could see exactly what was going on. > > Returning to the audio xrun problem: I think that in the typical USRP > > + audio situation, xruns are aggravated by differences in the clocks > > between the two domains and the fact that we aren't doing anything to > > handle that situation. > > I do agree. Then, how to we distinguish an xrun off a missed deadline > from a xrun off a clock difference ? > What are solutions in sight? "Get to know your clocks"? For the clock difference problem, the idea is to have a flag passed to the audio source/sink at instantiation time that says "OK to block or not". This allows the application to specify if the audio sink/source should pace the pipeline or not. If you're using a USRP and an audio sink/source, you'd typically set the flag to "NOT OK to block". Then by watching the callback from portaudio / jack / alsa, and using a ring buffer between the GNU Radio world and the audio world we can explicity manage the flow of data to/from the audio subsystem. We can either fill or drop as required, without leading to a big backup in the GNU Radio processing pipeline. If you're looking for something to do, we could *really* use a gr-audio-portaudio source/sink with these new semantics ;) The portaudio V19 stuff in CVS has good support for JACK and ALSA under Linux, plus Windows and OS/X of course. Weren't you pointing this out years ago? ;) There's a skeleton gr-audio-portaudio module checked in (copied from gr-audio-alsa and renamed). It doesn't compile, doesn't implement the new semantics, and doesn't have the ring buffers. It's patiently waiting for some highly skilled attention ;) Interested? Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
