discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] GNURadio on Windows


From: Robert Roberts
Subject: Re: [Discuss-gnuradio] GNURadio on Windows
Date: Mon, 06 Feb 2006 20:19:14 -0500


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



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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]