Fully configure frame processors when they are used directly on an audio stream

[1egoman]

Updates the python sdk so that FrameProcessor-based noise cancellation providers can be used directly on AudioStream, without having to go through the agent's RoomIO to be able to initialize itself with credentials.

For example, with this change, something like the below becomes possible:

stream = rtc.AudioStream.from_track(                                                                                                                   
    track=track,
    sample_rate=SAMPLE_RATE,                                             
    num_channels=CHANNELS,
    noise_cancellation=ai_coustics.audio_enhancement(model=ai_coustics.EnhancerModel.QUAIL_VF_L)  ,
) 

The way this works - Tracks now keep track of which room they are part of (holding a weakref value). When the room a track is in changes, it computes new frame processor options and sends these to any AudioStreams which are associated with the track.

The noise_cancellation_leave_open parameter allows the agents sdk to call this from_track method with a frame processor which remains open across the whole session, and won't be auto-closed when the track is closed.

This goes along with livekit/agents#5867, which removes the relevant event handling logic in the agents sdk. I will follow up with a node version of this once the python one is in a good state.

Todo

• Add some tests for this newly added behavior

[theomonnom]

Suggested change

noise_cancellation_leave_open: bool = False,

Can we move that inside NoiseCancellationOptions?

[1egoman]

Unfortunately, no - this is important to the FrameProcessor[AudioFrame] side of that noise_cancellation union. Open to putting it somewhere else but it needs to be settable in the FrameProcessor path.

[lukasIO]

hmm, not sure if it's a good idea, but could it be a field on the FrameProcessor interface instead?

Then we could add it to NoiseCancellationOptions and new FrameProcessors would be able to set it on the processor itself

[1egoman]

It's not a setting that a frame processor would always want to have set or not have set, so I'm not sure that would really make sense either.

For context, the reason this is here is so the agents sdk can reuse a single FrameProcessor across multiple underlying tracks. Previously, this wasn't a problem in the way this used to work, because the agents sdk had the responsibility of closing the FrameProcessor, so it could easily do it at room disconnection time. But in order to support the ability to use FrameProcessors directly on an AudioStream, calling close needs to be pushed down deeper than the agents sdk layer. This flag allows the caller to explictly tell AudioStream that they will manage cleaning up the FrameProcessor so that both use cases can continue to work.

[xianshijing-lk]

I think this flag is not really configuring the noise suppression behavior, but how AudioStream deals with its own noise suppression, maybe the naming of noise_cancellation_leave_open is a bit confusing ?

how about close_noise_cancellation_on_stream_close or manage_noise_cancellation_processor ?

[lukasIO]

It's not a setting that a frame processor would always want to have set or not have set

it could stay undefined by default? 🤷
I understand however that it feels a bit weird for it to live on the processor if the processor itself doesn't really use the field.

We shortly discussed also the option to introduce a restart method on the processor. I think this could still be a viable alternative?

[1egoman]

We shortly discussed also the option to introduce a restart method on the processor. I think this could still be a viable alternative?

It could, but the con there is it's a breaking api change to FrameProcessor.

Just generally, I want to understand what folks' concerns are in more detail. Is it just the noise_cancellation_ prefix naming like shijing suggested (I think out of the two suggestions, I like manage_noise_cancellation_processor better)? Or is there something deeper behavior wise that is concerning?

FWIW, two fairly similar patterns I found:

• LiveKitAPI conditionally controls aiohttp.ClientSession cleanup here based on whether the user passes a custom session or uses an inbuilt session.
• The LocalAudioTrack has a userProvidedTrack parameter which is used to control whether the track is cleaned up or not here.

[1egoman]

Talked to @lukasIO in a 1:1 and he confirmed his concern was mostly with the naming, not with the broad approach, which is helpful.

A few other name ideas, in addition to shijing's suggestions (close_noise_cancellation_on_stream_close / manage_noise_cancellation_processor) - some of these would involve flipping the flag:

• shared_noise_cancellation
• noise_cancellation_externally_managed
• auto_close_noise_cancellation
• owns_noise_cancellation

Out of the above, I think I like auto_close_noise_cancellation the best:

# Usage within agents sdk:
AudioStream.from_track(
    # ...
    noise_cancellation=frame_processor,
    auto_close_noise_cancellation=False,
)

I'm going to update the pull request to use it for now in 8d5e656.

---

Another possible idea: maybe something like the below could be a different way to package the same data which could better contain it. In a world like this, noise_cancellation would be of type Union[NoiseCancellationOptions, FrameProcessorOptions, FrameProcessor]:

AudioStream.from_track(
    # ...
    noise_cancellation=FrameProcessorOptions(frame_processor=self, leave_open=True)
)

Do any of these ideas look better than the current state?

[1egoman]

@theomonnom @xianshijing-lk Lukas gave a a general 👍 to the rename to auto_close_noise_cancellation addressing his concern. Do either of you have further concerns beyond what this rename could accomplish with this approach?

If not / I don't hear anything in the next few days I think I am good to merge this.

[lukasIO]

question(non-blocking): do you foresee any scenario where on_credentials_cleared and on_stream_info_cleared would get called independently from one another?

I don't have a good suggestion for a unified method name, just raising this in case you can think of one that would be obvious and allow for less methods to be implemented for each processor

[1egoman]

Yes, one example (at least in theory) where they could be called at different times: a frame processor is detached from a track, kept around connected to the room for a period of time, then reattached to another track in that same room.

[1egoman]

Did a little bit of testing locally along with livekit/agents#5867 and this looks to work in all the easy to test happy path cases. That along with the test coverage of the harder to test non happy path cases I think makes me fairly confident in this now!

Also, in case anyone is curious - I also have tested the current main of the agents repo (451bae4f7) with this loaded and everything works, there just are in some cases callbacks like _on_credentials_updated / etc are being called twice (once by agents code, once by the code in this PR) instead of once.