I have repurposed the Unity SDK for LiveKit into an new .Net Client SDK. This invokes requests via the LiveKit-Ffi and it works amazingly well ... except for one major issue.
We have our own internal framework which include our own AI Assistant solution. When a chat completion is transformed to audio and is applied to an audio source as a capture frame it works for a while but more so than not, it seems that the libwebrtc native audio_source function blocks forever and I am not sure why.
The reason I know this is occurring in or within this function is that a calling method does not raise the CaptureAudioFrame event is never raised ...
let res = source.capture_frame(&audio_frame).await;
let _ = server.send_event(proto::ffi_event::Message::CaptureAudioFrame(
proto::CaptureAudioFrameCallback {
async_id,
error: res.err().map(|e| e.to_string()),
},
));
In this method ...
pub async fn capture_frame(&self, frame: &AudioFrame<'_>) -> Result<(), RtcError> {
if self.sample_rate != frame.sample_rate || self.num_channels != frame.num_channels {
return Err(RtcError {
error_type: RtcErrorType::InvalidState,
message: "sample_rate and num_channels don't match".to_owned(),
});
}
let mut inner = self.inner.lock().await;
let mut samples = 0;
// split frames into 10ms chunks
loop {
let remaining_samples = frame.data.len() - samples;
if remaining_samples == 0 {
break;
}
if (inner.len != 0 && remaining_samples > 0) || remaining_samples < self.samples_10ms {
let missing_len = self.samples_10ms - inner.len;
let to_add = missing_len.min(remaining_samples);
let start = inner.len;
inner.buf[start..start + to_add]
.copy_from_slice(&frame.data[samples..samples + to_add]);
inner.len += to_add;
samples += to_add;
if inner.len == self.samples_10ms {
let data = inner.buf.clone().to_vec();
let _ = self.po_tx.send(data).await;
inner.len = 0;
}
continue;
}
if remaining_samples >= self.samples_10ms {
// TODO(theomonnom): avoid copying
let data = frame.data[samples..samples + self.samples_10ms].to_vec();
let _ = self.po_tx.send(data).await;
samples += self.samples_10ms;
}
}
Ok(())
}
}
... it calls into let _ = self.po_tx.send(data).await; and never comes back. I know that because previously I had println statements before and after.
This tends to work for a period of time and then it stops.
In my tests I applied the same audio each time and it stops processing at random places in the track.
Plus, up to the point where it blocks I can hear the audio playing back on a remote participant (JS Client) with no errors at the client.
Because the source is always the same and that I initially hear what I expect to hear, that the source is properly framed and if it wasn't that I'd expect not hear anything or that it would always fail at the exact same frame (which it does not).
What can cause this behavior?
Are there other things I can run to figure this out?
I am otherwise extremely pleased with how all else is working, so any assistance would be greatly appreciated!
I have repurposed the Unity SDK for LiveKit into an new .Net Client SDK. This invokes requests via the LiveKit-Ffi and it works amazingly well ... except for one major issue.
We have our own internal framework which include our own AI Assistant solution. When a chat completion is transformed to audio and is applied to an audio source as a capture frame it works for a while but more so than not, it seems that the libwebrtc native audio_source function blocks forever and I am not sure why.
The reason I know this is occurring in or within this function is that a calling method does not raise the CaptureAudioFrame event is never raised ...
In this method ...
... it calls into let _ = self.po_tx.send(data).await; and never comes back. I know that because previously I had println statements before and after.
This tends to work for a period of time and then it stops.
In my tests I applied the same audio each time and it stops processing at random places in the track.
Plus, up to the point where it blocks I can hear the audio playing back on a remote participant (JS Client) with no errors at the client.
Because the source is always the same and that I initially hear what I expect to hear, that the source is properly framed and if it wasn't that I'd expect not hear anything or that it would always fail at the exact same frame (which it does not).
What can cause this behavior?
Are there other things I can run to figure this out?
I am otherwise extremely pleased with how all else is working, so any assistance would be greatly appreciated!