Maybe you could try to add this to your startup.scd file (inside Platform.userConfigDir) and see if that helps:

[\internal, \local].do { |s|
  s = Server.perform(s);
  s.options.numInputBusChannels  = 0;
};

I've found that it can be worked around by using ASIO4ALL, but starting scsynth with 0 input bus channels doesn't make any difference for me. ASIO4ALL seems to be necessary on typical Windows systems with integrated motherboard audio.

It would be good if this could be fixed... ASIO4ALL is a good solution for people who explicitly want to run SuperCollider for music making purposes etc, but for situations like using scsynth as a sound engine for an application / game this is a rather undesirable requirement for the end user.

Actually, I've found that on some systems ASIO4ALL does not seem to work reliably. I had a lot of fun yesterday debugging this...

Often, plugging something in to an audio input jack will allow scsynth to start with MME drivers on basic hardware. I'm preparing audio for an exhibition at the moment, and this is what we'll be doing, and what other people involved who don't have special audio hardware currently have to do to make things run reliably. It seems much more stable than ASIO4ALL on the machines in question.

I've not tried fiddling directly with PortAudio myself, but I see that when you fall back to Pa_OpenDefaultStream, you do so with 2 input channels specified. Maybe simply changing that argument to 0 on line 413 of SC_PortAudio.cpp would be adequate on the basis that if normal configuration fails up to that point, you should use the safest default possible and might not care about input. Alternatively, at least if it respected numInputBusChannels = 0, then the workaround suggested by gusano aught to work; it's clear that it won't with the code as is.

I'm not in a position to test this out myself just at the moment, but once the exhibition is up and running I can try to build with that change in. I'm sure it would be much easier for someone who already has a Windows SC build environment set up, though.

Cheers, any feedback much appreciated...

3f78951
solved that?

I think it did! I tested on Thinkpad X201 with Win8.1 64-bit both with the inbuilt device and a gigaport HD+, a portable USB-soundcard with 8 outs and no in. I disabled the internal mic and everything went beautifully: with the Gigaport plugged in, the server would boot with MME : Speakers (GIGAPort HD+) only, with no in. Without the Gigaport connected, the server would come up with the outs of the internal sound device. Even the opposite worked: with enabled mice and disabled sound out, the server would boot with In only. Lovely! Thank you...

Let's wait for one more confirmation and then close this and relateds....

It's been confirmed by Sonic Pi users, so I'll close.