Detecting audio device after boot

Questions
1

hi guys
Is it possible for the language, retrieve information about the actual audio device the synth is connected to when working on Windows?

Let me better explain: when I’m on Windows I’m used to work like these: settings all the server options and then running the main code.

(
s = Server.local;
s.options.sampleRate = 48000;
s.options.numWireBufs_(256);
s.options.numOutputBusChannels_( 6 );
s.latency = 0.20;
s.options.device = "ASIO : US-16x08 ASIO";

s.waitForBoot({
    // my main code here
});
)

One of the most important settings to set beforehand to me is to address a specific sound device in order for the project to actually work as expected.

Recently I’ve come across an issue with the hardware I’m working with: the PC sometimes is not capable of correctly detecting the sound card (a Tascam US-16x08) at startup so, SuperCollider will corretly boot but falling back to the default audio device. Only a PC reboot can solve the problem.

When the issue occurs, the post window is telling me something like this:

Booting server 'localhost' on address 127.0.0.1:57110.

Device options:
  - MME : Microsoft Sound Mapper - Input   (device #0 with 2 ins 0 outs)
  - MME : Microphone (High Definition Aud   (device #1 with 2 ins 0 outs)
  - MME : Microsoft Sound Mapper - Output   (device #2 with 0 ins 2 outs)
  - MME : Altoparlanti (High Definition A   (device #3 with 0 ins 6 outs)
  - Windows DirectSound : Driver primario di acquisizione suoni   (device #4 with 2 ins 0 outs)
  - Windows DirectSound : Microphone (High Definition Audio Device)   (device #5 with 2 ins 0 outs)
  - Windows DirectSound : Driver audio principale   (device #6 with 0 ins 2 outs)
  - Windows DirectSound : Altoparlanti (High Definition Audio Device)   (device #7 with 0 ins 6 outs)
  - ASIO : ASIO4ALL v2   (device #8 with 2 ins 6 outs)
  - Windows WASAPI : Altoparlanti (High Definition Audio Device)   (device #9 with 0 ins 2 outs)
  - Windows WASAPI : Microphone (High Definition Audio Device)   (device #10 with 2 ins 0 outs)
  - Windows WDM-KS : Speakers (HD Audio Speaker)   (device #11 with 0 ins 6 outs)
  - Windows WDM-KS : Microfono (HD Audio Microphone)   (device #12 with 2 ins 0 outs)

Requested devices:
  In (matching device NOT found):
  - ASIO : US-16x08 ASIO
  Out (matching device NOT found):
  - ASIO : US-16x08 ASIO

Selecting default system input/output devices

Booting with:
  In: MME : Microphone (High Definition Aud
  Out: MME : Altoparlanti (High Definition A
  Sample rate: 48000.000
  Latency (in/out): 0.013 / 0.093 sec
SC_AudioDriver: sample rate = 48000.000000, driver's block size = 64
SuperCollider 3 server ready.
Requested notification messages from server 'localhost'
localhost: server process's maxLogins (1) matches with my options.
localhost: keeping clientID (0) as confirmed by server process.
Shared memory server interface initialized

As you see, the PC is not detecting the sound device I would like to use:

Requested devices:
  In (matching device NOT found):
  - ASIO : US-16x08 ASIO
  Out (matching device NOT found):
  - ASIO : US-16x08 ASIO

instead it is using the default one:

Booting with:
  In: MME : Microphone (High Definition Aud
  Out: MME : Altoparlanti (High Definition A

I would like SuperCollider to be able of reboot the PC when the wrong sound card is selected as audio device so, initially I thought that checking for equality between s.options.device and the string ASIO : US-16x08 ASIO after booting will do the job but, this option stays always the same, even if another hardware audio device has been selected by the server.

I have the suspicion that this option can be written by the user, but then, in the event of an error like mine, whereby a different device is chosen as fallback by the server, the option is not updated with the name of the device actually in use; although, this information must exist somewhere, since the post window is able to detect it and print it out.

How can I intercept this information? maybe s.options.device is not the correct place where i should look for?
Thank you so much for your help

2

Like this?

(
s = Server.local;
s.options.sampleRate = 48000;
s.options.numWireBufs_(256);
s.options.numOutputBusChannels_( 6 );
s.latency = 0.20;
s.options.device = "ASIO : US-16x08 ASIO";

ServerOptions.devices.join.contains(s.options.device).if { 
// ServerOptions.devices.join.contains("US-16x08").if { 
s.waitForBoot({
    // your main code here
})
} { 
"shutdown /r /t 0".unixCmd // works on Windows
}
)

Please check also:

Post << ServerOptions.devices

ServerOptions.devices.do { |anInOutDevice, index| ("Device index no. %: %\n").postf(index,anInOutDevice ) }

ServerOptions.inDevices

ServerOptions.outDevices

However, could you do the following?

  • Reinstall the audio driver for US-16x08
  • Check the connection with the PC and the US-16x08
  • Check power on of US-16x08
3

I have always wished that there was an option to prevent this. I’ve just opened an issue on GitHub: Server option to disable audio device fallback · Issue #6691 · supercollider/supercollider · GitHub

2 Likes
4

Thank you so much @prko ,
I can definitely use this method: it will work in my case but this is different in a subtle way from what I was thinking of doing.

Here we are listing all devices that are visible in order to find out whether the desired device exists among them (the server has not yet actually started). I would rather be interested in finding out which device is currently in use (the server has already been started).

I take it that there is therefore no method of finding out which device is in use after the server has been started?

However, could you do the following?

  • Reinstall the audio driver for US-16x08
  • Check the connection with the PC and the US-16x08
  • Check power on of US-16x08

Thank you very much for all your suggestions, in fact I have already done all these procedures but without success. I’ve also tried a number of other methods involving:

  • the bios and USB port enable/disable settings during shutdown/hibernation;
  • some batch script invoking the pnputil tool;

… nothig work;

From a series of dump files generated by the crash of another piece of software running on the same machine, I discovered it was most likely a faulty CPU processor (because a 13th generation i9).

The solution seems to be to substitute the processor :smiling_face_with_tear:

5

Yes, I understood that, but I did not know how to do it, so I suggested this method.

The following output

is defined in the server/scsynth/SC_PortAudio.cpp file:

However, I do not know C++ and I could not find an instance method for ServerOption to get the devices currently used by a server. I would appreciate it if someone could let us know if such a method already exists.

Oh, sorry to hear that :smiling_face_with_tear:

1 Like