[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] Using USRP from multiple applications simultaneou
Re: [Discuss-gnuradio] Using USRP from multiple applications simultaneously
Wed, 4 May 2005 03:12:32 +0200
mutt-ng 1.5.8-r168i (Debian)
On Sun, May 01, 2005 at 03:02:40PM -0700, John Gilmore wrote:
> The current software was designed to let you run one transmit
> application and one receive application at the same time. If that
> doesn't work, please report exactly what happens when you try.
Ok, still didn't try it again, but on Saturday I was unable to run
usrp_siggen and usrp_fft at the same time. basically the app you
started first would stop working and the app you started second would
'grab' the device.
> Whatever more-complicated muxing we may come up with to allow
> arbitrary settings on different daughterboards will almost certainly
> blow the "zero copying" model you guys are prematurely optimizing.
I doubt a generic facility to do zerocopy-dma for userspace usb drivers
will be a premature optimization. It would be an extension to usbdevfs,
which is quite a number of years in age, thus definitely something that
can be optimized by now.
> SOMEBODY in the library or kernel will have to tease those data
> streams apart so the separate applications can access them without
> interfering with each other.
Mh. It was much better if the hardware actually allowed for that.
Doing the demux of data coming from one endpoint in the kernel means it
will require a special purpose kernel driver and be non-portable :(
Doing demux in userspace (like, let's say an additional demux-daemon)
will introduce even more latency than we already have right now, so it's
again something I think we should avoid if at all possible.
Please note that I don't want to complain. The USRP is a great tool the
way it is. But this doesn't mean we can't make up our mind how to
improve it further :)
- Harald Welte <address@hidden> http://gnumonks.org/
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Description: PGP signature