hi, i have a little question about ActiveSpeakerObserver when producer is not on the same router
when producers are not on the same router and ActiveSpeakerObserver is getting created by router.createActiveSpeakerObserver, do i need to pipe the related producers to one router so i can create activeSpeakerObserver on that router and add producers to the created activeSpeakerObserver instance?
Well, I’m not sure what is the use case of having producers from different routers in the same ActiveSpeakerObserver.
If there is a valid use case, we might be able to move it up the stack under worker, just like WebRtcServer.
hi again,
@nazar-pc my problem is i have a room, producers are on different routers and i want to use a activeSpeakerObserver to get the room active speaker ( producer in case ).
i don’t know what @ibc meant about letting pipeToRouter work in the same worker ( not related to my problem i think ) but if i get it right did he meant we can’t use pipeToRouter to pipe a producer between two routers which is created on the same worker?
anyway im creating one router per worker.
We have a change pending in mediasoup that may potentially disallow piping producers within the same worker. If you have routers in different workers it will work fine.
Why do you have multiple routers for the same room though? Is it due to room size?
why should disallow it!?
yes my routers are on different workers
Why do you have multiple routers for the same room though? Is it due to room size?
@nazar-pc not sure if its a good decision but this is how i did it :
there is two projects one handling producers and room logic(orchestration) one handling consumers
orchestrator is keeping and executing room logic ( creating send transport, managing producers, pipe consumers, peers, etc ) and consumer is only handling [ creating receive transport, consumers, pipe producers ].
orchestrator creates one worker per cpu core and one router per worker and connects it to consumer routers ( which is one per worker and one worker per cpu core there too ). relation is one to n ( one router to n router )
orchestrator only handles creation of producers and a room producers are on the same instance but on different routers/workers and producers are piped to alive consumer instances in the network/cluster so i can load balance consumers.
and now i need to implement active speaker!
can you tel me what is the best thing to do to achieve it?
i was thinking of creating a router and piping all the producers from every router to it so i have them all on the same router then i can create an active speaker observer for a room! 
That seems an overkill, why 2 separate projects, you can do it in one, create a room which creates worker and so on and let it handle producers and consumers you don’t need piping at this point. Now you need another worker for same room, you can create it and use it and pipe necessary producers to the new router and consume from there.
Now if your machine is full then a new machine should pop up and worker will be created on that machine and the rest of the process is same.
for some distribution and decomposition purpose. its actually two modules in same project
Still it is not reasonable, not necessary to do all this separation.
You can do separation like have one class deal with producers and have another deal with consumers, but producers and consumers of one room should be using same worker and if needed create another worker and use piping, the point is they should work together as a one unit not like as a separate apps, it will just create complexity nothing else.
The use case is completely valid, I have many producing servers; the routers mean nothing to me because I blow past the worker limits; so I can have a router handling few rooms but a limit of how many users per…
It’s best to handle audio observation at a client level. If a client hides a user or mutes them, their levels should be considered muted (server won’t know this). If you have clients spread across several media servers it’s absolutely zero over-head on your network/resources.
Overall you can’t go wrong doing this client side.
If you must insist on having the media-servers do it, you’d need to output the stats of each producer and signal them to a server where you calculate the results to send back to each user in the room (every 2 seconds or less type stuff). Highly discouraged…
@BronzedBroth
thank you
yes right
i already have it on client side but i need it in server side too for some recording purposes.
as mediasoup has added ActiveSpeakerObserver i want to use it but i was wonder whats the best way to do to get one for a room in my implementation.
Okay perfect,
Depends on what you’re trying to record, there’s lots of things we can do! I can certainly say the resource usage is not worth it having server compute things it doesn’t need to (if possible). Could save yourself on calculations.
im recording audio and video of peers in a room
merging all audio files to get one file ( for audio ) at the end
now i want to add video but i want to switch video based on current active speaker.
you said
you’d need to output the stats of each producer and signal them to a server where you calculate the results
what do you think about creating a router for this purpose and piping producers to it so i can use this router to create ActiveSpeakerObserver on it? because ActiveSpeakerObserver have a addProducer(id: string) which takes producer id and it works if the producer is on the same router with observer.
is it a bad idea?
Not necessary, very inefficient!
You could build a room bot, it joins with a headless browser and records the entire session.
so your saying its more efficient to use a headless browser!? how is it more efficient than that?
Simply because all your producers would be available for consumption by any viewer request without extra steps just a single consume (in large scenarios it may open another pipe for viewers that’s room size dependent though).
You also can benefit from the use of multithreading, something that’ll help in large rooms.
You could try a few things and see what you like, I’d be concerned with the additional piping when it’s not necessary being a waste on resources.
We’d like to have a global map of all entities in a worker and piped producers have the same ID as originals, making such map more awkward than it could have been.
thank you @BronzedBroth for your time and explanation.
i will give a try to puppeteer in recording part.
No problem, if you can sort something more efficient out do share. Your specific setup is a bit advanced so take it slow and plan carefully! 