Positional Audio about node-mumble

[Rantanen]

Not in the provided API. The input stream is also a bit tricky abstraction for it. Mumble doesn't handle positional audio as some hypothetical multichannel audio; instead the audio is still encoded as mono/stereo stream. The positional information is then added as extra metadata on the audio packets.

The input stream eats PCM audio, splits this in audio frames and encodes it. These encoded frames are then combined into a Mumble audio packet based on packet size settings. That audio packet has optional field for the positional data.

The issue here is that the input stream doesn't expose details/API on packet boundaries so there is no way to tell when the packet changes and positional data could be sent. Associating positional data with each sample would be quite expensive.

On the MumbleConnection-level the packets are formed in the sendEncodedFrame function:

node-mumble/lib/MumbleConnection.js

Lines 386 to 396 in 3387e12

	// UDP tunnel prefix.
	var prefix = new Buffer( 6 );
	prefix.writeUInt16BE( Messages.idByName.UDPTunnel, 0 );
	prefix.writeUInt32BE( voiceHeader.length + framesLength, 2 );
	this.socket.write( prefix );
	// Write the voice header
	this.socket.write( voiceHeader );
	// Write the frames.
	for( var f in frames ) { this.socket.write( frames[ f ] ); }

The protocol docs indicate the positional data should follow the frames: https://mumble-protocol.readthedocs.io/en/latest/voice_data.html#encoded-audio-data-packet

Writing three float coordinates after the frames on line 396 would take care of that (and ensuring the length info on line 390 takes that added data into account).

A possible API for this would have current position as a state on the stream the user would keep up to date. Then when the stream queues the frames on the connection by invoking connection,sendVoiceFrame it would also pass the position data as a parameter. sendVoiceFrame would then pass the parameter to sendEncodedFrame. This would avoid the stream from having to expose the packet boundaries or from the user having to pass the location data with every sample.

Alternative to exposing the location as a field on the stream object would be to support some in-stream metadata that could be written to the stream through normal write APIs and the stream would update its internal state based on those - writing the location data would then proceed as above. I don't see much point with this though.

Now unfortunately this project is not only not maintained anymore, but I also lost the use of my other hand few months ago so I'm not going to be able to do any maintenance currently. The above instructions should enable you to make the necessary changes if you need them.