Should DanteDevice.add_subscription use channel friendly names?

[jamesremuscat]

DanteDevice.add_subscription passes tx_channel.name to its command_add_subscription method. Dante naming weirdness means that channel "names" are always '01', '02' etc.

This works, and audio is routed appropriately, but it confuses Dante Controller into not knowing where that subscription is coming from: it gives green checkmarks against the tx device, but doesn't know which column to put them in.

By way of example: here ATEM-Input is subscribed to channels 1 and 2 from SQ6-Broadcast. The subscriptions were made with netaudio.

These channels have friendly names of Broadcast L and Broadcast R respectively. You can see that Dante Controller thinks the subscriptions are actually to channels called 01 and 02 - which, surprisingly, works and audio gets passed appropriately.

Should add_subscription be using these friendly names if present? (Come to think of it, should these friendly names be used in place of names everywhere they're used?)

[krosseyed]

@jamesremuscat Do you know where to look within the code to make this change? I just started using netaudio and I was curious if anyone took a swing at fixing this one.

I noticed that this only affects TX channels, and not RX channels. Maybe there is a difference in how those are handled or how the names are passed between the TX and RX side of things?

I am working on getting this integrated with Bitfocus Companion, and this seems to be one of the last steps in my config process. I can use a separate 'truth table' and rename the TX channels to fix this issue for the time being, but it would be very nice to be able to see my configuration reflect the friendly names of the TX channels.

[jamesremuscat]

@krosseyed I'm afraid I've not looked at this project in more than two years! DanteDevice.add_subscription is the only breadcrumb I left myself.

[krosseyed]

Edits to the following files:

I added actual_tx_name as a variable to check if friendly_name is not None

• /netaudio/console/commands/subscription/_add.py

        if rx_channel and rx_device and tx_channel and tx_channel:
            actual_tx_name = tx_channel.friendly_name if tx_channel.friendly_name else tx_channel.name
            self.line(
                f"{rx_channel.name}@{rx_device.name} <- {actual_tx_name}@{tx_device.name}"
            )
            await rx_device.add_subscription(rx_channel, tx_channel, tx_device)

• /netaudio/lib/python3.10/site-packages/netaudio/dante/device.py

    async def add_subscription(self, rx_channel, tx_channel, tx_device):
        actual_tx_name = tx_channel.friendly_name if tx_channel.friendly_name else tx_channel.name
        response = await self.dante_command(
            *self.command_add_subscription(
                rx_channel.number, actual_tx_name, tx_device.name
            )
        )

        return response

After doing these changes, Dante Controller seemed to give me the green check mark. Here is the command that I am running to confirm this works:

wsl /home/ubuntu/.local/bin/netaudio subscription add 
    --tx-device-name=BirdDog-NDI-Bridge 
    --rx-device-name=BirdDog-NDI-Bridge 
    --tx-channel-name=TestTX2 
    --rx-channel-name=TestRX2

I am testing this on Windows 11 with Ubuntu 24.04 on WSL. I have dedicated a NIC to the Ubuntu VM using Hyper-V tools and it is able to detect all Dante devices (and NDI devices in my case) on my network.

[chris-ritsen]

Keep in mind that this is a very experimental project. I have just done packet captures and modifications to devices I personally own. I didn't try every device or feature; some aren't even known to me. I've seen undocumented features on hardware I have that has never been mentioned even.

All I remember about this is that I did a full network config export from the official client and it had these "friendly channel name" fields that I didn't need for anything I was doing at the time. I'm at a loss for what to call most of the things named here because I'm not using any official API documentation to describe it, so I just go with what I see. Even the name of the project is just the prefix to the mDNS services I found using it. I don't remember the extent that I tested how to change or use these friendly channel names when listing or changing subscriptions. I probably just made them visible on list and changed things with fixed channel names (i.e., indexes) while testing. Also subscriptions are set/stored on the rx devices; that's the device you target when adding/removing a subscription. But I don't remember which arguments it accepts (friendly vs fixed) or how.

Also, thanks for testing on WSL; it's been a while since I've tried there.

[krosseyed]

@chris-ritsen, Thanks for doing a lot of the heavy lifting on reversing the Dante API. You have done a LOT of work on getting this up and running and I appreciate it!

The tx_channel.friendly_name variable seems to be used for labeling each channel. The way it is setup in the netaudio code is that the friendly_name var is passed in from the channel of the Dante device itself. My code edit checks to see if that variable has been passed from the Dante device or if it is using the default channel name/number by checking if friendly_name is None.

I am not sure if you can try this out, but using the code edits I have made should allow you to label each TX channel to something more human readable. This was already the case for the RX channels, as I have been able to change crosspoints on RX devices using their friendly_name.

I currently have Bitfocus Companion working with this 100%. Its a bit slow on changing crosspoints, but the speed of this code is not critical to the implementation I have built out. I have to say that this has given me a way to control Dante from a web interface, and its very useful!