discuss-gnuradio
[Top][All Lists]
Advanced

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

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


From: Martin Dvh
Subject: Re: [Discuss-gnuradio] portaudio sink, partial succes on windows
Date: Wed, 22 Mar 2006 00:56:01 +0100
User-agent: Debian Thunderbird 1.0.2 (X11/20051002)

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
> latency. 
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.

Greetings,
Martin



> 
> Congratulations.
> 
> Bob
> 
> 
> 
> 
> 
> 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
>>> stabilized.
>>>
>>> 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
>> portaudio
>>
>> 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  ->
>> /usr/local/lib/pkgconfig/portaudio.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
>> run:
>> dial_tone_portaudio.py
>> mono_tone_portaudio.py
>> multi_tone_portaudio.py
>> 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
>> seconds.
>> 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.
>>
>>
>> Greetings,
>> Martin
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> address@hidden
>> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>   
> 
> 
> 





reply via email to

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