----- Original Message ----- From: Martin Dvh <[EMAIL PROTECTED]> 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. 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. :-) > > > > > > 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 > > _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
