search

AaronJowitt / Rivendell

RIvendell Automation Issue/Req Tracking
0 stars 0 forks source link

UDP echo packets from CAE server & client -OR- queries re virtual CAE Server communication. #13

Open AaronJowitt opened 8 years ago

AaronJowitt commented 8 years ago

-------- Forwarded Message -------- Subject: Re: RD CAE - UDP communication Date: Mon, 24 Aug 2015 23:01:10 +1000 From: Aaron Jowitt Aaron.Jowitt@Rebelfm.com.au Reply-To: Aaron.Jowitt@RebelMedia.com.au To: Frederick Gleason fredg@paravelsystems.com

Hi Fred,

I've made some progress - RDAirPlay is showing audio metering.

RDLibrary is not though (or track position), but I can play/stop files in Edit Markers. And RDAirPlay is also not advancing track position (but Sound Panel is) . I'm still not sure why that is. I guess it has omething to do with the MP or MS message I'm sending, but it looks fine to me. I'm still looking....

I was able to get RDAirplay (Sound Panel) Metering working by using Wireshark to view the UDP packets being sent from an genuine RD CAE server to a client. This showed that each 'message' was self contained in one packet. I had been grouping the TCP commands in one packet and sd that had been working ok, I was doing teh same with teh UDP messages. So I separated each UDP message into dedicated packets. The other thing Wireshark revealed was there was no "!" symbol to mark the end of each message. This is in conflict with what is detailed in the CAE.odt document. None the less, just removing the "!' from the end of all the UDP packets I was sending is what got the metering working on RDAirplay.

EDIT 10Sep:

I can either keep going down this path of having a VB client act as a virtual CAE server, or as you earlier suggested (which is a better solution),echo UDP packets from a real 'CAE server to client' session. This could be as simple as either the CAE Client or Server Sending a UDP packet to the entire subnet as the CAE (i.e if RD CAE client is on 192.168.1.80, it sends the UDP packet to 192.168.1.255) on a fixed port number. The UDP packet needs to contain;

These need to be real time (i.e sent received in same routine as the TCP packets)

ElvishArtisan commented 8 years ago

| what is the undocumented 'CS" command?

Clock Select. It is used to set which input of an ASI card should be used to derive the internal sample clock. It is used only with AES3 cards.

ElvishArtisan commented 8 years ago

| In RDLIbrary, Record window I get an AES ALARM. Is that an issue?

It indicates that your have an input port configured for AES3 input, but the respective port on the ASI card is not seeing AES3 framing. For an ASI6x85 card, leave all of the port types set to 'Analog'.

ElvishArtisan commented 8 years ago

| I can have have either RDAirPlay or RDLibrary talking to our app, but not both at once. I assume | therefore each RD module has its own TCP session with a CAE server. How is that 2nd (and | subsequent) session connected? What port numbers?

Just make a connection to the same port number [5005].

ElvishArtisan commented 8 years ago

| How do I best make /var/snd on our RDServ1 available (read access is fine) to the windows machine | so the Digigram cards API can access the audio files.

This is going to be difficult. The normal method for interfacing to Windows systems is Samba, but that system uses SMB file semantics, which will interfere with the locking protocol used by Rivendell. Your best bet will be to find an NFS utility for Windows that will permit native NFS mounts to be used.

ElvishArtisan commented 8 years ago

| I can either keep going down this path of having a VB client act as a virtual CAE server, or as you | earlier suggested (which is a better solution),echo UDP packets from a real 'CAE server to client' | session.

I don't think I'm understanding your architecture here.

AaronJowitt commented 8 years ago

| This is going to be difficult. ... Your best bet will be to find an NFS utility for Windows that will permit native NFS mounts to be used.

Ok I'll look into this further after we the CAE communication sorted. I'm wondering if a easier or better alternative (getting around the RD locking protocol ?) would be to put a 4TB drive in a Windows pc, configure that drive to constantly 'sync' from /var/snd, then our windows playout machines read from the windows drive...

AaronJowitt commented 8 years ago

| I don't think I'm understanding your architecture here.

A Windows pc equipped with one or more Digigram cards, running a VB6 app and the Digigram API, the aim is to have the Digigram cards real time either;

The sole purpose is access the superior time scaling ability of the Digigram card range. While I've done some work on the 2nd method and got it partially working (with some workarounds), more I think about it, by the time we sort the questions and issues with this approach, the 1st method may be simpler & faster for both of us!

