teletype1 / aes67-sender-enhanced Goto Github PK

Firstly thank you for this work, I'm hoping it will be just what I need. However when running on MacOS (M2 Ventura). I get the following output

sudo node aes67-sender-enhanced.js -a MACOS -d 7 -n "Mac Test" -v -m 192.168.0.255 --address 192.168.0.38 -c 2

`Selected CoreAudio as audio API.
Selected 192.168.0.38 as network interface
Channel input map from the sound card is [ 0, 1 ]
Selected device Existential Audio Inc.: BlackHole 2ch with 2 input channels

We are trying to put 2 channels on the network
This will require 1 AES67 flow(s).

Selected the following MultiCast Addresses: [ '192.168.0.255' ]
Selected the following names for the AES67 flows: [ 'Mac Test-Bank-1' ]
Opening audio stream.
Trying to sync to PTP leader.
Initializing PTP client
Synced to 16-98-9c-ff-fe-64-33-79:0 successfully
Starting SAP annoucements and audio stream.
Resycing PTP and RTP timestamp. Offset was 64840453.125ms.
libc++abi: terminating due to uncaught exception of type Napi::Error: The value of "value" is out of range. It must be >= 0 and <= 4294967295. Received -3179643600
Abort trap: 6`

Is the error likely to be to do with the M2 architecture?

First off, thanks a ton for the script. It absolutely works decently on Windows. However, there's some weird issue with the RTP timestamp resync. The problem I have is 'micro' stutter / dropouts that seem to coincide directly with the console message of the RTP Timestamp Resync. I know you're not on Windows so I doubt you'll be able to help here but perhaps you have some ideas?

Lets talk about WASAPI first. So it does work, I setup the AES67-Sender-Enhanced on my PC with an audio sink (tried a few of the VB Cable stuff including Banana but more on that later) and sure enough, my Ravenna linux machine picks up the stream, just like it picks up streams sent from other machines both Windows & Linux running Ravenna's driver. However, while it doesn't happen on EVERY RTP Resync, occasionally, I'll get this little pop (clearly audible while playing pink noise) that seems to coincide with a few of those messages. The offset is comfortably around 8-9ms although occasionally it drops down to 4ms in which case the little dropout is almost certain to happen, though it CAN happen when the value is firmly around 8-9ms.
Okay so, I changed the sync time to every 10s and every 100s, the dropouts are understandably way less frequent and lipsync is still working even after an hour long session.
Cool but shouldn't I be able to re-sync whenever? So I figure okay, lets try Process Hacker and make everything related to the specific node process 'real-time'. No difference.

I took apart the Dante Virtual Soundcard a bit to see if it has any different flags in terms of 'real time' on windows and no, it's ptp process has the realtime flag but I was able to give the same flag to the 'node' process. I figured, look at something that works and see if they're doing anything different right?

Next thing I tried was forcing node by default to try and set a higher priority.

console.log("setting priority for" + " the current process to -20"); try{ // Setting priority of current process os.setPriority(-20); }catch(err){ // Printing error message if any console.log(": error occurred"+err); }
It does correctly set the priority on windows but it doesn't make a difference.

Finally, the ASIO backend is weird, by changing the Audify binary build to something that worked (the 1.7.1 mentioned above) I'm able to get ASIO working correctly (I think 1.8 is broken for ASIO) but I get a massive difference in reported timestamp differences, going from 7-9ms to 400ms and most of the time is just a distorted mess, so there's really something weird with it. I tried adding the 'framesize' option to replace fpp (so replacing fpp with 0) to no effect. I can't really understand why the timestamp difference goes up so dramatically ?

RtAudioStreamFlags=0x8 Added that in too just in case to try and tell RTAudio to use the realtime flag?

I'm a little at a loss here.
I'd love some ideas. I guess it technically works, especially if you change the resync time to only do it like every 10 or 100s.
I'm 99% sure this is either an audify issue or a node + windows for 'real time' stuff issue but that's way outside of my knowledge.

Thanks again