Please can you elaborate more? Is it that a PC with Dante HW, i.e. running Dante drivers, can become a network renderer for another PC running Dante network drivers?
If so, the condition to use Dante HW is quite pricey, IMO.
IMO if a distance of several meters is enough, the advantages of Dante (low latency and gigabit network distance) are not of a benefit.
There are other network audio protocols which do not need any vendor-specific hardware. Roon protocol, VBAN for windows (e.g. with linux pipewire receiver), DLNA, etc... However almost all of them clock-slave the renderer which is suboptimal for bit-perfect audio... async UAC2 is the least compromise (for distances within USB reach).
Then there is USB over IP which works quite OK too. Viable e.g. for running USB devices on remote linux clients, to be accessed over ethernet from local Windows with generic or vendor USB drivers. Many choices.
OFFTOPIC ON
It might make sense to add this to the Camilla Readme. While it's not strictly specific to Camilla, it provides an important piece of context I was not aware of, and makes things much more attractive!
Can the DAC use one of USB ports of the RPi, or is the entire USB system of the RPi configured as an input from the PC?
OFFTOPIC OFF
I Phofman,
Well yes it can. But we are not talking 2 chanels with Dante, it's at max 64x64 ( in/out at 48khz/24bits) 32x32 at 96khz, 16x16 at 192khz ( iirc).
It's pricey yes but... it's stable and reliable ( it's the number one parameter of choice for pro audio) and endorsed by a large number of pro brands: compatibility and set and forget.
I already setup system with multiple computers ( one dedicated for DAW, other one for effects and virtual instruments) but it's very specific.
In my own case i want a dedicated computer for xover and my loudspeaker management unit have Dante input so it makes sense to discard soundcard to link from compiter with DAW to the one with xover to loudspeaker management unit.
But it's very specific to my use and looks more like a mastering studio than a typical home setup.
The real benefits of Dante is not about the protocol in itself, rather the fact you don't need soundcard anymore on computer which is a large saving regarding previous cost of such setup needing lots of in/out.
I truly understand people are curious about other ways to do so, but... i spent ( lost) enough time in my life debugging things for them to works ( in pro context but not only) and doesn't have the patience or will to do such things anymore.
There are standard for such 'set and forget' things, blameless quality wise and i think most amateurs should be aware about them before entering this kind of system.
Of course ymmv.
Well yes it can. But we are not talking 2 chanels with Dante, it's at max 64x64 ( in/out at 48khz/24bits) 32x32 at 96khz, 16x16 at 192khz ( iirc).
It's pricey yes but... it's stable and reliable ( it's the number one parameter of choice for pro audio) and endorsed by a large number of pro brands: compatibility and set and forget.
I already setup system with multiple computers ( one dedicated for DAW, other one for effects and virtual instruments) but it's very specific.
In my own case i want a dedicated computer for xover and my loudspeaker management unit have Dante input so it makes sense to discard soundcard to link from compiter with DAW to the one with xover to loudspeaker management unit.
But it's very specific to my use and looks more like a mastering studio than a typical home setup.
The real benefits of Dante is not about the protocol in itself, rather the fact you don't need soundcard anymore on computer which is a large saving regarding previous cost of such setup needing lots of in/out.
I truly understand people are curious about other ways to do so, but... i spent ( lost) enough time in my life debugging things for them to works ( in pro context but not only) and doesn't have the patience or will to do such things anymore.
There are standard for such 'set and forget' things, blameless quality wise and i think most amateurs should be aware about them before entering this kind of system.
Of course ymmv.
Last edited:
USB audio gadget has been used for a few years, quite a few projects available now . Descriptions e.g.
https://github.com/mdsimon2/RPi-CamillaDSP?tab=readme-ov-file#8-enable-usb-gadget-optional
https://www.audiosciencereview.com/...between-an-usb-source-ipad-and-usb-dac.25414/
https://www.audiosciencereview.com/...en-usb-source-and-usb-dac.53750/#post-1946831
https://www.diyaudio.com/community/threads/sample-rate-switcher-for-camilladsp.403054/
https://www.diyaudio.com/community/threads/linux-usb-audio-gadget-rpi4-otg.342070/
Many ARM SoCs have two controllers, one of which is OTG-capable.
All android SoCs have USB-OTG, so that the android USB link adb can work (as well as downloading files from a phone from a PC over USB).
https://github.com/mdsimon2/RPi-CamillaDSP?tab=readme-ov-file#8-enable-usb-gadget-optional
https://www.audiosciencereview.com/...between-an-usb-source-ipad-and-usb-dac.25414/
https://www.audiosciencereview.com/...en-usb-source-and-usb-dac.53750/#post-1946831
https://www.diyaudio.com/community/threads/sample-rate-switcher-for-camilladsp.403054/
https://www.diyaudio.com/community/threads/linux-usb-audio-gadget-rpi4-otg.342070/
The USB device or USB OTG feature requires HW support from the system. If a system has several USB controllers, some of which support OTG (device mode), you can use one controller for OTG and the other for USB host. RPi1-3 have only one on-chip USB controller (Synopsys IP Core DWC2), RPi4 has dwc2 IP plus PCI-e-USB3 controller VL805, RPi5 has dwc2 IP plus USB3 controller inside the new RP1 interface chip.
Many ARM SoCs have two controllers, one of which is OTG-capable.
All android SoCs have USB-OTG, so that the android USB link adb can work (as well as downloading files from a phone from a PC over USB).
I thought we were talking about home-use of a PC, also for audio.
Nevertheless, as of the channels: the UAC2 gadget supports 27x27, limited by 27bits of UAC2-specced channel-mask field https://github.com/torvalds/linux/blob/master/drivers/usb/gadget/function/f_uac2.c#L21-L22
Then the limit of 8000 microframes x 1024 bytes per second assigned to high-speed isochronous transfer applies.
That makes 27x27 for 96/24, 14x14 for 192/24, 7x7 for 384/24, 3x3 for 768/24, 2x2 for 1536/16.
If you use a better HW like newer dwc3 IP with longer FIFOs (e.g. in newer Intel Atom SoCs or newer ARM SoCs like newer Rockchips - e.g. Radxa Rock Pi 5), then the hardware allows using 3 packet transactions instead of just one in each microframe https://www.usbmadesimple.co.uk/ums_7.htm , tripling the available data rate = number of channels. This feature is not coded in the linux uac2 gadget driver yet, but windows and linux USB-host audio drivers support this mode, unlike e.g. iOS https://forum.rme-audio.de/viewtopic.php?id=34172 .
As of physical outputs - RPi5 has 8x8 32bit I2S up to 384kHz. The RK3308 in the tiny Rock Pi S (15USD) powered directly through its USB-device port handles 16x10 32bit I2S up to 384kHz, playback/capture on PC USB host through the USB gadget (dwc2). It has a separate USB2-host port too, for attaching a any multichannel USB DAC if needed.
All these chains can be master-clocked by the DAC, unlike Dante. But of course they cannot attain sub-ms latencies necessary for audio production or movie theatres (for which AES67/Dante were designed).
But yes, taking these ARM SBCs to full potential takes time, some knowledge, and effort. Nevertheless neither 27x27 nor 64x64 in Dante are of any need for a regular home user.
I disagree on two -edit: three!- things:
_Dante enable any clock on the network to be used as master ( it's pro gear...),
_The number of chanels can be of use for us diyers: multi way and multi chanel set up can make number of i/o grow very, very fast.
_ there is no difference between home pc use and pro use: both are digital stream of multichanel signals. And aren't we talking about 'dsp' *
That said i have nothing against other possible protocol ( except in the race to the fastest sampling rate which is funny when you know the max fs used to record is 192khz -and for maybe 1% of production ever released, 49% being 96khz the other 50% being 44,1/48khz...-), just be warned you could spend way too much time ( imo) geeking rather than listening to music.
It's a choice. And as i had to do this professionaly i've made mine for home use... i do not like to bring work at home 😉
*: dsp is equal for loudspeaker management unit to me, multi amp and filtering: multi chanel.
_Dante enable any clock on the network to be used as master ( it's pro gear...),
_The number of chanels can be of use for us diyers: multi way and multi chanel set up can make number of i/o grow very, very fast.
_ there is no difference between home pc use and pro use: both are digital stream of multichanel signals. And aren't we talking about 'dsp' *
That said i have nothing against other possible protocol ( except in the race to the fastest sampling rate which is funny when you know the max fs used to record is 192khz -and for maybe 1% of production ever released, 49% being 96khz the other 50% being 44,1/48khz...-), just be warned you could spend way too much time ( imo) geeking rather than listening to music.
It's a choice. And as i had to do this professionaly i've made mine for home use... i do not like to bring work at home 😉
*: dsp is equal for loudspeaker management unit to me, multi amp and filtering: multi chanel.
Last edited:
It uses PTP for stream synchronization - the RTP stream contains timestamps, each renderer has a PTP-adjusted software reference clock, and makes effort to pass the samples to the output buffer to fit the timestamps. But the samples need to be read from the output buffer using some clock, to be fed to the actual DAC, that's the same problem of every audio transport. The DAC clock can be either
A) somehow generated (by PLL), to fit the incoming rate into the buffer - similar to USB adaptive or SPDIF - PLL clock recovery, which requires dedicated hardware, or
B) low-jitter independent clock (crystal), but then two clocks are being merged, the buffer fill must be observed, and the incoming samples somehow modified to fit the local clock frequency. Either adaptively resampled (unlikely as it introduces latency), or simply dropped/duplicated/interpolated, or
C) the PTP global-synchronization clock can be derived from the DAC clock - again requires some substantial hardware support.
The method B with simple sample dropping/duplication is exactly what e.g. gstreamer can do, including the RTP timestamp alignment to a selected clock (either software-based globally-PTP-adjusted if needed, or the local soundcard clock).
The method C would work only for one renderer, all the other renders would have to use either method A or B (i.e. synchronizing to an external clock). My 2 cents it's not used in Dante as it's quite complicated and provides benefit for only one of the typically many renderers in the setup.
@CharlieLaub has done a lot of work in gstreamer on network streams synchronization, he may chime in with his experience.
Only method C for the master renderer is comparable to master clock of multichannel async UAC2. But of course in UAC2 the channels need to be consumed locally, physically close, unlike in the case of network renderers.
Actually there is no race - it's just a byte stream, and up to the player and receiver whether the receiver views the byte chunks passed in the usb frames as many channels with fewer samples, or fewer channels with more samples (higher samplerate). The limits are put on the overall byte bandwidth.
My tests were done not for audio, but for a 2ch USB measurement device with 768kHz samplerate and integrated advanced DSP. No need for these samplerates for standard audio, I absolutely agree.
@phofman,
From my understanding of Audinate's protocol the A,B and C are all possible scenario.
They use a very advanced clocking schem with a 'list' of possible master clocks: if one fails or have a drop the next one in the list takes the lead.
I once tried to disconnect the rj45 on my Dolby Lake to see how it'll behave and... no noise and 'transparent' behavior when i plugged it in afterwhile: back inline without noise or pop and without action from my part.
Impressive for one of the oldest Dante enabled device and took away concerns if clock fail ( no 0dbfs signal sent to drivers. Rassuring.).
Being pro gear there is choice of external input from wordclock possible when clock master (in complex setup we often have a dedicated wordclock generator with multiple output to put in synch every digital gear used). And there is most always PLL in pro digital gear anyway (adc/dac, desk, effects,...).
With a Virtual Soundcard, the clock can come from computer but it is delayed to 1ms. In fact even if sub ms latency is possible it is almost always in the 1ms range anyway when configuration is a bit complex ( The Control Center gives 'optimal' settings for the configuration which is very nice for non expert in computer network as i am).
In my simple setup i can daisy chain if needed between xover dedicated computer/loudspeaker management unit.
I find you optimistic about how FS is understood. Few peoples have your technical understanding and sadly higher numbers in FS/bit depth are often used as marketing BS.
From my understanding of Audinate's protocol the A,B and C are all possible scenario.
They use a very advanced clocking schem with a 'list' of possible master clocks: if one fails or have a drop the next one in the list takes the lead.
I once tried to disconnect the rj45 on my Dolby Lake to see how it'll behave and... no noise and 'transparent' behavior when i plugged it in afterwhile: back inline without noise or pop and without action from my part.
Impressive for one of the oldest Dante enabled device and took away concerns if clock fail ( no 0dbfs signal sent to drivers. Rassuring.).
Being pro gear there is choice of external input from wordclock possible when clock master (in complex setup we often have a dedicated wordclock generator with multiple output to put in synch every digital gear used). And there is most always PLL in pro digital gear anyway (adc/dac, desk, effects,...).
With a Virtual Soundcard, the clock can come from computer but it is delayed to 1ms. In fact even if sub ms latency is possible it is almost always in the 1ms range anyway when configuration is a bit complex ( The Control Center gives 'optimal' settings for the configuration which is very nice for non expert in computer network as i am).
In my simple setup i can daisy chain if needed between xover dedicated computer/loudspeaker management unit.
I find you optimistic about how FS is understood. Few peoples have your technical understanding and sadly higher numbers in FS/bit depth are often used as marketing BS.
Well, PTP is not like master clocks used in studios. Master clocks distribute a real clock signal to which all the DACs/ADCs are synced to.
PTP is just a network protocol which fine-tunes software clocks to report the same time (down to sub-microseconds). If no PTP adjustment arrives, the clocks continue "running" but will start deviating from each other after a while, untill the next PTP adjustment message re-aligns the clock to the rest.
Before splitting to individual renderers, ale channels are being passed together. A multichannel device receives all the channels together and passes the corresponding samples for each channel to each codec at the same time, keeping synchronicity of the channels.
But when channels are split and passed across network to individual renderers, they will arrive at different times. To maintain channels synchronicity (to properly play time-sensitive multichannel content, like Atmos objects), they all must be passed to the local audio converters at the same time. That's why all the network RTP streams include timestamps with the RTP data blocks, all renderers have local software clocks, precisely synchronized to the PTP master time, and the playback software makes sure these sample blocks are passed to the audio device when the local clock reaches the block timestamp. If the local clocks loose PTP synchronization, all that happens is the affected channels will eventually skew against the other ones, damaging the spatial audio image.
But the codecs still need some master clock for the actual conversion, a hardware signal. Since the Dante renderers seem to be based on FPGAs (to allow the low latencies, which are not possible to get with an embedded linux renderer), maybe the FPGA developers programmed some digital oscillators which are fine-tuned by the PTP signal - i.e. the method A. I do not know if any implementation details are known.
PTP is just a network protocol which fine-tunes software clocks to report the same time (down to sub-microseconds). If no PTP adjustment arrives, the clocks continue "running" but will start deviating from each other after a while, untill the next PTP adjustment message re-aligns the clock to the rest.
Before splitting to individual renderers, ale channels are being passed together. A multichannel device receives all the channels together and passes the corresponding samples for each channel to each codec at the same time, keeping synchronicity of the channels.
But when channels are split and passed across network to individual renderers, they will arrive at different times. To maintain channels synchronicity (to properly play time-sensitive multichannel content, like Atmos objects), they all must be passed to the local audio converters at the same time. That's why all the network RTP streams include timestamps with the RTP data blocks, all renderers have local software clocks, precisely synchronized to the PTP master time, and the playback software makes sure these sample blocks are passed to the audio device when the local clock reaches the block timestamp. If the local clocks loose PTP synchronization, all that happens is the affected channels will eventually skew against the other ones, damaging the spatial audio image.
But the codecs still need some master clock for the actual conversion, a hardware signal. Since the Dante renderers seem to be based on FPGAs (to allow the low latencies, which are not possible to get with an embedded linux renderer), maybe the FPGA developers programmed some digital oscillators which are fine-tuned by the PTP signal - i.e. the method A. I do not know if any implementation details are known.
Last edited:
I have been using Gstreamer based DSP for several years now. Audio and clock data are distributed over a normal WiFi LAN system. In the setup that I left back in the USA before moving, the clock source was a stratum 1 (GPS based) NTP server on my LAN. This clock was distributed to each machine over the LAN, using either a wired or wireless connection. This keeps the computer clock well synchronized to real time. Importantly this is the exact TIME and not just the correct RATE like a crystal clock source will give you. This is important when trying to synchronize multiple playback endpoints, because the data may reach each client at a slightly different time. RATE based playback does not correct any initial offset. This can only success when a TIME based playback timing and synchronization mechanism is used. Gstreamer incorporates such a mechanism and it is based on the NTP algorithm. Gstreamer adjusts the playback buffer pointer to correct for the offset, and examines the DAC clock on the local machine to ascertain its rate and then adjusts accordingly. I have had relatively good success streaming audio to separate clients, each in one of the left or right speakers and running independently except for the mechanisms used by the Gstreamer pipeline and the NTP OS clock synchronization. By this I mean the stereo image is stable. Gstreamer has been improving its synchronization algorithm to make it more resistant to glitches in the timing info it gets via RTP and NTP and I need to go back and take a closer look. In the past I could keep machines synchronized to within about 20-50 microseconds of each other, and this was good enough to preserve the stereo image in a fullrange monitor. Of course this could also work with a subwoofer since a increasingly more delay can be tolerated as frequency decreases.
Apart from WiSA based systems that achieve about 5usec synchronization, I don't know of any other wireless (not wired LAN based like Dante) audio system that has better synchronization control than Gstreamer. Unfortunately you have to write pipelines and this can be complicated with Gstreamer. I wrote my own application that translates human readable input files into Gstreamer pipelines and have been using that for several years as a whole-home audio solution.
Apart from WiSA based systems that achieve about 5usec synchronization, I don't know of any other wireless (not wired LAN based like Dante) audio system that has better synchronization control than Gstreamer. Unfortunately you have to write pipelines and this can be complicated with Gstreamer. I wrote my own application that translates human readable input files into Gstreamer pipelines and have been using that for several years as a whole-home audio solution.
Thanks. Yes, I'd seen Wubuntu; it seems in some ways to be a continuation of LinuxFX unfortunately though, which wasn't the kind of OS I would like to trust. Maybe things are more professional and less shady now; I haven't followed it closely enough to know (though I'd still be cautious). But no worries, as it isn't really what I'm looking for here.
If I wanted to run windows apps on linux then I'd personally prefer to use a mainstream distro such as Debian or Fedora with (e.g.) wine, and choose a normal Linux desktop.
I haven't completely dismissed wine etc as an option and might come back to compare it for compatibility, once I've settled on what my required/preferred apps and workflow are going to be, and having tested how they should run in their native environment. Particularly if that includes Roon, since the important server part will even run on Linux natively. But initially, I suspect that I'd find best compatibility just using a (true) windows VM - unless/until I hit any VM-type issues or get too annoyed with Microsoft's way.
If I wanted to run windows apps on linux then I'd personally prefer to use a mainstream distro such as Debian or Fedora with (e.g.) wine, and choose a normal Linux desktop.
I haven't completely dismissed wine etc as an option and might come back to compare it for compatibility, once I've settled on what my required/preferred apps and workflow are going to be, and having tested how they should run in their native environment. Particularly if that includes Roon, since the important server part will even run on Linux natively. But initially, I suspect that I'd find best compatibility just using a (true) windows VM - unless/until I hit any VM-type issues or get too annoyed with Microsoft's way.
Thanks Allen, yes that is my hope too, which is encouraging.
I've done the USB-passthrough before without any obvious problem (admittedly only to a linux guest), so am reasonably optimistic there. Though things have also surprised me before, which I hadn't anticipated (like virtual clocks being less reliable than hardware ones).
No doubt clever people could make almost anything work, eventually, but whilst my IT skills exist they are only quite modest compared to many on here. So sometimes it can be easier for me to just try a different approach than wrestle forever with complications; time will tell!
I've done the USB-passthrough before without any obvious problem (admittedly only to a linux guest), so am reasonably optimistic there. Though things have also surprised me before, which I hadn't anticipated (like virtual clocks being less reliable than hardware ones).
No doubt clever people could make almost anything work, eventually, but whilst my IT skills exist they are only quite modest compared to many on here. So sometimes it can be easier for me to just try a different approach than wrestle forever with complications; time will tell!
Or pick one of the other main tech channels.
I only see Intel being blamed everywhere (incl this thread).
Point is that they are most certainly and obviously not the only one to blamed here. In fact only a small part.
The other obvious part are the motherboard manufactures.
Once again, don't jump into definitive conclusions, before you have all the information.
It most certainly doesn't have anything to do with older generation systems.
Remind me, where did I do that? I have not blamed anyone, just stated that the issues are real.
Remind me, where did I claim that?
I don't get the point of these Linux distros that try to be windows. In my view that are just weird Linux, and since they are weird it gets hard to find useful help when there is some problem (which seems likely to happen since they are weird). Long term support is also questionable.
For a pleasant Linux experience, just get a well known, well supported distribution.
That means the same thing, let's not get pedantic over words.
Also not needed, nobody here is attacking anyone either.
I kinda agree with this.
I used to setup computer systems for small organizations.
Since they often had no or an extremely limited budget, with users that basically just only browse a couple of websites etc, Linux was ideal here.
I did notice that some people get all flustered when things look off.
So after a while I was just making the distro look more like windows and I got a lot less complaints.
Keep in mind that not everyone is a tech/science/engineering/programming nerd like us. 😉
The only thing these people know, is to click on the "thing" in that corner that looks like "something" that brings them to the page they want.
Even if you change the color of that same "things", they are completely lost.
For people who know a little more, all basic Linux distors look great these days.
In fact, I REALLY miss the snappy taskbar/menu experience from Linux.
It's one of the things that still works mediocre for Windows.
Well I've had a day off at last and have been able to do some tinkering with a win11 VM, giving it 4cores and 16Gb of ram. The USB passthrough worked okay, so I'm sure this method would function as expected, if playing to a hardware gadget for DSP etc.
Though I find the GUI a little sluggish for everyday use as a VM. I invested in decent hardware for my PC a while ago and seem to have become conditioned into expecting things to be snappy (like the linux VMs are). There are some other niggles as well, like tearing in video which I'd need to address. I also set up my audio collection on a filesystem that Windows can't use without a third party application. Which I could solve of course, but my prejudices are getting in the way; I'm reluctant to allow a fun/hobby windows system direct access to my main PC's drives so I'd probably want a NAS or something.
But on reflection this isn't even necessary now that I've become keen on roon and on having a Pi5 as a DSP/renderer. The main core server (the only mildly heavy bit) of roon will run natively on linux, and there are lots of ways in which it'll play easily to my Pi. All I need are quite mininal resources (on almost anything except, sadly, native linux) to act just as a controller/GUI. So I'll probably follow mbrennwa's model; a tablet sounds perfect for armchair listening.
Though I find the GUI a little sluggish for everyday use as a VM. I invested in decent hardware for my PC a while ago and seem to have become conditioned into expecting things to be snappy (like the linux VMs are). There are some other niggles as well, like tearing in video which I'd need to address. I also set up my audio collection on a filesystem that Windows can't use without a third party application. Which I could solve of course, but my prejudices are getting in the way; I'm reluctant to allow a fun/hobby windows system direct access to my main PC's drives so I'd probably want a NAS or something.
But on reflection this isn't even necessary now that I've become keen on roon and on having a Pi5 as a DSP/renderer. The main core server (the only mildly heavy bit) of roon will run natively on linux, and there are lots of ways in which it'll play easily to my Pi. All I need are quite mininal resources (on almost anything except, sadly, native linux) to act just as a controller/GUI. So I'll probably follow mbrennwa's model; a tablet sounds perfect for armchair listening.