Re: [Discuss-gnuradio] GNURadio on Windows

[Martin Dvh]

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.

> 
> 
> 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.py
line50:        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