Re: [Discuss-gnuradio] GNURadio on Windows

[Martin Dvh]

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
>>
>>
> 
>