SonicPi doesn’t stream audio over Discord’s client on Windows. The video signal can be captured, but the audio signal can’t. I have never encountered this issue for any other program I regularly use. This includes audio-focused applications like LMMS, VCV Rack and Audacity. Here are the list of things I have tried in order to remedy this issue:
Add SonicPi’s window to Discord as a game in order to allow the streaming client to get a better context
Use a virtual cable to patch scsynth.exe directly to the microphone input
Use Voicemeeter to create a virtual audio stream that mixes microphone audio with SonicPi
Try all three versions of voicemeeter to try the exact same thing with each virtual input
Use the Windows task manager to force SonicPi to use a virtual audio input that connects to Discord
Use VDiscord to create a virtual video stream using every single audio input available, including the hidden inputs available from the audio settings menu (It just parrots the video signal back for no reason)
Spend four hours with a hobbyist audio engineer walking me through all the previous steps and more
Every single one of these solutions was totally ineffective and only created more problems. It seems to be that while most applications in windows occur in a single window, SonicPi is an application spread across several windows. Thing is, SonicPi’s audio preferences menu is extremely bare bones. Where are the options for testing output or changing which device the audio is sent to? There aren’t any. You have a single volume slider, an option for external synths and basic speaker settings. That’s it.
I shouldn’t have to learn how to use a virtual mixer in order to play music for my friends. It should just work. Even then, SonicPi really doesn’t like running on Windows at all. You have to restart the app constantly just to get any kind of response from it. This goes especially for changing which outputs are forced via Windows. Even if the posted solutions were effective, that would still mean I can’t talk and code at the same time, which makes teaching friends how to live code a non-starter. What’s even more egregious is that other apps that have a streaming feature work just fine. I didn’t have to do anything special to get it to work on Microsoft Teams or Zoom, so what gives? I offer the following suggestions:
A) Discord’s streaming client is so flaky that it will not transmit the audio of any application with more than one sub-process as SonicPi does, meaning that a future update from Discord will be required
B) SonicPi has failed to transmit audio on the Windows platform in such a way that it can be easily read
C) One of SonicPi’s sub-processes has an incredibly rare bug when attempting a Discord stream
D) The sounds produced by SonicPi are eldritch hallucinations brought about by collective invention
E) All of the above
There is no video proof of anyone performing this task and succeeding. I understand that SonicPi is a niche product for a niche audience that is unlikely to be interested in this use case. However, audience metrics released in 2023 showed Discord having an active user base of over 560 million people (Source: The Latest Discord Statistics & Trends for 2023). Even if only a small percentage of those users have heard of Sonic Pi, most of the users on this forum either have Discord installed or did at some point. It is worth investigating regardless of how many people would actually be grateful for it.
It’s also worth noting that OBS has the same issue for me.
Please don’t link me to any existing tutorials on the subject. I have followed them to the letter multiple times and they do not work. I’m only interested either in novel information on a potential fix, and what further action I can take to get the code changed. As well as what contact has been made with Discord in terms of a resolution. Given that this has been known about for over three years I doubt anything will be done, but seeing as I’m new here I’m going to be polite and give it the benefit of the doubt. What now?
I hardly ever use Windows, but mainly Macs, but I should perhaps say that over the last week I have been working with Sonic Pi on a Raspberry Pi which is moving to a new OS based on debian bookworm. They have chosen pipewire as the mainstay of the audiosystem, and I have now got Sonic Pi working under pipewire-jack. I have spent this evening playingwith sending Sonic Pi audio to different audoi outputs at will.including hdmi output, usb output, audio jack output, bluetooth speaker output. It is also quite happy to share outputs with other apps eg Spotify playing at the same time. I have also had it sending audio to more than one output at the same time, and even playing differnt tunes to two separate stereo streams. You can easily set this up with a graphical patch panel qwpgraph, or script the connections you want. So maybe things can change.
However there is no huge staff to do all this. It is down to volunteers to help Sam Aaron the creator and main developer. It is also quite challenging to support a range of machines: Mac, Windows and linux with a huge variety of audio setups.
So what happens now is nothing. We just hope someone who knows how Windows API connects to Sonic PI turns up? I find this to be a frustrating non-answer that doesn’t address the issue. None of the software you mentioned is available on Windows. It’s all specific to Arch Linux. I’d be happy to give it my best shot in terms of altering the code to enable this functionality, but:
I don’t know the first thing about how SonicPi was programmed
We still haven’t conclusively determined where the problem comes from
If the problem is with Discord or Voicemeeter, that’s propriatary software we don’t have access to
At this point it might be enough of a problem to be worth investigating Tides or another live coding suite
Furthermore, your answer doesn’t even explicitly indicate or show SonicPi transmitting audio through a Discord stream in a way other people can listen to. If this problem doesn’t exist on Arch, then that might help in terms of eliminating possibilities and creating an action plan. As it stands right now, we’re at an impasse. There’s nothing strange or unusual about my audio setup other than me using wireless headphones.
If you can recommend a new solution or show video proof of it working on Arch, then that would be most helpful. A screenshot would need to show either Discord showing an signal with SonicPi open and no microphone connected. Otherwise I’d ask to be sent the resources necessary to navigate the source code.
I had a brief look at this today and I think that you may find Voicemeeter Potato could connect you to discord. I installed it on an old PC and got Sonic Pi working as an input (it actually showed it as scsynth.exe) There are videos on Youtube showing Voicemeeter being used with discord.
So it appears that while native support doesn’t work and is unlikely to work soon, it is totally possible to bridge the audio from Sonic Pi into a virtual input, which you can then configure Discord to use. I had the most success with Voice Meeter banana after actually bothering to read the manual and understand how the program works. Before I was just blindly clicking buttons not understanding what they all mean. You also need OBS installed to get the visual component over. This appears to be the workaround Linux users have to use for every program. I’ll write a more detailed summary in a new post some other time but for right now I’m just happy to have gotten it working.
So you’re saying it works after you’ve read the manual? Guess the time spent writing these rather aggressive posts demanding solutions for this free and open source software Sam coded out of the kindness of his heart was wasted. @robin.newman is a kinder and more patient man than I am.
Well I’m glad you have a working solution. As far as Sonic Pi is concerned its evolution depends upon the positive halp of individuals prepared to support its development. Suggestions are welcome, but their implementation depends on resourcing. If you wish to help, then the relevant area to look at in the source files on github is the file daemon.rb which can be found in app/server/ruby/bin in the source distribution. This is basically responsible for opening up all the participating parts of Sonic Pi which is quite complex, and then making sure they all close down correctly before it quits. One of those parts is starting up scsynth and connecting its output to the currently selected audio output, accommodating whether it is running on Linuix, Windows or Mac. There is an associated config file generated on first run in .sonic-pi/config/audio-settings.toml created in the user’s home folder.
I think that is as far as I can usefully offer at this time in this thread.