I’m confused by your definition of the endpoint as a “streamer”… It is just a “renderer” of digital-audio signals being delivered by transmission protocol like UPnP/DLNA, etc, over Ethernet… No? It does not provide access to internet streamed content as a function of the device…
Yes, and “streamer” is a valid common definition of what it does.
A device that can both serve as an endpoint for a server on the LAN, but can also play local files from a drive that is attached to it, and/or access the Internet and play content from Qobuz, for instance, is more commonly called a “Network player”.
These words are used indifferently on the audiophiles forums in English.
I’m just familiar with “Network Player” as a streaming device… Any other interface that converts UPnP, etc, protocol encoded digital-audio data distributed over Ethernet to USB as an endpoint/renderer… I now clearly understand how you are using the term…. Thanks again for your clarification. 
For this model of streamer, the word “renderer” is part of its name.
But actually, like any other streamer, it has various renderers for various streaming protocols. The word “renderer” refers to the bit of software that renders the sound. (UPNP renderer, Roon Bridge, etc…)
I am under the impression that an “endpoint/media renderer” is just a decoder/translator of the protocol data it receives and delivers the converted signal to the DAC via isochronous USB, S/PDIF, i²S or AES/EBU protocol.
It’s more than that. In all the cases, it receives a sound that is not rendered, and it renders it.
But you can stream to it the tracks in their storage format, Flac for instance, and it will decompress them as well.
Depending on the features of the streamer, it can also process the sound in different ways. It can upsample it. It can apply to it convolution, etc…
I can see how a network player and the connected DAC will decode the digital-audio file format… To me, an endpoint/renderer only extracts the digital-audio data from the carrier protocol, where the extracted signal is then decoded by the DAC architecture.
The rendering is done by the renderers on the streamer. The sound is clocked then to I2S inside the streamer.
If the streamer is attached to the USB port of the DAC, for instance, it will be translated to USB packages, and clocked, during its transfer to the DAC. If it is attached to the I2S port of the DAC, for instance, it will be transferred to the chip without any translation or reclocking.
The endpoint/renderer extracts the isochronous USB digital-audio signals from the transfer protocol (in the case of USB)… So, yes the DAC will always be the decoder… However, it seems you are describing the use of some receiving OS on a device like RPI that acts as a decoder like a DDC…
The RPI is not a streamer. It is a cheap general purpose computer that accepts additional electronic boards.
There are all kinds of electronic boards for it, and many OSs that enhance its features.
And there’s an increasing number of steamers that are not based on a RPI who have a built-in DDC.
Guys : I guess a picture talks more than words …
Works both in USB (USB256) and Coax (USB64)
& Ropieee config is a breeze…
Probably would sound 152.7% better in MQA😉
@Cloclo … If Core Audio is not used in a Ethernet connected transfer of the digital-audio signal to the DAC, how does Audirvana utilize Audio Units DSP and manage sample-rate for that connection? Are you telling us that a user cannot apply DSP or that sample-rate is ambiquously clocked by the Ethernet connected DAC?
Let’s not go there for the time being… 
The two things have nothing to do.
The player applies DSP to the track, and then streams it to the endpoint.
It’s not that simple… Audirvana does not usurp the macOS, it is running inside of macOS in a symbiotic state of operations… Ethernet bus controller operations are intrinsically tied to macOS APIs.
If the macOS doesn’t see the endpoint/renderer, then how does Audirvana know the IP address of the endpoint? The macOS is controlling the general Ethernet traffic on the Ethernet bus of the Mac. How does the endpoint know what sample-rate that is being transmitted on the Ethernet bus if not being transferred through Core Audio to the Ethernet bus output controller, as that information is derived from the digital-audio file being played in Audirvana that was delivered by Core Audio APIs?
Certainly there are UPnP markers, etc, that are produced by Audirvana UPnP API(s) which is running on the macOS… Audirvana’s clock is derived from the sample-rate of the digital-audio file and sends synchronization information to the DAC and acquires information about the operational functions of the DAC in the synchronization process, so it knows what protocol it will receive signals on… This is why Audirvana did not see DoP capability in the Dietpi OS, because when queried about DoP operations, Dietpi could not respond…
You are messing everything in your theories.
-
I said that macOS does not see the renderer, and it doesn’t. Audirvana alone sees it.
The Ethernet service of macOS just streams the DATA to an IP address on the LAN. It does it with the protocol that is embedded in Audirvana, and not in macOS.
The same thing happens when DATA is streamed on the LAN or from/to the Internet by other kinds of application with protocols that are embedded in the apps, and not in macOS.
All this has nothing to do with Core Audio. -
It’s not a rendered sound that is streamed, but WAV or DSD in Ethernet packs. And they are streamed from the server to the endpoint. The endpoint is the streamer, and it knows which kind of sound it is receiving with the Ethernet packs, the same way that Audirvana knows which kind of sound is stored by the file on the drive: the sound has a header with technical metadata.
Audirvana communicates with it, and synchronizes with it, while using the Ethernet services of macOS. -
The DAC has nothing to do with all this, because the DATA is streamed to the streamer, not to the DAC. The synchronization is between the server, and the endpoint (streamer). The DATA is processed first by the streamer, and only then the sound is transferred from the streamer to the DAC.
-
@dh3rm3 could not stream DSD, probably because he did not configure DietPi correctly, and not because of your theory. DietPi is the OS that run on the streamer.
I understand how you interpret what happens… I think there is something getting lost or mis-interpreted in the translations of my statements regarding this… It’s okay, I get what you are trying to communicate… We understand that everything Ethernet is intrinsically tied to macOS… Core Audio is necessary for Audirvana to get access to the digital-audio files and run Audio Units DSP, up-sampling, etc, etc… Try running Audirvana without Core Audio APIs…
The DAC receives from the rendering processes, the packetized isochronous USB signal, which carries the digital-audio signal (bits and words) and clocking/sample-rate information, etc, just like it would if the DAC were connected directly to the USB port of the Mac, where subsequently, this digital-audio signal is clocked asynchronously in the DAC architecture… Only when the renderer hardware platform has a unified DAC architecture will it require synchronization with the digital-audio signal it receives and decodes and converts to analog signals… otherwise, it is acting as a “bridge” to the DAC input architecture, that is responsible for requesting the data and insuring a synchronized buffer of USB data to the DAC USB receiver architecture, so to prevent interrupts which cause loss of signal, that creates playback problems, etc…
Dietpi OS is the UPnP rendering engine for the packetized Ethernet signal and output format bus controller (USB, S/PDIF, etc.) of the hardware platform it is operating on… I understand that Dietpi OS was not configured properly and this is why I pointed to the Linuxaudio.org for some insights for configuring Dietpi OS for USB audio… I had at the same time, seen the Dietpi thread about DSD/DoP capabilities, before bitracer posted it here.
There are a few inaccuracies in your post. I’ll just point to this one:
Audirvana does not need Core Audio to access the digital files. Any app on the Mac can access them, and process them for any purpose (format conversion, tagging, etc…). The services of Core Audio are involved if the app streams the sound to a device that is attached to the Mac or with AirPlay.
When Audirvana upsamples with its own DSP engine, Core Audio is not involved at all.
I don’t think that Core Audio is involved when Audirvana uses the Audio Units.
- If these plugins were depended on Core Audio, they would have been available as a macOS service for all the players on the Mac. But it’s not the case. Only players that are compatible with this format of plugins can use them.
- I use Audirvana only for headphones listening. I always do it with CanOpenar, which is an Audio Units plugin, while streaming UPNP. It does not make the endpoint appear in Audio MIDI.
Since this topic seems to interest you, I would suggest to you to buy a basic RPI for $80, and practice streaming with the free Linux distributions. You’ll lean many things.
Otherwise, it’s similar to trying to learn to swim at home by reading articles about swimming on Wikipedia.