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

Question: Expected custom client flow for dummy source #252

Closed paulreimer closed 3 months ago

paulreimer commented 3 months ago

I am creating custom AOO clients (send-only) for interop with SonoBus 1.x clients, and one thing I haven't figured out is how I should be setting up my clients' source(s).

Specifically, I see from the SonoBus code that there is a dummy source with id=0. If my client also its own source with id=0, everything sort of works! But I am unable to then mute my peer in SonoBus (uninvite is not sent to my /aoo/src/0). After this, things get really wonky.

How is it supposed to work? I see that SonoBus clients eventually do some sort of handshake that ends up with them starting on id=0, and then doing an invite to id=1 followed by uninvite to the id=0s. (My guess is that other clients should also use two sources, one with id=0 and another with a non-zero id. Is that right?)

paulreimer commented 3 months ago

I should add that my clients currently don't have any sinks, as I am intending these clients to only ever be sending data.

Spacechild1 commented 3 months ago

AOO author here. SonoBus still uses a rather old AOO version which made it difficult to negotiate sink IDs among peers. That's why you have the dummy source, handshake and invitation.

I'm not too familiar with the exact logic and thus cannot really help with your question, but I wanted to point out that recent AOO (test) versions do not have this problem. Specifically, AOO v0.2-test3 has introduced the concept of group IDs and user IDs. In an online jamming app like SonoBus, each client would create a sink for every peer, using the peer's user ID as the sink ID.

For example:

Client A creates two sinks with IDs 2 and 3 so that B and C can send to A using their own user IDs.

@essej is planning to update SonoBus to the final AOO 2.0 version once it has been released.

paulreimer commented 3 months ago

@Spacechild1 noted! I actually first made my clients with the new API (not understanding that it was a breaking change), and I really enjoyed using it. Especially now that I've made new clients with the older API, I can really see both the improvements in functionality but also in developer experience. Looking forward to using it to interop with a future Sonobus version!

essej commented 3 months ago

Yeah, the sink/source number handshake is kind of a pain right now, and I've been a bit of out it for a while... it will definitely be better when I make the switch over to the latest AOO with SB 2. It'll take some time for me to give you an answer about what you should do to interoperate...

Spacechild1 commented 3 months ago

I can really see both the improvements in functionality but also in developer experience.

@paulreimer Glad to hear :)

paulreimer commented 3 months ago

@essej I think I figured this out! (at least my custom client seems to be working with 2 concurrent Sonobus instances)

In my client I have:

And I can expect an initial invite from Sonobus to the dummy source. And at that point I take that invite (for my source id=0) and pretend it was received by the audio source (id=1); just configure that source with the provided sink id that the dummy source was sent.

Shortly afterwards, an uninvite message is sent from Sonobus to my dummy source, which I just ignore, because I never did anything with the original dummy invite -- other than inspect it to find the desired sink id.

Seems to work OK!