[Top][All Lists]

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

Re: [Discuss-gnuradio] GNURadio on Windows

From: Robert McGwier
Subject: Re: [Discuss-gnuradio] GNURadio on Windows
Date: Sun, 05 Feb 2006 21:36:30 -0500
User-agent: Thunderbird 1.5 (Windows/20051201)

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.


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!


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.

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,
Laziness is the number one inspiration for ingenuity.  Guilty as charged!

reply via email to

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