Robert Roberts wrote:
----- Original Message -----
From: Martin Dvh <address@hidden>
Date: Sunday, February 5, 2006 3:12 pm
Subject: Re: [Discuss-gnuradio] GNURadio on Windows
Stephane Fillod wrote:
Hi Chris,
On Sat, Feb 04, 2006 at 03:26:29PM -0500, Robert Roberts wrote:
Is there anyone out there working with GNURadio on Windows with
the USRP?
Disclaimer: I'm not using the USRP on Windows, just lending a
hand in
porting the code. Among the lurker on the list, are there any
Windows gurus who can help better, starting with, for example,
beta-testing the Windows Installer Martin kindly released?
Rem: no need to own an USRP to try out GNU Radio on Windows.
The current install files from Martin have one issue with the
way
that I
install them. When I attempt to run any of the USRP code it
looks for
the usrp_prims.dll in the C:\Python24\site-packages directory.
The>>>>installer places that file in C:\Program Files\USRP\bin
Copying
the>>file fixes this.
The installer should have automatically put C:\Program
Files\USRP\bin on your PATH.
I will check, maybe I overlooked something.
Maybe I should just put usrp_prims.dll in C:\Python24\site-
packages. It is a python related and URP related file.
Your installer appears to add the Usrp directory in the path
correctly,> I've also tried adding the path by hand and I get the
same error (on
multiple machines), my only solution has been to place the
usrp_prims.dll in the site-packages folder.
I should check why it worked for me, I probably forgot to delete
usrp_prims.dll from the site-packages dir before I tested.
(It is installed there when I run the normal install process from
mingw)I will change the install location to the site-packages dir
as soon as I have a little time.
(Very busy right now)
I don't mind if somebody sends me a remainder next week if I forget
to do this.
(I sort of have a habit of forgetting these things)
Also, once we get some stability would you mind if I created a CD
iso> image of everything needed? This way there can be a one stop
shop to
install GNURadio on Windows boxes. :-)
"once we get some stability" is an important issue.
If it is not properly tested and you start distributing an iso,
expect loads of questions flooding the mailing-list.
We really need more testers.
We need audio fixed.
We need the wxgui to perform better (especially the scope_sink)
We need the first run of the usrp not result in an error. (First
run now always gives an error about not being able to attach to
interface,after the firmware has been loaded it is fine on next
runs. This is an usrp/usb driver issue)
We really need more testers.
It is also a good idea to update the wiki. The windows
documentation is surely out-of-date/incomplete.
Feel free to add, update anything needed.
http://comsec.com/wiki?CategoryInstall
http://comsec.com/wiki?MinGW
http://comsec.com/wiki?UsrpMinGW
http://comsec.com/wiki?Cygwin
Maybe it is also a good idea to put a link to the CategoryInstall
on the homepage of the wiki.
http://comsec.com/wiki
Greetings,
Martin
Was the C:\Program Files\USRP\bin directory in your PATH?
The audio is very choppy with the WFM_RCV example. I found that
going>>into the Task Manager and setting Pythons priority to
"real
time" fixes
this better. Are there any other tweaks out there?
Perhaps not enough buffering? Having source/sink in threads
helps
sometimes.> Martin will have better insight on the topic.
The code needs fixing but I haven't spend much time on optimizing
it yet.
I think it does has something to do with threads. Maybe another
buffer layer or number of buffers (pingpong) will fix it.
Put the windows_audio sink in another thread will probably help,
but I don't know howto.
I just copied the ideas for the windows_audio driver from other
GPL'ed windows audio projects.
The windows_audio driver also needs an audio_source implementation.
An other solution would be to implement a direct_audio driver
(directX audio) in stead of fixing this.
I suspect you would have much less synchronisation issues.
A quick-and-dirty solution test would indeed be to increase the
audio-buffer.
(You need to build from source to test this)
An even more quick and dirty test is to change the default value
for all buffers between blocks.
(Can be done after install)
change the value for self.fixed_buffer_size in C:\Python24\site-
packages\gnuradio\flow_graph.pyline50:
self.fixed_buffer_size = 32*1024
Change this to a higher/lower value and see what it does for you.
The default is 32*1024 which means 32 kByte
Note that this value is for ALL blocks, so you might break things
when you make it too low and slow things down when you make it
too
high.
greetings,
Martin