Accurate audio track counting

[hiroshihorie]

Not sure what can cause trackDidStop to be called unbalanced with trackDidStart but better guard this.
Accurate counting of audio tracks instead of counting publish / unpublish.

[bcherry]

is it still possible for a track that's already stopped to call stopCapture? in the case everything is already at 0 this won't matter, but if if the values are greater than 0 it could cause miscounting.

a more durable approach may be to store sets of the active track ids, instead of counts, and it will prevent miscounts in the case of extra starts or stops for a single track.

(But this looks like it will fix the issue as reported, where we reached -1 before anything got published, so this should be good to merge)

[hiroshihorie]

start/stopCapture is guarded by a trackState lock so it should be ok:

client-sdk-swift/Sources/LiveKit/Track/Track.swift

Lines 225 to 251 in 8f3da0a

	// Intended for child class to override
	func startCapture() async throws {}
	// Intended for child class to override
	func stopCapture() async throws {}
	@objc
	public final func start() async throws {
	guard _state.trackState != .started else {
	log("Already started", .warning)
	return
	}
	try await startCapture()
	if self is RemoteTrack { try await enable() }
	_state.mutate { $0.trackState = .started }
	}
	@objc
	public final func stop() async throws {
	guard _state.trackState != .stopped else {
	log("Already stopped", .warning)
	return
	}
	try await stopCapture()
	if self is RemoteTrack { try await disable() }
	_state.mutate { $0.trackState = .stopped }
	}

But I agree there with more work I can make it more solid.

[bcherry]

@hiroshihorie yeah that's perfect - this should probably work as it is then

[hiroshihorie]

Ok when I look again it's still not race proof stop() could get executed concurrently