Sonic-pi: Could not boot Sonic Pi Server

Created on 22 Oct 2019  ·  22Comments  ·  Source: sonic-pi-net/sonic-pi

Sonic Pi Boot Error Report

System Information

  • Sonic Pi version: 3.1.0
  • OS: Windows 10

GUI Log

C:\Users\user\.sonic-pi\log\gui.log

[GUI] - Detecting port numbers...
[GUI] - GUI OSC listen port 4558
[GUI] -    port: 4558 [OK]
[GUI] - Server OSC listen port 4557
[GUI] -    port: 4557 [OK]
[GUI] - Server incoming OSC cues port 4559
[GUI] -    port: 4559 [OK]
[GUI] - Scsynth port 4556
[GUI] -    port: 4556 [OK]
[GUI] - Server OSC out port 4558
[GUI] - GUI OSC out port 4557
[GUI] - Scsynth send port 4556
[GUI] - Erlang router port 4560
[GUI] -    port: 4560 [OK]
[GUI] - OSC MIDI out port 4561
[GUI] -    port: 4561 [OK]
[GUI] - OSC MIDI in port 4562
[GUI] -    port: 4562 [OK]
[GUI] - Init script completed
[GUI] - using default editor colours
[GUI] - launching Sonic Pi Server:
[GUI] - starting UDP OSC Server on port 4558...
[GUI] - UDP OSC Server ready and listening
[GUI] - Ruby server pid registered: 4164
[GUI] - waiting for Sonic Pi Server to boot...
............................................................
[GUI] - Critical error! Could not boot Sonic Pi Server.
[GUI] - stopping UDP OSC Server...
[GUI] - UDP OSC Server no longer listening

Server Errors

C:\Users\user\.sonic-pi\log\server-errors.log

Server Output

C:\Users\user\.sonic-pi\log\server-output.log

Sonic Pi server booting...
Using protocol: udp
Detecting port numbers...
Send port: 4558
Listen port: 4557
  - OK
Scsynth port: 4556
  - OK
Scsynth send port: 4556
  - OK
OSC cues port: 4559
  - OK
Erlang port: 4560
  - OK
OSC MIDI out port: 4561
  - OK
OSC MIDI in port: 4562
  - OK


Clearing pids: ["4164"]

Clearing [4164]
  -- command "D:\SonicPi\App\Sonic Pi\app\gui\qt\release\..\..\..\..\app\server\native\ruby\bin\ruby.exe"  --enable-frozen-string-literal -E utf-8 "D:\SonicPi\App\Sonic Pi\app\gui\qt\release\..\..\..\..\app\server\ruby\bin\sonic-pi-server.rb" -u 4557 4558 4556 4556 4559 4560 4561 4562
  -- removing C:/Users/user/AppData/Local/Temp/SonicPiPortableTemp/sonic-pi-pids/4164
  -- force killing 4164
  -- killed 4164

Finished clearing pids

Scsynth Output

C:\Users\user\.sonic-pi\log\scsynth.log

# Starting SuperCollider 2019-10-22 11:44:50

