[Top][All Lists]
[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
>>
>
>
>