It’s unclear that all fields are, in fact, optionals, in the doc

which fields are you referring to above?

which fields are you referring to above?

I was referring to the fields in the subsection

types

:

They seem all nullable per their definition in go: https://github.com/livekit/protocol/blob/main/livekit/livekit_models.pb.go#L551

(More precisely they are absent of the response)

But this is not explicitely said in the doc, so it came as a surprise when I tested my parser (I code in Kotlin which differenciates Nullable and Non-nullable)

Those

Thanks in particular for the answer regarding sample rate. You mention that it matches incoming

Any idea how I can query for the exact value? It’s typically important in order to feed a SpeechToText engine to know this value.

perhaps we should ensure that.. by resampling if it doesn't match.. i'll talk to the team about this

Good evening David. On the same kind of topic, the number of channels is also not documented. Experimented today on chrome and it seems to be 2 (which I suppose, is also purely depending on the raw.)

perhaps we should ensure that.. by resampling if it doesn’t match.. i’ll talk to the team about this

Another way to tackle the problem is to make sure that the first message sent on the WebSocket is a json containing information about the audio, sample rate and channel count. According to the documentation you actually do sent json messages,

{ "muted": true }

for instance

(@dry-elephant-14928 in case you missed it)

re documentation: • The endpoint for egress requests (

/twirp/livekit.Egress

) is actually missing from the doc Misc: not really doc related thing, but currently whenever one make a POST request to a service that does not exist, livekit answers a counter-intuitive

OK

. For instance I initially made a mistake in the egress request endpoint, I mistakenly used

/twirp/livekit.EgressService

and I got very confused because I received

OK

responses.

thanks for the note on egress / twirp feedback too. we'll update the docs as well. It makes sense not to install the OK handler as a catch all. I'll file an issue for that

the issue is here in case you are interested in submitting a PR! 🙂

Passing the information of the number of channels seems mandatory, otherwise the PCMs are much harder (impossible I think) to exploit, since they are raw audio data without any headers. (Unless we know what number of channel did the clients use when creating the tracks). I see 2 solutions: • That livekit egress enforces the number of channels in the case of Websocket stream • That livekit egress sends (on the websocket) a json message that contains the number of channel and sample rate. I can make a PR if needed. What do you guys think?

I think it would be easiest to enforce both channels and sample rate for websocket. It’ll be 2 the majority of the time (if not always), and sample rate will always be 48k, so the increase in computation should be negligible

thanks