@Gale: When I tried Leland's fix I lacked 2 WDMKS inputs and the remaining 2 inputs were incorrectly named - as were the WDMKS outputs. MME worked fine for me. I think it's very system/driver dependent.
Also I forgot the debug log file code - sorry if you wasted a lot of time there.

Btw I dusted off and booted my very stale OSX 10.5 Leopard partition on this machine (yes it's a macbook, and I'm running WinXP on it!) to see if there would be any problems with audio drivers there for 2.0.4 - after all it's the same hardware. But it worked fine.
I also tried to compile Audacity from source, but got stuck in update-everything-you-have-before-you-can-do-anything-useful limbo. But this is not the thread for that.

// Lasse

"There is a crack in everything, that's how the light gets in." - L. Cohen

On Fri, Sep 27, 2013 at 8:08 AM, Gale Andrews <gale@audacityteam.org> wrote:

| From Leland <leland@audacityteam.org>
| Wed, 25 Sep 2013 12:46:33 -0500
| Subject: [Audacity-devel] Debugging never-ending portaudio init
> Gale,
> I know you have a LOT of free time :-),but would you be able to
> apply this to a "test" build and ask a couple of the others that are
> have the looping issue give it a try?  If it does work for them, then a
> copy of "Help -> Audio Device info" would be a good thing to have if
> Audacity successfully.

OK I "assume" I patched it correctly using GNU patch - the SVN
diff then was the same as Lasse's diff.

But there is no debug log file, applying that patch on its own. Do
we want a log file like Leland's patches had? If so, did you want me
to apply Leland's patch, but using Lasse's pa_win_wdmks.c ?

I too think there are problems with Leland's patch, based on
the user comeback. In half the cases, MME is said to be missing
(at least on some launches), even though the hang was fixed.

I haven't seen any reported problems with missing inputs and
outputs after running Leland's patch, but WDM-KS is reported to
have that problem already on some machines in current HEAD.

Were you missing inputs and outputs under all hosts, Lasse, or
just WDM-KS?


> On 9/23/2013 11:13 AM, Lasse Steen Bohnstedt wrote:
> > I'm attaching a diff with my code for loop detection. I've also kept > the /magic-number-1024-timeout/, but I guess people aren't so happy > about that ;-)
> > pa_win_wdmks.c---with-new-loop-detection.diff > <https://docs.google.com/file/d/0B-9LFBxZUuOQZkhVQTh5QzlWMlE/edit?usp=drive_web>
> >
> > Anyway, the 1024 timeout doesn't trigger now, as can be seen from this > log:
> > palog---with-new-loop-detection.txt > <https://docs.google.com/file/d/0B-9LFBxZUuOQTzdBNTdYZUV5cFk/edit?usp=drive_web>
> > Interestingly enough it only escapes from _one_ single loop, but it > also fails in another way, that I've called "Erroneous connection list > - part 2".
> >
> >
> > I've tried my very best to keep it ANSI C - oh how I would have loved > to be able to do it OO!
> > Have a look at it, please.
> >
> >
> > // Lasse
> >
> > "There is a crack in everything, that's how the light gets in." - L. Cohen
> >
> >
> > On Mon, Sep 23, 2013 at 10:58 AM, Leland <leland@audacityteam.org > <mailto:leland@audacityteam.org>> wrote:
> >
> >     On 9/23/2013 2:53 AM, Lasse Steen Bohnstedt wrote:
> >>     There's a problem with Leland's loop-detection in
> >>     GetConnectedPin(..) - it prevents Audacity from finding all
> >>     devices on my system - and those found have "generic" names (fx
> >>     "input" and "output" rather than "microphone" and "speaker").
> >     So, my suspicions mentioned here:
> >
> >     http://sourceforge.net/mailarchive/message.php?msg_id=31427504
> >
> >     were correct.
> >
> >>     Also I suppose the loop-detection has a memory leak as it doesn't
> >>     clean up the array it creates (very minor problem).
> >     Yep, never said it was complete...just asked for assistance in
> >     testing.
> >>     So should I try to refine the loop detection? It would be quite
> >>     straightforward but still some coding required because it would
> >>     mean testing values of several other variables besides the _conn_
> >>     variable.
> >>     On the other hand the /timeout-with-the-magic-number/ version is
> >>     a no-brainer - and it might be better to keep it simple?
> >>     What say you?
> >     Absolutely continue on if you have the time.  You're about our
> >     best bet in getting this resolved properly.  Sure, the artificial
> >     limiter is okay (a "similar" limiter is already doing in the WDMKS
> >     code), but it would be nice to understand and resolve that actual
> >     problem.
> >
> >     Leland

October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
audacity-devel mailing list