Try to by pass audio encoder if pre-encoded set

[kuba--]

This draft PR is an experiment to by-pass audio encoder if pre_encoded audio option was set.

[davidliu]

Do these checks prevent using pre-encoded data? Since it's on the receive end, seems like this should be unaffected? In particular, dropping the 10ms rule seems like a pretty big deal since it's assumed fairly throughout the system that play data would be given in 10ms chunks.

[kuba--]

I'll double check the samples one (it should be fine). For sure if you link rust-sdk examples with debug version of webrtc it will crash in this place, so I commented this block for testing purpose.

#
# Fatal error in: ../../../../_source/macos_arm64/webrtc/src/audio/audio_transport_impl.cc, line 213
# last system error: 0
# Check failed: sizeof(int16_t) * nChannels == nBytesPerSample (4 vs. 2)

[kuba--]

I also worried about OggReader where we have:

const OGG_PAGE_DURATION: Duration = Duration::from_millis(20);

[davidzhao]

I think we can change that to be 10. since webrtc's internal clock for audio is 10ms

[davidliu]

Is endianess an issue here?

[kuba--]

I assumed we will have decoder (and this is how I tested), so the most important was to be consistent with decoder.
Otherwise, this is good question. I think I'll convert it to Little Endian (as more popular architecture). Another alternative is to rely on real architecture (by using C like union implementation) or expose this information as part of API, but It may look too complicated, because who knows what output SDP device will decode it.

[kuba--]

I uncommented most of checks in AudioTransportImpl::NeedMorePlayData. I left commented the only one, which crashes our example:

// RTC_DCHECK_EQ(sizeof(int16_t) * nChannels, nBytesPerSample);

I've also refined encoding. Made it more platform generic (instead of hardcoded big endian).

[davidliu]

Endian I think would work as platform generic? Checked the network code and I think it expects platform endianess anyways.

For the nChannels vs. nBytesPerSample check, is this something we can address?

[kuba--]

For the nChannels vs. nBytesPerSample check, is this something we can address?

I'm not 100% sure if it has any impact on workflow (because nBytesPerSample is only used in the assert check), but I found the root cause. It's because in rust-sdks AudioDevice wrapper we have hardcoded values.

I've sent PR with fix: livekit/rust-sdks#344