[Top][All Lists]

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

Re: [Discuss-gnuradio] GNURadio on Windows

From: Berndt Josef Wulf
Subject: Re: [Discuss-gnuradio] GNURadio on Windows
Date: Mon, 6 Feb 2006 13:46:50 +1030
User-agent: KMail/1.9.1

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

Attachment: pgpaEmPogR6rp.pgp
Description: PGP signature

reply via email to

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