Re: [Discuss-gnuradio] gnuradio on windows 7
On 01/15/2013 12:21 PM, tok...@myranch.com wrote: > I have installed gnuradio and uhd according to the directions given in the > ettus wiki. When I try to run gnuradio-companion.py I get: > > C:\Users\Al>gnuradio-companion.py > Traceback : > File “C:\Program Files\gnuradio\bin\gnuradio-companion.py”, line 22, in > > Import pygtk > ImportError: No module named pygtk > > I tried explicitly adding the PATH to pygtk using Rapid Environment Editor > but that didn’t work. > The pygtk installer should setup that stuff automatically. Did you see the post install instructions on that wiki page for the python dependencies? -josh > Looking for suggestion. > > Thank you. > > Al > > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNURadio on Windows
Robert Roberts wrote: > > - 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. 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. >>
Re: [Discuss-gnuradio] GNURadio on Windows
- 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
Re: [Discuss-gnuradio] GNURadio on Windows
Berndt Josef Wulf wrote: On Monday 06 February 2006 13:06, Robert McGwier wrote: Lots of hooey deleted I would say that this is the single best hope we have for reliable and solid audio under Windows for GnuRadio. I will soon return to this and help Eric, et. al. get it running and into the general cvs download and then all of us can beat it into shape. I might remind Berndt and everyone else that I have NEVER used a release version of GnuRadio. They seem to stay current for about fifteen minutes under a major change was checked in! Bob Berndt Josef Wulf wrote: On Monday 06 February 2006 11:04, Eric Blossom wrote: O cheerio Berndt Wow, many thanks for a very detailed report on portaudio. It has kindled my curiosity, so much so that I've downloaded and built the V19-devel snapshot. It took only a few minor changes to get it going on NetBSD and sofar passed all test applications that I run in this short period of time. Will read the docs in greater details tonight. cheerio Berndt I should have mentioned that Diane Bruce, VA3DB has it running reliably on FreeBSD, you and others have it running on NetBSD so it should run on the *nix things. Since I know from experience that it works well under WindBlows , I am sure this has tremendous potential for this project. Bob -- AMSAT VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats, NJQRP/AMQRP, QRP ARCI, QCWA, FRC. ARRL SDR Wrk Grp Chairman Laziness is the number one inspiration for ingenuity. Guilty as charged! ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNURadio on Windows
On Monday 06 February 2006 13:06, Robert McGwier wrote: > Gerald Youngblood with Flex Radio has made a multimillion dollar > business using V.19. He would be dead in the water without it being > reliable. I have used V.19 on windows, linux, etc. I converted the > gr-audio-alsa code to gr-audio-portaudio superficially and checked it > in. It will soon rise to the top of my plate. I have used portaudio on > top of jack for the new WJST development team. Joe Taylor (K1JT for you > hams) opened the source and invited a few to help. He was using > PortAudio V.19 on Windows. I have been watching PortAudio closely now > for almost two years. > > Recently: > > Eric Wachsmann of Flex Radio "finished" the windows code by getting > portaudio to run reliably on top of Windows WDM-KS. This was Flex > Radio's pay back to that community for the value it has received. This > will be lower latency than linux-2.6 with low latency and alsa or jack > in real time mode. I know as I have measured it. At this low level, > Windows allow you to preempt the kernel and just about everything else > almost without safe guards so you can get some truly tiny latencies. > > Arne Knudsen has steadily erased all problems I have experienced in > using PortAudio on top of OSS, ALSA, and Jack. > > In the last month, multiple people have gotten portaudio to run on > Coreaudio and the Mac stuff is taking off. > > I would say that this is the single best hope we have for reliable and > solid audio under Windows for GnuRadio. I will soon return to this and > help Eric, et. al. get it running and into the general cvs download and > then all of us can beat it into shape. > > I might remind Berndt and everyone else that I have NEVER used a release > version of GnuRadio. They seem to stay current for about fifteen > minutes under a major change was checked in! > > Bob > > Berndt Josef Wulf wrote: > > On Monday 06 February 2006 11:04, Eric Blossom wrote: > >> On Sun, Feb 05, 2006 at 09:12:10PM +0100, Martin Dvh wrote: > 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 > >> > >> I don't think changing the flow graph buffering is going to make any > >> difference. I think that the "right answer" is build a very > >> high-functioning audio sink/source using portaudio. It's on my list, > >> but if somebody else wants to do it, please do (talk to me. I've got > >> some ideas.) Using the portaudio CVS version 19 stuff, there is now > >> good support for windows, and under ALSA and jack under Linux. It's > >> also supposed to work under OS/X using CoreAudio. > > > > There hasn't been any official releases since the 30 June 2003 with > > V18.1. Do you think its a good idea to use the CVS version? > > > > No releases usually means an unacceptable status of the current work > > unfit for public release. > > > > cheerio Berndt Wow, many thanks for a very detailed report on portaudio. It has kindled my curiosity, so much so that I've downloaded and built the V19-devel snapshot. It took only a few minor changes to get it going on NetBSD and sofar passed all test applications that I run in this short period of time. Will read the docs in greater details tonight. cheerio Berndt pgpserrUieW8Y.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNURadio on Windows
Eric Blossom wrote: On Mon, Feb 06, 2006 at 01:46:50PM +1030, Berndt Josef Wulf wrote: I don't think changing the flow graph buffering is going to make any difference. I think that the "right answer" is build a very high-functioning audio sink/source using portaudio. It's on my list, but if somebody else wants to do it, please do (talk to me. I've got some ideas.) Using the portaudio CVS version 19 stuff, there is now good support for windows, and under ALSA and jack under Linux. It's also supposed to work under OS/X using CoreAudio. There hasn't been any official releases since the 30 June 2003 with V18.1. Do you think its a good idea to use the CVS version? No releases usually means an unacceptable status of the current work unfit for public release. Could be. On the other hand it appears that good work is being done in CVS. Lots of activity on their mailing lists. Not sure why they haven't made a release yet. The V18.1 stuff will not solve our problem, so I see zero reason to even consider it. I'm hoping to handle *all* audio issues on *all* platforms with a single gr-audio-portaudio module. [ I could be dreaming, but hey, that's what portaudio is supposed to do ;) ] If we find that their CVS works for us on all platforms we care about, then we talk to the developers and see what it would take to get them to make a V19 official release. Perhaps nobody's asked them in a few years ;) Eric This would seem to be a pretty straightforward as they do maintain a "to-do" list however, the to-do list seems out of date the last time I looked. All I can tell you is what my experience has been and what I have been observing over the past year. PortAudio appears to be taking off after it really languished in a very quiet period (as Berndt has correctly pointed out) for almost a year without major forward motion. Then Arve and Eric W got things rolling again. The traffic level is constant with a few developer messages a day on the portaudio list. Bob -- AMSAT VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats, NJQRP/AMQRP, QRP ARCI, QCWA, FRC. ARRL SDR Wrk Grp Chairman Laziness is the number one inspiration for ingenuity. Guilty as charged! ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNURadio on Windows
On Mon, Feb 06, 2006 at 01:46:50PM +1030, Berndt Josef Wulf wrote: > > > > I don't think changing the flow graph buffering is going to make any > > difference. I think that the "right answer" is build a very > > high-functioning audio sink/source using portaudio. It's on my list, > > but if somebody else wants to do it, please do (talk to me. I've got > > some ideas.) Using the portaudio CVS version 19 stuff, there is now good > > support for windows, and under ALSA and jack under Linux. It's also > > supposed to work under OS/X using CoreAudio. > > > There hasn't been any official releases since the 30 June 2003 with V18.1. Do > you think its a good idea to use the CVS version? > > No releases usually means an unacceptable status of the current work unfit > for > public release. Could be. On the other hand it appears that good work is being done in CVS. Lots of activity on their mailing lists. Not sure why they haven't made a release yet. The V18.1 stuff will not solve our problem, so I see zero reason to even consider it. I'm hoping to handle *all* audio issues on *all* platforms with a single gr-audio-portaudio module. [ I could be dreaming, but hey, that's what portaudio is supposed to do ;) ] If we find that their CVS works for us on all platforms we care about, then we talk to the developers and see what it would take to get them to make a V19 official release. Perhaps nobody's asked them in a few years ;) Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNURadio on Windows
Gerald Youngblood with Flex Radio has made a multimillion dollar business using V.19. He would be dead in the water without it being reliable. I have used V.19 on windows, linux, etc. I converted the gr-audio-alsa code to gr-audio-portaudio superficially and checked it in. It will soon rise to the top of my plate. I have used portaudio on top of jack for the new WJST development team. Joe Taylor (K1JT for you hams) opened the source and invited a few to help. He was using PortAudio V.19 on Windows. I have been watching PortAudio closely now for almost two years. Recently: Eric Wachsmann of Flex Radio "finished" the windows code by getting portaudio to run reliably on top of Windows WDM-KS. This was Flex Radio's pay back to that community for the value it has received. This will be lower latency than linux-2.6 with low latency and alsa or jack in real time mode. I know as I have measured it. At this low level, Windows allow you to preempt the kernel and just about everything else almost without safe guards so you can get some truly tiny latencies. Arne Knudsen has steadily erased all problems I have experienced in using PortAudio on top of OSS, ALSA, and Jack. In the last month, multiple people have gotten portaudio to run on Coreaudio and the Mac stuff is taking off. I would say that this is the single best hope we have for reliable and solid audio under Windows for GnuRadio. I will soon return to this and help Eric, et. al. get it running and into the general cvs download and then all of us can beat it into shape. I might remind Berndt and everyone else that I have NEVER used a release version of GnuRadio. They seem to stay current for about fifteen minutes under a major change was checked in! Bob Berndt Josef Wulf wrote: On Monday 06 February 2006 11:04, Eric Blossom wrote: On Sun, Feb 05, 2006 at 09:12:10PM +0100, Martin Dvh wrote: 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 I don't think changing the flow graph buffering is going to make any difference. I think that the "right answer" is build a very high-functioning audio sink/source using portaudio. It's on my list, but if somebody else wants to do it, please do (talk to me. I've got some ideas.) Using the portaudio CVS version 19 stuff, there is now good support for windows, and under ALSA and jack under Linux. It's also supposed to work under OS/X using CoreAudio. There hasn't been any official releases since the 30 June 2003 with V18.1. Do you think its a good idea to use the CVS version? No releases usually means an unacceptable status of the current work unfit for public release. cheerio Berndt -- AMSAT VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats, NJQRP/AMQRP, QRP ARCI, QCWA, FRC. ARRL SDR Wrk Grp Chairman Laziness is the number one inspiration for ingenuity. Guilty as charged! ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNURadio on Windows
On Monday 06 February 2006 11:04, Eric Blossom wrote: > On Sun, Feb 05, 2006 at 09:12:10PM +0100, Martin Dvh wrote: > > > 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 > > I don't think changing the flow graph buffering is going to make any > difference. I think that the "right answer" is build a very > high-functioning audio sink/source using portaudio. It's on my list, > but if somebody else wants to do it, please do (talk to me. I've got > some ideas.) Using the portaudio CVS version 19 stuff, there is now good > support for windows, and under ALSA and jack under Linux. It's also > supposed to work under OS/X using CoreAudio. There hasn't been any official releases since the 30 June 2003 with V18.1. Do you think its a good idea to use the CVS version? No releases usually means an unacceptable status of the current work unfit for public release. cheerio Berndt pgpFB1CKIwsr5.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNURadio on Windows
On Sun, Feb 05, 2006 at 09:12:10PM +0100, Martin Dvh wrote: > > > > 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 I don't think changing the flow graph buffering is going to make any difference. I think that the "right answer" is build a very high-functioning audio sink/source using portaudio. It's on my list, but if somebody else wants to do it, please do (talk to me. I've got some ideas.) Using the portaudio CVS version 19 stuff, there is now good support for windows, and under ALSA and jack under Linux. It's also supposed to work under OS/X using CoreAudio. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
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. > > > 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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNURadio on Windows
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. 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. Cheers, -- Stephane ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
