Fix Tapo 2-way audio

[xdissent]

The tapo stream just needed another \r\n to accept the requests. Working great for me via the UI and HomeKit (after reload).

[koush]

This obviously looks like a bug at first glance, but now I'm curious how it ever worked in the first place?

[koush]

@xdissent i did notice that the audio payloads are new line terminated here but not in go2rtc where I translated the code from. Not sure that’s correct.

ostensibly new line shouldn’t be necessary in either case because the content length is used for payloads, and multi part boundary is used for message delimiter.

[xdissent]

Oh, interesting - I would have sworn both the setup request and the audio payloads had the extra crlf in go2rtc, but looking again it is only on the setup request. Doesn't seem to hurt though. I'll try without it and see if it still works.

I agree it shouldn't be necessary, but clearly there's a bug in their http implementation in one place or the other.

[xdissent]

Yep, works fine without the crlf on the audio packets. I guess their main request handler or json content-type parser requires it though. Doesn't work without it on that request.

[koush]

chatgpt could be lying, will check the spec proper later though

[koush]

ahh yep

Note that the encapsulation boundary must occur at the beginning of a line, i.e., following a CRLF, and that that initial CRLF is considered to be part of the encapsulation boundary rather than part of the preceding part. The boundary must be followed immediately either by another CRLF and the header fields for the next part, or by two CRLFs, in which case there are no header fields for the next part (and it is therefore assumed to be of Content-Type text/plain).