This message was deleted.
# cloud
s
This message was deleted.
e
i’ve got a similar use case and already looked into this - you’ll want to use selective subscriptions https://docs.livekit.io/realtime/client/receive/#selective-subscription
f
this is about how to send only audio tracks, right?
e
track kind is irrelevant, it’s about which tracks to subscribe to
in your case how to tell a listener what track to listen to
f
on MUX implementation we have participants who can talk and listen, and listeners who can just listen with some stream latency. I check if user is just a listener I render just a mux player with playbackId, I try to understand how LiveKit handle this.
e
someone might correct me, but as far as i can tell, livekit is webRTC only, so the mux usage doesn’t map exactly here
what you’ll do is have 6 people join the room with audio input tracks, and everyone else join with no inputs
everyone subscribes to the 6
f
so you want to say that it’s impossible to broadcast room participants conversation to the big audience ?
e
no, im saying it works slightly differently
you can do live streaming
The vast majority of livestreams today use a protocol called HLS. HLS takes advantage of traditional CDNs which are optimized for quickly delivering a sequence of static files. The problem is end-to-end latency; anywhere from 5 to 30 seconds of it between broadcaster and subscriber. LiveKit is a new type of WebRTC CDN
f
I see. thank you. also I see that I can streaming to mux https://docs.livekit.io/egress-ingress/egress/overview/#streaming-to-mux
e
yeah, you can stream to mux too
👍 1
d
Hey @freezing-country-21607, you can definitely achieve the use case you are looking for while keeping everyone in the Room. LiveKit Cloud scales up to 100k participants per room. For your use case, you can do the following: • everyone joins as a participant • speakers would be assigned
canPublish
permissions in their access tokens. listeners would not receive that permission at start • by default everyone will be subscribed to the speakers' tracks If speakers don't change, that's all you need to do 🙂 It should just work If you are building something where the listeners can be invited to the stage, you could do the following • call UpdateParticipant API, and giving them
canPublish
permissions • clients will receive a ParticipantPermissionsChanged event, and on that cue they could publish their own tracks • when the participant should leave the stage, call
UpdateParticipant
again and remove
canPublish
permission Of course, you can export the stream to Mux for HLS distribution too!
f
sounds good, just two questions is there a difference in price between approach you described (when all clients are participants) and what I am saying (when 10 participants and all others are just listeners and listen audiostream via player with mux url) 2. about your approach: do I steel need to export stream to mux? Thank you very much for your previous answer
d
If you are serving all participants via WebRTC, there is no need to export the stream. In terms of pricing, it's difficult to compare as I'm not familiar with the alternatives.. But you can price out LiveKit workload with the calculator here: https://livekit.io/pricing/calculator
👍 1
f
@dry-elephant-14928 can you help me a bit with pricing calculator, I am a bit confuse, which values should I paste here if I will go with approach you suggested (when everyone joins as a participant), for example I have show with duration 2h, up to 8 active speakers and up to 50k listeners
d
so you'd want to fill in 8 for
users publishing audio
, and 50000 for
users receiving audio
f
for one show which has 1h duration with 8 speakers and 50k listeners will cost:
the same duration show and the same 8 speakers but just broadcasting audio will cost nothing:
d
if there are no listeners.. you are correct that it would fit within our free tier
f
so as I understand option when we have 8 speakers and streaming to mux https://docs.livekit.io/egress-ingress/egress/overview/#streaming-to-mux a lot cheaper than approach when we have 8 active speakers and 50k listeners, right?
d
I don't believe so.. what is the cost to serve 1hour of audio to 50k listeners on Mux?
f
in mux we have 10 active participants and start broadcast our stream to 50k listeners. thats why I am asking liveKit team about which approach is the gold middle between stable work and pricing
d
something is off with the pricing that you screenshotted..
f
maybe I misunderstand something?
d
just running some quick math here, it should be around ~$200.. about 1TB of data
f
if you have 5 minutes of free time we can have a quick meet call..
d
that's for a 2 hour session with 1 simultaneous speaker and 50k listeners.. note that not all speakers will be speaking at the same time.
f
this is the price of your setup
but when I am choosing 8 simultaneous speaker - price is ~600$
d
that's the issue with the pricing calculator.. 8 speakers are likely not all speaking at the same time.. but there's no way to specify that into the calculator. Since this is an estimate, I would suggest using 2 simultaneous speakers to get an approximate cost.
f
got it, but one more qs(sorry for bothering you all day) if we have in the room 8 participants with token({canPublish: true}), and 1 or 2 participants can speak in the same time. which pricing calculation will be in this case?
d
no problem. I would suggest running a example session and seeing how much bandwidth is used.. and extrapolate from there. These are ballpark numbers and will not be precise.
f
@dry-elephant-14928 hello, I was moved to another task and now I am on “livekit migrate from mux” task again, I checked pricing page and see a lot of changes there, can you help me a bit to understand which option fits for me I see tab “Livestreaming” and “Audio only”. And I think “Audio only it’s what I needб, isn’t it?
d
these aren't different options.. they are just examples for the exact same pricing model.
👍 1
f
@dry-elephant-14928 hello, while my developing process I faced with issue on safari(desktop/mobile)
mobile safari when the participant(H - host) is already connected to the room and after that some participant(A) connected to the room everything is fine, participant(A) plays hosts audio tracks if the host allows to speak other participant(B) - participant(A) do not plays participant(B) audio tracks but plays participant(H - host) audio tracks only if participant(A) refreshes the page and connect to the room - all is good I read about
startAudio
method on the
room
object and about
handleAudioPlaybackStatusChanged
event. But I don not receive this event on safari
on safari desktop - silence in all cases
btw
room.canPlayAudio
is
true
d
that sounds like you are not attaching participant B's tracks for playback.
f
when I set this setting, all start working well
d
@polite-kilobyte-67570, is this related to the Safari restrictions you were mentioning?
p
hm. not sure. @freezing-country-21607 can you reproduce this on meet.livekit.io?
f
@polite-kilobyte-67570 yes, one participant on safari mobile second on safari desktop on safari dektop square of the participant one blinking (is-speaking state changed) but there is no sound
p
and you also don't see a start-audio button next to the chat? 👀
f
yeah, no buttons
p
ah you're saying you don't hear sound on the desktop? or is there no sound on the mobile ?
f
participant from safari desktop do not hear anything
p
I was able to reproduce this once. The audio element is in a
paused
state then, and we should be showing a
Start Audio
button. Somehow this fails. Can you try downgrading livekit-client to
1.15.0
and see if you see the start audio button then? We changed the way we handle this in 1.15.1 and while in our tests everything looked fine, we might still be hitting some Safari edge case from time to time
f
@polite-kilobyte-67570 will try to downgrade and check this again I will update you with results Thank you very much for your time
🙏 1
@polite-kilobyte-67570 version 1.15.0 Working like a charm! starts audio automatically without call startAudio() method
p
thanks for checking!
👍 1
PR for the fixing this. If it’s possible for you to run your reproduction of the issue with the changes in this branch, that would be great to verify the fix also from your side.
f
@polite-kilobyte-67570 sure, will check again using this branch do I need also check on livekit demo meet?
p
thanks! as long as you’re handling the RoomEvent.AudioPlaybackStatus changed event properly, then no need to verify additionally with the meet demo
f
@polite-kilobyte-67570 sorry for late response, I ran reproduction of the issue with the changes from your branch, all is good. issue is gone
🙌 1