Output Stream recording

[clux]

Is it possible to record from the outputstream as it stands?

I have tried (on 'initialized'):

//user record
var u = connection.userByName('clux')
u.outputStream().pipe(fs.createWriteStream('./test.pcm'));

or

// global record
connection.outputStream().pipe(fs.createWriteStream('./test.pcm'));

and then running

// playback
fs.createReadStream('./test.pcm').pipe(connection.inputStream());

but nothing seems to be heard from my bot. I know the playback part should work since I can play your sin.pcm file. Is this not the intended usage?

(btw module has been fantastic so far - have done some really fun things with it :+1: )

[Rantanen]

I don't have problem with this. Make sure you're using up to date version though - there was a problem few weeks ago where the user-specific output streams weren't working. This was fixed two weeks ago in f689be7a6da226984fc0b0478a3df7d32cc9e1cb but the NPM version was a bit later I think.

[Prior99]

I can also confirm that the above code works, I am using a smiliar setup. Make sure this is not a problem related to permission in your server.

[clux]

That is weird. I am on the latest version. It is the recording stage to test.pcm that fails. The file only gets endless blocks of four zeroes written to it, and the 'voice' event on connection seems to never trigger.

I'll request a look at the server config later, it's not my server, but I mean, I can transmit and join using key and cert, what could be different for listening?

[Prior99]

Please try on 'ready'. On 'initialized' the connection was initialized but the library is still waiting for the initial status of the server.

[clux]

No, that's not doing it either. I'll try to do some debugging though. Added a console.log('got udttunnel data', data) to the beginning of MumbleConnection.prototype._onUDPTunnel and the buffer is definitely receiving my data properly.

[clux]

Right. The type in _onUDPTunnel is 0 which is not one of the valid ones in MumbleConnection.codecValues so the packet is ignored. Not sure how that is zero, given that the valid ones are 4 or 5, but that is at least the problem.

[clux]

Interesting solution:

//var type = ( data[0] & 0xe0 ) >> 5;
var type = 5;

This fixed it for me.

[Rantanen]

Ironically this is actually the "correct" solution - correct as far as the codecs go anyway. I've got no idea why the Celt codec is set to be number 5 on line 69:

MumbleConnection.codec = { Celt: 5, Opus: 4 }

The correct value for Celt would actually be 0...

[Rantanen]

Fixed in a2f1a158f19d8f203d1d756cd747da1a35f03d9f

Thanks for reporting it! I guess the rest of us were using Opus which works. The exact codec used is kind of hidden by the implementation which makes it nice to use but causes weird issues when the codecs differ. :)

[clux]

Hehe, yeah that makes sense. Thanks for the fast publish :)