[Top][All Lists]

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

Re: [Discuss-gnuradio] portaudio sink, partial succes on windows WARNING

From: Robert McGwier
Subject: Re: [Discuss-gnuradio] portaudio sink, partial succes on windows WARNING
Date: Tue, 21 Mar 2006 21:10:23 -0500
User-agent: Thunderbird 1.5 (Windows/20051201)

Yes, I believe you are killing the pa threads with this small latency request. I should have remembered this for Windows. In the current sink code, the buffer and latency request are based on 21.33333 ms. For Windows MME, this should be at least 100ms on your first try.

Be careful and always back up the last portaudio library you had working. I have been doing this since things really started heating up in the development and I am glad I did. The stuff I got today from cvs is completely broken for ALSA. CAVEAT EMPTOR.


Martin Dvh wrote:
Robert McGwier wrote:
This is excellent news.  I can't believe we have only been attempting
this for a little over a week.   It will improve.

Please change the 10.666666 ms interval in check_topology UPWARDS until
the crackling stops.  I am sure you are not able to handle 11 msec
latency with wmme.  You will be lucky if it will sustain 100msec
Could this also be the reason for the runtime error popup, and termination of 
the proogram after a few seconds?
If it is not, how do I find out what is causing this error.
(how do you debug an non-descriptive error without generating something that 
will trigger a debugger)
 wmd_ks is MUCH better and that driver does work.  Stephane
submitted to portaudio an official patch that will allow pa19 to be
developed under mingw,  linux, osx,  etc.  They have agreed to adopt it
after review.
Does somebody have built version of this for me (including includes and lib) or 
something I can built easaly with mingw (or if needed msvc2003)
I couldn't find any build or install instructions, so I just did a 
configure/build/install which resulted in a wmme driver.




Martin Dvh wrote:

Robert McGwier wrote:

Thanks to tons of grunt work by Eric,  we have used the highly tuned
ring buffers in the audio_portaudio_sink code and it functions nicely
with a little bit of operator help.    I can now get solid
performance on all Linux hosts with the example code

mono_tone_portaudio.py and multi_tone_portaudio.py.

All worked on oss, alsa, and jack.

Eric got similar performance.

Thomas Schmid ran mono_tone_portaudio.py successfully on his mac with
coreaudio automatically identified as the host.  We had to modify the
buffer size calculation (by forcing it).  This will improve over the
next few days as the audio_portaudio_source gets built and these very
large portaudio messages  which are delivered in device and stream
info structs are parsed more carefully.

It is not clear to me that we want to prefer portaudio talking to
jack over directly talking to jack.  This might change if we
(Stephane,  me, others)  improve the portaudio jack handler.   For
now,  my thinking is we are probably better off and we will be more
versatile talking directly to jack without portaudio but we can do
this kind of thinking after we get this portaudio stuff fully

I am hoping the Windows folks can bring their code up now as well. Portaudio is really solid on Windows as I have been using it there
for ASIO, MME,  and DirectX for two years and after I helped Eric
Wachsman get a leg up (by leaning on my friends for help) he got
WDM-KS running.  WDM-KS is the single lowest latency sound host I
have seen in ANY personal computer but let me say that I have never
used a Mac.  If anyone working on the windows code needs a dll,
export library,  Microsoft .NET 2003 project for v-19 devel, please
let me know.  We should be able to build the dll under mingw but I
have not tried yet.  That said,  all of this portaudio stuff about
latency this and that make very little sense for what we are doing. What we need is not necessarily very low latency but rock solid
performance using buffer sizes that make sense for our applications.
A partial success on windows.
I have portaudio running on windows (just the wmme driver) and for the
first time I hear sounds without too much crackles here.

I needed only a few tweaks.

Most important, don't use standard cvs HEAD of portaudio but the
special cvs v19-devel version
I missed the following comment in one of the portaudio mails
It will be important to stay current:

cvs -d:pserver:address@hidden:/home/cvs co -r v19-devel

I had done a normal cvs HEAD checkout and got loads of problems first.
You really need the -r v19-devel  options.
Once that was sorted out I did the following.
This is all using mingw:
Update/build/install gnuradio-core
do a configure/build/install for portaudio-v19-devel (only default
configure options, so it is using the wmme driver)
Then I had to make the following symbolic link:
/usr/local/lib/pkgconfig/portaudio-2.0.pc  ->

then checkout gr-audio-portaudio
do a bootstrap
Check that the latest libtool version is used
do a configure/build/install

update gnuradio-examples
All run fine ;-)

modify usrp/usrp_wfm_rcv.py to use portaudio
run it
listen to my favourite FM station without too much crackles.
(The audio is not completely clean yet, but probably the ks driver
will help here)

now run usrp/usrp_wfm_pll_PA.py
runtime error popup immediately

change from non-blocking to blocking portaudio
runtime error popup immediately

disable fft displays
runs ok for 5 to 20 seconds
after that a runtime error popup

enable non-blocking again
runtime error popup immediately

The runtime error  I get is a popup:
(also see attached image runtime_error.gif)
"Microsoft Visual C++ Runtime Library

Runtime Error!
Program: d:\Python24\python.exe
abnormal program termination"

So it only works with blocking enabled and no ffts, and only for a few
I think it has to do with something not keeping up.
I can force this error by clicking on any other open program window or
moving another window.

I then tried opening/moving windows while running multi_tone.py and
this causes multi_tone.py to stop too with the same runtime error.
Running a high computational load in the background doesn't seem to
hurt multi_tone.py.

Many thanks for making this work, so far.

No it is time for finetuning and getting rid of problems like these.

I people want to try this at home, I have binary installers for
windows available for this partially working portaudio driver.




Discuss-gnuradio mailing list

Discuss-gnuradio mailing list

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]