To effect the first method, all I'd need from RD is a fast 'real time' copy/echo of all TCP client/server CAE packets, to be sent by UDP to a customisable address & port. i.e. RD WS1 to send/echo its TCP client/server packets to say 192.168.1.41:7000 (UDP), and RD WS2 to send/echo its TCP client/server packets to say 192.168.1.42:7000 (UDP), etc.

RDWS1 & RDWS2 would playout locally via their ASI cards (but not route the audio to air)

We then code our VB6 app on those target pc's to listen for the UDP packets from the RD Clients, extract the client/server bi-directional CAE documented 'commands and acknowledgements' and interpret/translate them to the Digigram API. The Digigram audio outputs would be routed to air.

How does that sound?

ElvishArtisan commented 8 years ago

| To effect the first method, all I'd need from RD is a fast 'real time' copy/echo of all TCP client/server | CAE packets, to be sent by UDP to a customisable address & port. i.e. RD WS1 to send/echo its TCP | client/server packets to say 192.168.1.41:7000 (UDP), and RD WS2 to send/echo its TCP | client/server packets to say 192.168.1.42:7000 (UDP), etc.

This is not going to work. The CAE protocol is TCP-based. As such, it relies on TCP's 'connection-oriented' nature to disambiguate messages from multiple client processes. UDP is stateless and connection-less; thus, you'd have no way to determine which messages were associated with which client processes.

AaronJowitt commented 8 years ago

ok, I really haven't thought this through a lot, but what if a simple header was added to start of each UDP packet to identify it? Like the audio card/port the message was related to (given we will dedicate a fixed card/port to a fixed log machine) and its server/client direction. Or alternatively just maybe a unique handle that identifies each individual TCP connection?

Our app doesn't need to be smart enough to understand the authentication and most of the different CAE TCP commands. It can 'assume' some things and ignore others, and only needs to be able to identify the basics to strip out enough info to mirror playback of RDAirPlay logs.

So a header with something like [direction card port stream]

[TX 1 7 5] PP 10 1452! [RX 1 7 5] PP +! [TX 1 7 5] PY 10 240878 100870 1! [RX 1 7 5] PY +!

or a unique handle representing the TCP connection like [direction TCPHandle]

[TX 5000] PP 10 1452! [RX 5000] PP +! [TX 5000] PY 10 240878 100870 1! [RX 5000] PY +!

Would something like that work and be simple to do?

ElvishArtisan commented 8 years ago

| ok, I really haven't thought this through a lot, but what if a simple header was added to start of each | UDP packet to identify it? Like the audio card/port the message was related to (given we will dedicate | a fixed card/port to a fixed log machine) and its server/client direction. Or alternatively just maybe a | unique handle that identifies each individual TCP connection?

This would be tantamount to redesigning the entire protocol (and much of the implementation as well). It means that the connection state would have to be tracked internally throughout all of the codepaths within caed(8). And, I strongly suspect that this would merely be the tip of the iceburg. Running two processes in parallel like this is liable to be bedeviled by a host of race conditions (due to the fact that the two different implementations will inevitably execute at different speeds and thus fall out of step with each other). Given that the goal is merely a subjective improvement to perceived audio fidelity, I think that the cost/benefit ratios here are wildly out of line.

AaronJowitt commented 8 years ago

Preventing significant degradation of audio quality is I believe a worthy goal. The majority (but admittedly not all) of people we have exposed to reference A-B music tracks can easily hear a marked difference - even on $20 desktop speakers. It's not that Digigram cards are great at time scaling, it's that ASI are (subjectively) currently much worse in comparison.

| This would be tantamount to redesigning the entire protocol...

Understood thanks. If only Digigram had linux drivers/api... So the first approach is only viable option, where at our end we create a windows CAE server app (compatible with RD clients) that can control the Digigram cards, and maybe play audio from a local windows HD that is synced with /var/snd.

| Just make a connection to the same port number [5005].

VB6 (I think) won't do that. It allows a single TCP connection to a given target IP address/port. An attempt to make a second separate connection to same IP:port results in an 'address already in use' error.

I may have to look further into all this at our end ,when its clearer that RD is closer to being able to deploy. Thanks Fred. Any interim thoughts most welcome!