A streamer is a device sold to have more connectivity that should be already embeded in a modern DAC nowadays cause we are not in 2008 with Synology or Logitech fine stuffs anymore.
You could add an external clock to add a box : sexier ; one more specialised to run CDs as CD players (Rega is in touch, lol); another box for enhancing the power supply and add battery (Naim is comming) and of course two more, one for the DAC and one for the analog output stage made from microphonic direct heated triodes. Don't forget all the expensive cable in between.... and the NAS with a Raid10 with a virtual network to make a SAN for the security and for a geocluster at the opposit of your Earth location at Aunt Lucy house by satelite !
In short the first purpose of a streamer is to stream out the monney of your wallet !
You could add an external clock to add a box : sexier ; one more specialised to run CDs as CD players (Rega is in touch, lol); another box for enhancing the power supply and add battery (Naim is comming) and of course two more, one for the DAC and one for the analog output stage made from microphonic direct heated triodes. Don't forget all the expensive cable in between.... and the NAS with a Raid10 with a virtual network to make a SAN for the security and for a geocluster at the opposit of your Earth location at Aunt Lucy house by satelite !
In short the first purpose of a streamer is to stream out the monney of your wallet !
Last edited:
(1) The problem with USB audio is that Android and Chromebooks don't do bit perfect audio. Those two devices are ubiquitous so it's very important to make sure they support it... A work around is to connect to another device that supports bit perfect audio over USB. In essence we're looking for a bridge. The issue is not solved by a reclocker because the problem is in the bit rate encoding at the sender.
Since Android and Chromebooks do not reclock the data bit rates for transmission over IP networks then the hunt is for a bridge that will receive IP and convert that to USB while preserving the data (payload) source bit rate. That makes it "bitperfect".
Of course the true solution will be to "Fix" Android and Chromebooks.... so they don't need USB-OTG and the like anymore... still for wireless, you can not use Bluetooth.... for the time being.
I've solved this issue by gettings some WiiM Ultras that take the IP network audio data and convert it to USB. The DAC always sees the native bit rate. Of course, there's likely more going on under the sheets, like Tidal Connect, but I don't care, It has solved our problem with using Tidal and Spotify.
(2) For "IP based" audio, you would select TCP. Very simple. You could choose UDP but then you'd have to write the code to make the transfer reliable. Why do that when you already have that in a connection based TCP?
The WiiM Ultra connects via both Ethernet and WiFi. Both of those datalinks support IP.
If you think about it, IP connections are far more robust. The client doesn't have to support all of the network layers. An IP DAC would not have to support HTTP, RTP... all it would have to do is support TCP and UDP.
The device drivers and networking stacks are already in there.... Windows, Apple, Android, Chromebook, Linux, etc, etc... no need for WASAPI or ASIO. Those are designed to provide near real time IO in a Windows world. They are not needed when networking. You just transmit the data to the end point and there it is taken off the stack and moved to a different DA stack... simple.
Absolutely no need for the sender and receivers to know anything about he real time nature of the output device clocks.... NOTHING. They are independent.
The only important thing is that the bandwidth of the network data has to be greater than the bandwidth of the data going to the DAC. Otherwise you get "buffering" interruption.
BTW, IP networking has been around for 50 years now, it is extremely robust. I think the only reason it's not yet abundant in consumer audio is the slow movement of the consumer Audio World. Remember they were stuck in "synchronous USB 1 " while the rest of the world had migrated a decade earlier to "asynchronous USB 2"... this was because they are CHEAP and the USB1 chips were cheap....
Since Android and Chromebooks do not reclock the data bit rates for transmission over IP networks then the hunt is for a bridge that will receive IP and convert that to USB while preserving the data (payload) source bit rate. That makes it "bitperfect".
Of course the true solution will be to "Fix" Android and Chromebooks.... so they don't need USB-OTG and the like anymore... still for wireless, you can not use Bluetooth.... for the time being.
I've solved this issue by gettings some WiiM Ultras that take the IP network audio data and convert it to USB. The DAC always sees the native bit rate. Of course, there's likely more going on under the sheets, like Tidal Connect, but I don't care, It has solved our problem with using Tidal and Spotify.
(2) For "IP based" audio, you would select TCP. Very simple. You could choose UDP but then you'd have to write the code to make the transfer reliable. Why do that when you already have that in a connection based TCP?
The WiiM Ultra connects via both Ethernet and WiFi. Both of those datalinks support IP.
If you think about it, IP connections are far more robust. The client doesn't have to support all of the network layers. An IP DAC would not have to support HTTP, RTP... all it would have to do is support TCP and UDP.
The device drivers and networking stacks are already in there.... Windows, Apple, Android, Chromebook, Linux, etc, etc... no need for WASAPI or ASIO. Those are designed to provide near real time IO in a Windows world. They are not needed when networking. You just transmit the data to the end point and there it is taken off the stack and moved to a different DA stack... simple.
Absolutely no need for the sender and receivers to know anything about he real time nature of the output device clocks.... NOTHING. They are independent.
The only important thing is that the bandwidth of the network data has to be greater than the bandwidth of the data going to the DAC. Otherwise you get "buffering" interruption.
BTW, IP networking has been around for 50 years now, it is extremely robust. I think the only reason it's not yet abundant in consumer audio is the slow movement of the consumer Audio World. Remember they were stuck in "synchronous USB 1 " while the rest of the world had migrated a decade earlier to "asynchronous USB 2"... this was because they are CHEAP and the USB1 chips were cheap....
Last edited:
These consumer-oriented devices use audio mixers which typically run at a single samplerate (otherwise they could not mix multiple streams). It's possible your app output gets resampled if the stream samplerate the app sends via Android audio API to the mixer does not correspond to its samplerate.
BTW Android does allow apps to set a bitperfect behaviour of the mixer stream - https://developer.android.com/media/platform/improve-audio-playback
It's up to the apps to use it. If your app does not use it - well either use a different one, or code your own. Android does not prevent you from that.
I have never heard of Android having a built-in facility to transfer audio over network as a basic service. There are apps which are programmed to do so in "user space" without using Android (probably VLC app and others).
TCP is suitable for "downloading audio", not streaming with fixed latency. Especially over wifi where lost packets are common, causing TCP to resend them with progressively longer delay. That's why RTP almost always runs over UDP. But this is not important as there are no IP-audio sound device drivers in operating systems anyway.
?? IP is just a transmission layer. You need the actual protocol (like USB packets vs. UAC2 protocol).
?? How do you output audio over network from a standard sound application which uses standard audio API (like wasapi or ASIO on windows)? The way would be to create an audio driver which on the internal side exposes WASAPI/ASIO and on the other side communicates over network. E.g. like https://www.telosalliance.com/consoles-audio-mixing/accessories/axia-livewire-aes67-ip-audio-driver - see what they say:
?? Have you actually ever created an audio application? The output device clock is what determines the pace at which the audio output API consumes the samples of your app (including the audio mixer, if used in the chain). If the incoming stream has its own pace and your application has no control over it (i.e. the incoming stream is a clock master), you simply have to resolve the clock difference somehow. Yes, the two clocks are independent, and it's your job to handle it. That's why good audio protocols include rate feedback to allow making the incoming stream slaved to your output clock.
When talking about network - HTTP is simple - you simply send a request for a block of audio data, receive with some delay (eventually) and play. Since you do not know when the data actually arrives (wifi here?), you must keep a pretty long buffer of pre-fetched data, so that your running audio device is not starved. That results in huge latency - no way for real-time streaming.
RTP (of course UDP-based) just keeps sending data, paced by the transmitter. There is no feedback control incorporated in the protocol. It's up to you to merge the incoming and outgoing clocks. Gstreamer does it, AES67 renderers do it, any RTP receiver must do it, somehow. Of course not bit-perfectly - by principle.
There are custom protocols which handle the feedback - The old Squeezebox devices used a clever SlimProto protocol https://wiki.lyrion.org/index.php/SlimProto_TCP_protocol.html , Pulseaudio network protocol does it similarly.
But e.g. the new VBAN (accepted e.g. by Pipewire) is plain master https://vb-audio.com/Voicemeeter/VBANProtocol_Specifications.pdf:
Yes, but again - there are no standard network audio drivers available in main operating systems. While you can buy and use e.g. AES67/Dante drivers, they have to be paid for by someone and installed by the user. Definitely not something available for standard DACs - unlike USB audio, where e.g. many Alsa developers have programmed the linux snd-usb-audio driver used in your WiiM https://github.com/torvalds/linux/commits/master/sound/usb .
Last edited:
I've been doing Internetworking since 1989.... was there before when it was DARPAnet. Before that I spent a decade in a lab doing metrology stuff.
Written the TCP/UCP/IP stacks from scratch from the RFCs and Internetworking with TCP/IP by Douglas Comer. Created our own company private HTML in '93, ported it over TCP by creating an HTTP like socket (we didn't publish this, it was strictly done to control our routers over the Internet, bypassing SNMP).
We were working on comm and multimedia (voice, video, data) over Internet all over the 90s, when the infrastructure was being laid out and the money was pouring from Hollywood, cable companies and the telcos.
Done Satellite, cable, fiber, ATM, etc... for multimedia distribution.
Then I've programmed Android/Linux/RTOS at the kernel level, done device drivers, done wireless phone SoC with multimedia... done BSPs.
I stand for what my comments were, those are based on doing real time firmware on such things.
IMHO, you are confusing specific user implementations with the actual underlaying protocols. You are discussing some specific solutions while I'm describing the generalities that constrain ALL solutions.
We have a saying
"There are many ways to skin a cat"
Written the TCP/UCP/IP stacks from scratch from the RFCs and Internetworking with TCP/IP by Douglas Comer. Created our own company private HTML in '93, ported it over TCP by creating an HTTP like socket (we didn't publish this, it was strictly done to control our routers over the Internet, bypassing SNMP).
We were working on comm and multimedia (voice, video, data) over Internet all over the 90s, when the infrastructure was being laid out and the money was pouring from Hollywood, cable companies and the telcos.
Done Satellite, cable, fiber, ATM, etc... for multimedia distribution.
Then I've programmed Android/Linux/RTOS at the kernel level, done device drivers, done wireless phone SoC with multimedia... done BSPs.
I stand for what my comments were, those are based on doing real time firmware on such things.
IMHO, you are confusing specific user implementations with the actual underlaying protocols. You are discussing some specific solutions while I'm describing the generalities that constrain ALL solutions.
We have a saying
"There are many ways to skin a cat"
Last edited:
Hats off to you background.
IMO what you suggest already exists - Ravenna, AES67, Dante. Expensive, full of proprietary IP, and used in specific scenarios, where USB does not suffice. It has never replaced USB despite the many years of existence and it's absolutely no surprise, when comparing the costs and benefits for local audio (i.e. range of several meters only).
I noticed that. You claim DAC manufacturers should use network instead of USB. While I say there are no readily and widely available networking solutions for them, on the host/sender/transmitter/operating systems side. Of course every DAC manufacturer could design some solution for transmitting audio over network, but how would people use them? How would you play audio from browser (youtube, ...), from games, from video players, from all the softwares which (logically) use the audio APIs? And on multiple operating systems, not just windows. What solution do you propose? Because they need a solution, not just a general low-level technology like IP or TCP/UDP. They need audio drivers with standard audio APIs facing towards existing applications. Do you suggest the vendors would build custom protocols including building and especially maintaining drivers from scratch? Why would they do it when the bitperfect and clocking-correct USB audio driver is in every OS, for free? What hardware would they use on their side, instead of the existing selection of inexpensive USB-I2S receiver chips available? Would they hire expensive FPGA pros to prepare firmware for expensive FPGAs? Would they use and maintain complete linux stack in small ARM SoCs, just for transferring the audio stream, with no way of very small latency? What specific solution do you recommend to them?
IMO what you suggest already exists - Ravenna, AES67, Dante. Expensive, full of proprietary IP, and used in specific scenarios, where USB does not suffice. It has never replaced USB despite the many years of existence and it's absolutely no surprise, when comparing the costs and benefits for local audio (i.e. range of several meters only).
Well, right now, the WiiM Ultra is doing it with Tidal Connect. You can get it for 325 bucks on the Internet.
And USB is entirely a different issue...
The Tidal Connect application runs IP over both Ethernet and WiFi. So it fixes the issues with the reclocking that Android and Chromebooks do since those two do not reclock the bit rate over those networks.
As a system, the output from WiiM Ultra is then bitperfect over USB. So, however, they do it, it seems to work and I doubt it was designed from scratch.
It's like an Uber DDC setup... it logically fixes the issue with Android and Chromebooks: The sender sends the audio bitperfect over the network and then the receiver simply takes the data and bridges it from an IP network directly to the USB interface.
I have noticed that Tidal Connect, and Spotify, run the application natively in the WiiM... and the connection is over a network, most likely over some socket and some application they use over TCP. This is fairly common: to design some socket(s) and then to establish the connection via some discovery when the network connection is configured. It's not difficult to do.
There's also a WiiM Home configuration application ( which BTW is unstable when connecting from Tidal HiFi running in a PC.. you need to force the WiiM Ultra to reconfigure, likely generating some broadcast request that the Tidal HiFi program running under Windows recognizes ).
It might be that there is an issue with aging the connection when using Tidal Connect with Tidal in Windows. Who knows? It doesn't happen with Android and Chromebooks. This is a known issue in the WiiM forums. I might have to try using static IP addresses for the WiiM Home... right now I'm still using DHCP to assign IPADDR's to the WiiMs in the network ( got three right now ).
Again, they likely wrote some simple application code... no need to recreate the entire stack. Given that TCP is reliable and has wide bandwidth for audio ( and video ) it doesn't have the issues of Bluetooth.
The way it works, considering that Windows is still in Beta, is fine. There is no reason why the DACs could not incorporate this into their designs and bypass the need for Tidal Connect in a WiiM Ultra box.
In essence, the DAC over the network would appear as another audio device in the PC/Android/Tablet over IP.
It's easier to do under Linux variations, btw.
And USB is entirely a different issue...
The Tidal Connect application runs IP over both Ethernet and WiFi. So it fixes the issues with the reclocking that Android and Chromebooks do since those two do not reclock the bit rate over those networks.
As a system, the output from WiiM Ultra is then bitperfect over USB. So, however, they do it, it seems to work and I doubt it was designed from scratch.
It's like an Uber DDC setup... it logically fixes the issue with Android and Chromebooks: The sender sends the audio bitperfect over the network and then the receiver simply takes the data and bridges it from an IP network directly to the USB interface.
I have noticed that Tidal Connect, and Spotify, run the application natively in the WiiM... and the connection is over a network, most likely over some socket and some application they use over TCP. This is fairly common: to design some socket(s) and then to establish the connection via some discovery when the network connection is configured. It's not difficult to do.
There's also a WiiM Home configuration application ( which BTW is unstable when connecting from Tidal HiFi running in a PC.. you need to force the WiiM Ultra to reconfigure, likely generating some broadcast request that the Tidal HiFi program running under Windows recognizes ).
It might be that there is an issue with aging the connection when using Tidal Connect with Tidal in Windows. Who knows? It doesn't happen with Android and Chromebooks. This is a known issue in the WiiM forums. I might have to try using static IP addresses for the WiiM Home... right now I'm still using DHCP to assign IPADDR's to the WiiMs in the network ( got three right now ).
Again, they likely wrote some simple application code... no need to recreate the entire stack. Given that TCP is reliable and has wide bandwidth for audio ( and video ) it doesn't have the issues of Bluetooth.
The way it works, considering that Windows is still in Beta, is fine. There is no reason why the DACs could not incorporate this into their designs and bypass the need for Tidal Connect in a WiiM Ultra box.
In essence, the DAC over the network would appear as another audio device in the PC/Android/Tablet over IP.
It's easier to do under Linux variations, btw.
Last edited:
Tidal Connect has nothing to do with audio transfer. It is a protocol between a controlling device and Tidal renderer device that tells the renderer what to fetch from Tidal cloud servers - via HTTPS. Your Android device or Chromebook just tells your Wiim, using the Tidal Connect protocol, to fetch audio stream from a Tidal server directly. That has nothing to do with audio transfer between a host and a device. Copilot nicely summarizes:
Hmm... I made a point of that. Tidal Connect runs natively in the WiiM Ultra. The audio data doesn't carry through the network from Tidal HiFi to Tidal Connect. That's how the WiiM Ultra solves the problem. Once it has started to run, Connect goes on its own with the remote. Indeed, often Tidal Connect and Tidal HiFi will unsynchronize from each other and you got to push it to resynch from Tidal HiFi.
Note: In fact I pestered @jean-paul about this when he opened the WiiM Ultra thread.... I didn't buy my WiiM Ultras until I was quite sure of that behavior.
But, it could always if they wanted it. They got the bandwidth. After all, Tidal Connect goes into the Internet when streaming from the Tidal servers.
Another interesting thing, though. Tidal HiFi via Tidal Connect will play audio that was downloaded into the local storage... so that means that Tidal Connect does have the ability to mount the network file system... Or perhaps Tidal HiFi does serve the audio then?
But I think we're looking at one specific solution. The point is that there is ample network connection to carry the music if they so desired.
Don't trust AI. It doesn't recognize User Corner Cases.
Note: In fact I pestered @jean-paul about this when he opened the WiiM Ultra thread.... I didn't buy my WiiM Ultras until I was quite sure of that behavior.
But, it could always if they wanted it. They got the bandwidth. After all, Tidal Connect goes into the Internet when streaming from the Tidal servers.
Another interesting thing, though. Tidal HiFi via Tidal Connect will play audio that was downloaded into the local storage... so that means that Tidal Connect does have the ability to mount the network file system... Or perhaps Tidal HiFi does serve the audio then?
But I think we're looking at one specific solution. The point is that there is ample network connection to carry the music if they so desired.
Don't trust AI. It doesn't recognize User Corner Cases.
Last edited:
?? Please let me quote what I reacted to:
This discussion is going haywire, I am off from this topic.
Now you argue with a network protocol which is used for controlling how a streamer device fetches audio data directly from Tidal servers. But how does it pertain to a DAC which is behind such streamer device? It needs to receive the actual audio stream. WiiM is a linux computer - the streamer, not the DAC itself. It has a DAC inside, and (maybe) can fetch the audio data to an external DAC - via USB.
This discussion is going haywire, I am off from this topic.