Windows compatability

[zinkkkk]

Really like the look of this project, it's something i've been also been thinking about over the last year or two and very much thought the price of DVS was insulting for what it is.

I can see the entire project is currently made to work under linux but i'd be very interested in a windows version as i do live sound work and ideally had a goal of having music producers be able to play into large sound systems directly over dante from DAW software with the potential of streaming multi-channel/complex surround sound options without needing external audio interfaces. As it currently stands i don't know of any produces using linux as most commonly used software is Ableton/FLStudio/Bitwig so having a windows version of this software would be pretty desirable.

How deeply built into the linux ecosystem is this project and what would the viability of windows or even other OS support be in the long term? I've been learning rust programming recently but still a bit a newbie to bigger code projects but would consider trying to add windows support to some parts, any chance you could give a rough breakdown on what parts can or can't be changed?

I had a look at usrvclock-rs and that looks like it should be easy enough to convert to support windows, in fact i somewhat wonder why you used all the nix crates as the large majority of the functions used were also available as OS independent versions in rust std?

Statime looks like a bit of an established behemoth already and not as easy to add windows support, how essential is this for inferno? I haven't really seen many/any windows PTP implementations especially in rust so this may be a bit of a hurdle.

Ideally the main functionality i'm interested in is just the ability to play audio over network out of computers the recording parts are slightly less desirable for me at this point in time.

[teodly]

having music producers be able to play into large sound systems directly over dante from DAW software with the potential of streaming multi-channel/complex surround sound options without needing external audio interfaces.

Sounds awesome! I'm also a sound engineer and I'm fed up with D->A->D loops. However it would require music producers to install custom software, which in case of Windows kernel-level driver would be hard because Windows verifies digital signatures. Maybe building open source/open hardware equivalent to Dante AVIO-USB would work better? It would work with class-compliant driver. But not sure about multi-channel on Windows, whether WDM or ASIO4ALL would handle it. Hardware part can be minimal, Raspberry Pi or other SBC with Ethernet interface and USB-C configured as an audio device ("gadget" in Linux kernel terminology) should suffice.

How deeply built into the linux ecosystem is this project and what would the viability of windows or even other OS support be in the long term?

I've tried to make it as cross-platform as possible. In fact, older version of Inferno2pipe (from stable branch), before PTP integration was implemented, probably could work on Windows with none or minimal changes, but it's capture-only, so not your use case.

However, virtual soundcard functionality requires deep integration with the OS. This part would need to be written from scratch. In case of Linux we're lucky to have ALSA and PipeWire allowing creating virtual devices entirely in user-space. Not sure about ASIO and WDM on Windows and CoreAudio on OS X.

If we implement cross-platform audio I/O, the only remaining Linuxisms/Unixisms are clock synchronization and setting realtime thread priority (it is already implemented for non-Unix systems but not as fine-grained as on Unix).

We could implement Inferno as a VST3 plugin!

Audio plugin can't be the clock source for a DAW so that would require adaptive resampling. But it would enable the musician to install it easily and continue to use their audio interface for personal monitoring and using external devices (hardware synths etc). Their usual audio interface would be the clock source for DAW and Inferno VST plugin would resample for Dante network - still yielding better sound quality than a D->A->D loop. What's most important, VST3 standard is completely cross-platform! The only remaining challenge is clock synchronization.

usrvclock-rs [...] why you used all the nix crates as the large majority of the functions used were also available as OS independent versions in rust std?

Because it is implementation of a protocol which should work the same across different programming languages. I've designed it specifically for adding virtual clock support to Statime.

Statime [...] how essential is this for inferno?

If we implement another way of receiving Dante clock, not essential at all. Even if it is less precise, we can compensate it by setting larger minimum latency of our TX channels.

I can think of multicasting any channel from a Dante device. The audio data will be discarded by us but each audio packet contains a timestamp. But it may generate edge cases like single point of failure or someone unfamiliar with this workaround looking into Dante Controller and "oh, this channel is not needed here, let's disconnect it".

We can also implement very simple listen-only PTP receiver in Inferno directly, without using Linux-dependent hardware timestamping. Not sure whether special permissions are needed for listening on port < 1024 on Windows, though.

the main functionality i'm interested in is just the ability to play audio over network out of computers

So AES67 will work in your use case and Dante devices will be able to see the stream. Not sure about the pricing of Windows driver, they have loginwall at https://www.ravenna-network.com/downloads/

[zinkkkk]

However it would require music producers to install custom software, which in case of Windows kernel-level driver would be hard because Windows verifies digital signatures.

I personally think this is ok if streamlined, using windows-rs crate you can prepackage in all the driver information and it shouldn't be more than a few clicks.

We could implement Inferno as a VST3 plugin!

Could be an ok idea, might add more complication with multichannel use, a few vst's for atmos/surround sound have their own complex routing systems like fiedler atmos composer which is usually routed back out via main system outputs in daw settings.

If we implement another way of receiving Dante clock, not essential at all.

Does seem like getting a reliable accurate clock on modern multicore hardware can be pretty fiddly...

special permissions are needed for listening on port < 1024 on Windows

Hmmm i had not heard of this personally unclear if this is a thing

So AES67 will work in your use case and Dante devices will be able to see the stream

I tried it and it says i have no compatible network devices and refuses to do anything :(

[teodly]

Doesn't Windows allow loading unsigned drivers only when started with a special kernel command line option?

getting a reliable accurate clock on modern multicore hardware can be pretty fiddly

Depends on the precision required. DVS has a minimum of 4ms probably for that reason. But 1 millisecond is a lot of time for a modern CPU and gigabit Ethernet. On Linux I had usual latency from Inferno to Dante device below 1ms with occasional spikes above up to 8ms but the OS was completely untuned (no threadirqs or network traffic control) and switches and NIC had Green Ethernet enabled which is not recommended by Audinate. So with proper tuning could probably go down to 1ms.

[matiaspl]

Doesn't Windows allow loading unsigned drivers only when started with a special kernel command line option?

There's https://github.com/ossign - I once tried using https://github.com/OSSign/vadimgrn--usbip-win2/tree/ossign and it worked ok.