Device options:
  - MME : Microsoft 音效對應表 - Input   (device #0 with 2 ins 0 outs)
  - MME : Microphone Array (Realtek High    (device #1 with 2 ins 0 outs)
  - MME : Microsoft 音效對應表 - Output   (device #2 with 0 ins 2 outs)
  - MME : Speakers (Realtek High Definiti   (device #3 with 0 ins 2 outs)
  - Windows DirectSound : 主要音效擷取驅動程式   (device #4 with 2 ins 0 outs)
  - Windows DirectSound : Microphone Array (Realtek High Definition Audio)   (device #5 with 2 ins 0 outs)
  - Windows DirectSound : 主要音效驅動程式   (device #6 with 0 ins 2 outs)
  - Windows DirectSound : Speakers (Realtek High Definition Audio)   (device #7 with 0 ins 2 outs)
  - Windows WASAPI : Speakers (Realtek High Definition Audio)   (device #8 with 0 ins 2 outs)
  - Windows WASAPI : Microphone Array (Realtek High Definition Audio)   (device #9 with 2 ins 0 outs)
  - Windows WDM-KS : 立體聲混音 (Realtek HD Audio Stereo input)   (device #10 with 2 ins 0 outs)
  - Windows WDM-KS : Speakers (Realtek HD Audio output)   (device #11 with 0 ins 2 outs)
  - Windows WDM-KS : 麥克風排列 (Realtek HD Audio Mic input)   (device #12 with 2 ins 0 outs)

Booting with:
  In: MME : Microphone Array (Realtek High 
  Out: MME : Speakers (Realtek High Definiti
SC_PortAudioDriver: PortAudio failed at Pa_OpenStream with error: 'Unanticipated host error'
could not initialize audio.

Process Log

C:\Users\user\.sonic-pi\log\processes.log

No pids store found here: C:/Users/user/AppData/Local/Temp/SonicPiPortableTemp/sonic-pi-pids
Exiting
Creating pids store: C:/Users/user/AppData/Local/Temp/SonicPiPortableTemp/sonic-pi-pids
Started [4164] [-] "D:\SonicPi\App\Sonic Pi\app\gui\qt\release\..\..\..\..\app\server\native\ruby\bin\ruby.exe"  --enable-frozen-string-literal -E utf-8 "D:\SonicPi\App\Sonic Pi\app\gui\qt\release\..\..\..\..\app\server\ruby\bin\sonic-pi-server.rb" -u 4557 4558 4556 4556 4559 4560 4561 4562 [-] C:/Users/user/AppData/Local/Temp/SonicPiPortableTemp/sonic-pi-pids/4164


Clearing pids: ["4164"]

Clearing [4164]
  -- command "D:\SonicPi\App\Sonic Pi\app\gui\qt\release\..\..\..\..\app\server\native\ruby\bin\ruby.exe"  --enable-frozen-string-literal -E utf-8 "D:\SonicPi\App\Sonic Pi\app\gui\qt\release\..\..\..\..\app\server\ruby\bin\sonic-pi-server.rb" -u 4557 4558 4556 4556 4559 4560 4561 4562
  -- removing C:/Users/user/AppData/Local/Temp/SonicPiPortableTemp/sonic-pi-pids/4164
  -- force killing 4164
  -- killed 4164

Finished clearing pids
boot
Source
picture tiffany92257
👍1

Most helpful comment

@samaaron

Oh, that's sad to hear. Is there any chance you could raise the error with them directly? If this can be fixed in SuperCollider, it will in-turn be fixed in Sonic Pi...

Current status in sc-land is:

  • The most recent version of SC, in Windows, finally supports different devices for input and output.

  • There is a pending issue for non-ASCII characters in audio device names. https://github.com/supercollider/supercollider/pull/4479 That's part of the problem here: "MME : Kopfhörer" currently, I think, doesn't fly.

Under https://github.com/supercollider/supercollider/issues/4616 we are discussing with @gumbo2k.

One of the issues is that basically all other audio software above consumer grade provides a front-end interface to choose the audio device. Looking through a few of the logs, I don't see where Sonic Pi is specifying a device -- leaving it to a system default, perhaps? That's definitely risky in Windows (and OSX for that matter, given the sample rate mismatch error) -- as attested by the hundred open issues about boot failures.

So that discussion has proposed that supercollider should have some sort of "easy mode" or fallback to choose some device or a combination that will work, even if it isn't the system default and isn't something that the user explicitly requested. For a lot of reasons, this is a dubious idea (and you won't find DAWs or softsynths that work this way).

IMO the best solution is:

  1. SC fixes the issue with handling non-ASCII device names.
  2. Sonic Pi uses device info from scsynth stdout to let the user choose.

This will probably take some cooperation between the two projects. I'd prefer cooperation over the current hot-potato approach.

picture jamshark70 on 30 Oct 2019
👍2

All 22 comments

Having same issue on two similar systems!

quintendewilde picture quintendewilde on 23 Oct 2019

@samaaron @tiffany92257 @quintendewilde

I have the same issue and here is the reporting:

Sonic Pi Boot Error Report

System Information

  • Sonic Pi version: 3.1.0
  • OS: macOS 10.14

GUI Log

/Users/chimkan/.sonic-pi/log/gui.log

[GUI] - Detecting port numbers...
[GUI] - GUI OSC listen port 4558
[GUI] -    port: 4558 [OK]
[GUI] - Server OSC listen port 4557
[GUI] -    port: 4557 [OK]
[GUI] - Server incoming OSC cues port 4559
[GUI] -    port: 4559 [OK]
[GUI] - Scsynth port 4556
[GUI] -    port: 4556 [OK]
[GUI] - Server OSC out port 4558
[GUI] - GUI OSC out port 4557
[GUI] - Scsynth send port 4556
[GUI] - Erlang router port 4560
[GUI] -    port: 4560 [OK]
[GUI] - OSC MIDI out port 4561
[GUI] -    port: 4561 [OK]
[GUI] - OSC MIDI in port 4562
[GUI] -    port: 4562 [OK]
[GUI] - Init script completed
[GUI] - using default editor colours
[GUI] - launching Sonic Pi Server:
[GUI] - starting UDP OSC Server on port 4558...
[GUI] - UDP OSC Server ready and listening
[GUI] - Ruby server pid registered: 1345
[GUI] - waiting for Sonic Pi Server to boot...
............................................................
[GUI] - Critical error! Could not boot Sonic Pi Server.
[GUI] - stopping UDP OSC Server...

Server Errors

/Users/chimkan/.sonic-pi/log/server-errors.log

libc++abi.dylib: terminating
/Applications/Sonic Pi.app/app/server/ruby/vendor/sys-proctable-1.1.3/lib/darwin/sys/proctable.rb:163: warning: constant ::Fixnum is deprecated

Server Output

/Users/chimkan/.sonic-pi/log/server-output.log

Sonic Pi server booting...
Using protocol: udp
Detecting port numbers...
Send port: 4558
Listen port: 4557
  - OK
Scsynth port: 4556
  - OK
Scsynth send port: 4556
  - OK
OSC cues port: 4559
  - OK
Erlang port: 4560
  - OK
OSC MIDI out port: 4561
  - OK
OSC MIDI in port: 4562
  - OK
Booting server...


Booting Sonic Pi
----------------

Boot - Booting on OS X
Boot - Checkout audio rates on OSX:
Boot - Input audio rate: 16000.0
Boot - Output audio rate: 48000.0
Boot - Audio input and output rates do not match.
Boot - Attempting to set the input rates to match output rate of 48000.0...
Boot - Starting the SuperCollider server...
Boot - /Applications/Sonic Pi.app/app/server/native/scsynth -u 4556 -a 1024 -m 131072 -D 0 -R 0 -l 1 -i 16 -o 16 -U /Applications/Sonic Pi.app/app/server/native/supercollider/plugins/ -b 4096 -B 127.0.0.1

Scsynth Output

/Users/chimkan/.sonic-pi/log/scsynth.log

# Starting SuperCollider 2019-10-25 17:54:49
Found 0 LADSPA plugins
Number of Devices: 7
   0 : "Built-in Microph"
   1 : "Built-in Output"
   2 : "USB Audio Device"
   3 : "Audiojingle"
   4 : "Audiojingle (UI Sounds)"
   5 : "Chim’s Beats Sol"
   6 : "Chim’s Beats Sol"

ERROR: Input sample rate is 16000, but output is 48000. Mismatched sample rates are not supported. To disable input, set the number of input channels to 0.
could not initialize audio.

Process Log

/Users/chimkan/.sonic-pi/log/processes.log

Clearing pids: []
No pids to clear :-)
Started [1345] [-] /Applications/Sonic Pi.app/Contents/MacOS/../../app/server/native/ruby/bin/ruby --enable-frozen-string-literal -E utf-8 /Applications/Sonic Pi.app/Contents/MacOS/../../app/server/ruby/bin/sonic-pi-server.rb -u 4557 4558 4556 4556 4559 4560 4561 4562 [-] /var/folders/nw/qp573xsj1v59j5c26n3zv9500000gn/T/sonic-pi-pids/1345
designium picture designium on 25 Oct 2019

@designium - the bluetooth issue you were both experiencing is a separate issue, as described in #1856, which will be fixed as of the next release (or you can compile master branch yourself to get the fix for that now).

ethancrawford picture ethancrawford on 26 Oct 2019

@tiffany92257 the issue you are seeing is related to the Supercollider sound engine that Sonic Pi uses, (as also described in https://github.com/samaaron/sonic-pi/issues/2065 for example). The Supercollider folks have addressed this recently (https://github.com/supercollider/supercollider/pull/4475) and therefore I'd imagine that the fix should hopefully be included in the next Sonic Pi release.

ethancrawford picture ethancrawford on 26 Oct 2019

Hi Ethan,
Thank you for looking into it!
Apparently i just ran into the same issue.
Sonic-pi 3.1.0 on Windows 10. Same for portabel and .msi:

```# Starting SuperCollider 2019-10-26 16:55:22

Device options:

  • MME : Microsoft Soundmapper - Input (device #0 with 2 ins 0 outs)
  • MME : Mikrofon (High Definition Audio (device #1 with 2 ins 0 outs)
  • MME : Microsoft Soundmapper - Output (device #2 with 0 ins 2 outs)
  • MME : Lautsprecher (High Definition A (device #3 with 0 ins 2 outs)
  • Windows DirectSound : Primärer Soundaufnahmetreiber (device #4 with 2 ins 0 outs)
  • Windows DirectSound : Mikrofon (High Definition Audio Device) (device #5 with 2 ins 0 outs)
  • Windows DirectSound : Primärer Soundtreiber (device #6 with 0 ins 2 outs)
  • Windows DirectSound : Lautsprecher (High Definition Audio Device) (device #7 with 0 ins 2 outs)
  • Windows WASAPI : Lautsprecher (High Definition Audio Device) (device #8 with 0 ins 2 outs)
  • Windows WASAPI : Mikrofon (High Definition Audio Device) (device #9 with 2 ins 0 outs)
  • Windows WDM-KS : Mikrofon (HD Audio Microphone 2) (device #10 with 2 ins 0 outs)
  • Windows WDM-KS : Speakers (HD Audio Speaker) (device #11 with 0 ins 2 outs)

Booting with:
In: MME : Mikrofon (High Definition Audio
Out: MME : Lautsprecher (High Definition A
SC_PortAudioDriver: PortAudio failed at Pa_OpenStream with error: 'Unanticipated host error'
could not initialize audio.
```

Any idea when a fixed version will be built?

gumbo2k picture gumbo2k on 26 Oct 2019

@gumbo2k not sure sorry. @samaaron's been pretty busy for a while.

ethancrawford picture ethancrawford on 27 Oct 2019

Earliest will be very late 2019, early 2020.

I’m currently in an intensive period of travelling doing events in an attempt to earn enough money to continue developing and supporting Sonic Pi. Travelling stops at the end of Nov for this year.

samaaron picture samaaron on 27 Oct 2019

One thing you can try without needing a new build of Sonic Pi is to see whether the very latest version of SuperCollider boots successfully. If it would be possible to download, boot and make a sound with it and report back your findings here, that would be very useful indeed.

samaaron picture samaaron on 27 Oct 2019

Hello Sam,

Just tried 

SuperCollider 3.10.3
Built from branch 'HEAD' [67a1eb1]

The IDE boots up but the server reports the same error:

Booting server 'localhost' on address 127.0.0.1:57110.

Device options:
  - MME : Microsoft Soundmapper - Input   (device #0 with 2 ins 0 outs)
  - MME : Mikrofon (High Definition Audio   (device #1 with 2 ins 0 outs)
  - MME : Microsoft Soundmapper - Output   (device #2 with 0 ins 2 outs)
  - MME : Kopfhörer (High Definition Audi   (device #3 with 0 ins 2 outs)
  - MME : Lautsprecher (High Definition A   (device #4 with 0 ins 2 outs)
  - Windows DirectSound : Primärer Soundaufnahmetreiber   (device #5 with 2 ins 0 outs)
  - Windows DirectSound : Mikrofon (High Definition Audio Device)   (device #6 with 2 ins 0 outs)
  - Windows DirectSound : Primärer Soundtreiber   (device #7 with 0 ins 2 outs)
  - Windows DirectSound : Kopfhörer (High Definition Audio Device)   (device #8 with 0 ins 2 outs)
  - Windows DirectSound : Lautsprecher (High Definition Audio Device)   (device #9 with 0 ins 2 outs)
  - Windows WASAPI : Kopfhörer (High Definition Audio Device)   (device #10 with 0 ins 2 outs)
  - Windows WASAPI : Lautsprecher (High Definition Audio Device)   (device #11 with 0 ins 2 outs)
  - Windows WASAPI : Mikrofon (High Definition Audio Device)   (device #12 with 2 ins 0 outs)
  - Windows WDM-KS : Headphones (HD Audio-Kopfhörer)   (device #13 with 0 ins 2 outs)
  - Windows WDM-KS : Mikrofon (HD Audio Microphone 2)   (device #14 with 2 ins 0 outs)
  - Windows WDM-KS : Speakers (HD Audio Speaker)   (device #15 with 0 ins 2 outs)

Requested devices:
  In (matching device NOT found):
  - (null)
  Out (matching device NOT found):
  - (null)

Selecting default system input/output devices

Booting with:
  In: MME : Mikrofon (High Definition Audio
  Out: MME : Kopfhörer (High Definition Audi
SC_PortAudioDriver: PortAudio failed at Pa_OpenStream with error: 'Unanticipated host error'
could not initialize audio.
Server 'localhost' exited with exit code -1073740791.

That was with headphones ("Kopfhörer") connected.
Disconnecting headphones and rebooting the server I get pretty much the same error:

Selecting default system input/output devices

Booting with:
  In: MME : Mikrofon (High Definition Audio
  Out: MME : Lautsprecher (High Definition A
SC_PortAudioDriver: PortAudio failed at Pa_OpenStream with error: 'Unanticipated host error'
could not initialize audio.
Server 'localhost' exited with exit code -1073740791.

I'll try to get the bleeding edge version to run and see if that changes anything.
PS: Great show at "goto; Berlin!" I am sorry I had to leave after your talk and didn't catch the party.

gumbo2k picture gumbo2k on 27 Oct 2019

Oh, that's sad to hear. Is there any chance you could raise the error with them directly? If this can be fixed in SuperCollider, it will in-turn be fixed in Sonic Pi...

samaaron picture samaaron on 27 Oct 2019

I managed to get the server to boot. Hurray !

At least I managed to get it to boot

  • from the windows command line and
  • if I specify a different sound device.

As you can see it doesn't like the non ascii names in some of the devices. 

C:\Users\hlangos\Downloads\SC-Windows-x64-069818b80335a862ae0f46e2f95149c8ef0bc54b\SuperCollider>scsynth -u 12345 -H "Windows WDM-KS : Speakers (HD Audio Speaker)"

Device options:
  - MME : Microsoft Soundmapper - Input   (device #0 with 2 ins 0 outs)
  - MME : Mikrofon (High Definition Audio   (device #1 with 2 ins 0 outs)
  - MME : Microsoft Soundmapper - Output   (device #2 with 0 ins 2 outs)
  - MME : Lautsprecher (High Definition A   (device #3 with 0 ins 2 outs)
  - Windows DirectSound : Primärer Soundaufnahmetreiber   (device #4 with 2 ins 0 outs)
  - Windows DirectSound : Mikrofon (High Definition Audio Device)   (device #5 with 2 ins 0 outs)
  - Windows DirectSound : Primärer Soundtreiber   (device #6 with 0 ins 2 outs)
  - Windows DirectSound : Lautsprecher (High Definition Audio Device)   (device #7 with 0 ins 2 outs)
  - Windows WASAPI : Lautsprecher (High Definition Audio Device)   (device #8 with 0 ins 2 outs)
  - Windows WASAPI : Mikrofon (High Definition Audio Device)   (device #9 with 2 ins 0 outs)
  - Windows WDM-KS : Mikrofon (HD Audio Microphone 2)   (device #10 with 2 ins 0 outs)
  - Windows WDM-KS : Speakers (HD Audio Speaker)   (device #11 with 0 ins 2 outs)

Requested devices:
  In (matching device NOT found):
  - Windows WDM-KS : Speakers (HD Audio Speaker)
  Out (matching device found):
  - Windows WDM-KS : Speakers (HD Audio Speaker)

Selecting default Windows WDM-KS input device

Booting with:
  In: Windows WDM-KS : Mikrofon (HD Audio Microphone 2)
  Out: Windows WDM-KS : Speakers (HD Audio Speaker)
  Sample rate: 44100.000
  Latency (in/out): 0.011 / 0.011 sec
SC_AudioDriver: sample rate = 44100.000000, driver's block size = 64
SuperCollider 3 server ready.

I didn't manage to produce a single beep yet, though.

Is there a way to specify command line options for scsynth in sonic pi ?

gumbo2k picture gumbo2k on 27 Oct 2019

Ok. Now I managed to get the supercollider ide to pick the right device:

o = Server.default.options;
o.inDevice_("Windows WDM-KS : Mikrofon");
o.outDevice_("Windows WDM-KS : Speakers");
Server.default.reboot;

This doesn't help me with sonic pi, yet.
I've submitted a bug report to SuperCollider https://github.com/supercollider/supercollider/issues/4616#issue-513036536
Let's hope for the best.

gumbo2k picture gumbo2k on 28 Oct 2019

@samaaron

Oh, that's sad to hear. Is there any chance you could raise the error with them directly? If this can be fixed in SuperCollider, it will in-turn be fixed in Sonic Pi...

Current status in sc-land is:

  • The most recent version of SC, in Windows, finally supports different devices for input and output.

  • There is a pending issue for non-ASCII characters in audio device names. https://github.com/supercollider/supercollider/pull/4479 That's part of the problem here: "MME : Kopfhörer" currently, I think, doesn't fly.

Under https://github.com/supercollider/supercollider/issues/4616 we are discussing with @gumbo2k.

One of the issues is that basically all other audio software above consumer grade provides a front-end interface to choose the audio device. Looking through a few of the logs, I don't see where Sonic Pi is specifying a device -- leaving it to a system default, perhaps? That's definitely risky in Windows (and OSX for that matter, given the sample rate mismatch error) -- as attested by the hundred open issues about boot failures.

So that discussion has proposed that supercollider should have some sort of "easy mode" or fallback to choose some device or a combination that will work, even if it isn't the system default and isn't something that the user explicitly requested. For a lot of reasons, this is a dubious idea (and you won't find DAWs or softsynths that work this way).

IMO the best solution is:

  1. SC fixes the issue with handling non-ASCII device names.
  2. Sonic Pi uses device info from scsynth stdout to let the user choose.

This will probably take some cooperation between the two projects. I'd prefer cooperation over the current hot-potato approach.

jamshark70 picture jamshark70 on 30 Oct 2019
👍2

I have the same issue and I believe its a problem where the old processes won't stop? Because when I repair it I get an issue where its still open or something...

Edit: Repairing works for one session.

AlaafGhub picture AlaafGhub on 10 Nov 2019

On Windows, providing "-H devicename"arguments in the scsynth.exe command line allows the named audio device to be specified. The devicename needs to match the device name that SuperCollider uses, including the API part. I've successfully modified my local Sonic Pi installation by editing serverrubylibsonicpiscsynthexternal.rb so it takes the user-specified value from an environment variable and passes it on to scsynth. Not the cleanest possible solution, but it at least allows user control over the device.

adamr66 picture adamr66 on 13 Feb 2020

What file do I need to change in Linux (Raspian) to get it running? The whole /usr/app directory doesn't exist.

cat /home/pi/.sonic-pi/log/scsynth.log

Starting SuperCollider 2020-02-25 20:20:21

Found 0 LADSPA plugins
* ERROR: open directory failed '/usr/app/server/native/extra-ugens/': No such file or directory
JackDriver: client name is 'SuperCollider'
SC_AudioDriver: sample rate = 44100.000000, driver's block size = 2048
SuperCollider 3 server ready.
JackDriver: max output latency 139.3 ms

someSven picture someSven on 25 Feb 2020

Which version of raspbian are you using? Which version of SP is Pi? It looks like Supercollider is running from your log. The extra-ugens error is not important.

rbnpi picture rbnpi on 25 Feb 2020

scsynth 3.10.0 (Built from branch 'not_a_git_checkout' [na])
Linux namedeleted 4.19.97-v7+ #1294 SMP Thu Jan 30 13:15:58 GMT 2020 armv7l GNU/Linux
Raspbian GNU/Linux 10 (buster)
Sonic-Pi 3.1.0
ruby 2.5.5p157 (2019-03-15 revision 67260) [arm-linux-gnueabihf]

Server Errors

/home/pi/.sonic-pi/log/server-errors.log
```
Failed to load the fast_osc c-extension, falling back to pure Ruby version
Overriding fast_osc c-extension FastOsc::decode_single_message, falling back to pure Ruby version
ruby: No such file or directory -- /usr/app/server/ruby/bin/task-register.rb (LoadError)

someSven picture someSven on 26 Feb 2020

@jamshark70

IMO the best solution is:

SC fixes the issue with handling non-ASCII device names.
Sonic Pi uses device info from scsynth stdout to let the user choose.
This will probably take some cooperation between the two projects. I'd prefer cooperation over the current hot-potato approach.

Apologies - somehow I didn't see this - I was crazy busy at the time you posted it.

Completely agreed - hot-potato is no fun! I also think that with a little bit of co-operation on both sides, this would be much easier to fix.

In general, the majority of Sonic Pi users likely don't know what an audio device is and wouldn't know how to switch it. I completely understand that this is not an issue or concern for sc-land in general. I also completely understand that having an audio-device selector is typical for audio applications and it is something I would love to add some point soon.

I also want to make an easy-mode.

For example, this is what I've done with improving bluetooth headphone support for macOS - I query and change the input device and audio rate if possible to match the output rate to give a greater chance that bluetooth headphones will 'just work'. https://github.com/samaaron/sonic-pi/commit/35074ce3a3a956c140eea54a542b05ab2f3a737d

One thing I don't currently have easy access to at the moment is a nice device listing that presents me strings that scsynth will be happy accepting. I acknowledge that you get a listing like this if you boot the server, but I don't want to have to boot a server, then kill it, to then boot it again with the correct settings. If there's a way of booting it in 'dummy' mode, then that would work. Alternatively, if there was a simple flag for scsynth which just printed out that listing, that would be truly amazing, and I'm pretty sure I could get all this other stuff done in a way that wouldn't require any further changes in sc-land.

Would it therefore be at all possible to either create a 'dummy' boot mode which doesn't actually start a server, but just go through the motions including printing the device listings, or would it be possible to add an explicit flag which just printed the devices to stdout.

samaaron picture samaaron on 5 Mar 2020

One thing I don't currently have easy access to at the moment is a nice device listing that presents me strings that scsynth will be happy accepting.

https://github.com/supercollider/supercollider/commit/e53f947b924f8a6a364c47a04ce18085b29a2942 = "sclang: add PortAudio bindings for listing audio devices"

This will be in SC 3.11 (just checked, it is definitely in the commit history for the 3.11 branch). 3.11 is due out in a matter of days... so, excellent timing to revisit this.

I haven't tried it myself in Windows, but it should be compatible with the Mac method. (Linux uses Jack by default, in which case SC isn't responsible for devices.)

In general, the majority of Sonic Pi users likely don't know what an audio device is and wouldn't know how to switch it.

I'm not sure what to do about that except give them a user friendly interface (which will be easier to do with SC 3.11).

jamshark70 picture jamshark70 on 6 Mar 2020
❤1

@jamshark70 ah - looks like that patch is just for SC Lang, not scsynth. Sonic Pi doesn't use SC Lang so can't take advantage of this.

Ideally I could call something like:

scsynth --list-devices

and it would return a list of available input and output devices (and their supported rates). This is something I could parse and work with to give them a friendly user interface and also to help choose the default to something that's more likely to work.

samaaron picture samaaron on 6 Mar 2020

Oh ok, I understand.

There's https://github.com/supercollider/supercollider/issues/278 but it never found a developer to work on it, unfortunately.

A possible workaround might be, in 3.11, to run an sclang script to call devices and dump the results to a text file that Sonic Pi could read. The disadvantage is launching yet another process but it wouldn't try to connect to an audio device and fail. (It's not a particularly great workaround but it may be better than parsing scsynth's output.)

It would be worth figuring out how to raise the profile of that feature request... Issue 278 does mention exactly your case: "the information is not accessible by other scsynth clients other than sclang (JCollider, Eisenkraut, ScalaCollider...)."

jamshark70 picture jamshark70 on 7 Mar 2020
Was this page helpful?
0 / 5 - 0 ratings

Related issues

Tob027 picture Tob027  ·  4Comments
farukbigez picture farukbigez  ·  7Comments
chunseoklee picture chunseoklee  ·  4Comments
NathanMEvans picture NathanMEvans  ·  5Comments
sbeaumont picture sbeaumont  ·  3Comments