search

sonosaurus / sonobus

Source code for SonoBus, a real-time network audio streaming collaboration tool.
https://sonobus.net
GNU General Public License v3.0
1.59k stars 118 forks source link

Sonobus Linux - Memory/Loop leak? #9

Open jcrystal opened 4 years ago

jcrystal commented 4 years ago

Debian stretch / JACK (dummy device)

Sometimes, after running successfully for several minutes, the Linux client will disconnect (leaving other devices to see it as "muted").

In this state, the SonoBus process spins up to 100%+ of CPU usage stops processing audio, and drags down the CPU to a grind. Only way out seems to be to manually SSH/kill that process. Possibly caused by a process XRun in Jack, but tough to determine. I can't identify what causes this to happen, but it seems to be anytime from 10 seconds to 5 minutes after starting a (successful) session.

Any way to help by extracting a log file from somewhere?

Thank you!

essej commented 4 years ago

There wouldn't be anything logged by default... have you tried it with a "real" audio interface and had this happen? When you look at 'top' output when it is in this state, is it just the CPU usage that has spiked, or is there a change in memory usage?

jcrystal commented 4 years ago

Yeah, I think a "real" audio interface is the next step. I'm attempting to get this rolling on an AWS instance, where I obviously don't have access to physical hardware. I wonder if there is a more stable virtual audio interface out there...

But to answer your question, while the CPU usage spikes, but the %MEM stays fairly constant. Really seems to just be CPU.

essej commented 4 years ago

Just a question, but why would you want to use this on an AWS instance? Currently it is using a pure peer-to-peer network setup, the only place you need to run it is at the endpoints where humans and audio interfaces are. In the future, there might be a server-based setup that would allow for a non-peer-to-peer-only option for mixing and/or to act as a relay... but the current version doesn't have that capability right now.

jcrystal commented 4 years ago

That situation you describe is exactly what I was building out; an AWS instance (not a peer) acting as a peer and routing to Jack (and returning). My guess is the lack of "real" hardware is what's causing it to take a dive, sadly.

I'll let you know if I come up with a solution on that front... :)