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
