Last edited:
Ray, are you using BBB USB out->Amanero->S03 or BBB->BBB-I2S or BBB-DSD adapter->S03 ?
Ray, I am throwing in a wild guess here but you have upmpdcli sitting in top of MPD, so this is doing the DoP to DSD 'conversion' and forwarding native DSD to Botic.
So again I reckon JRiver is actually 'streaming' DoP instead of native DSD as you have thought. As I indicated before I cannot seem to find any clear reference that JRiver actually bitstreams native DSD like what ASIO does for USB
Jurgen,
I'll send you an email on that topic next week.
And just for my interest, those commercial DAC's you added a USB "quirk" to kernel code for switch to native DSD output, (Denon and Marantz, maybe, but I can't remember), are they only capable of native DSD? They cannot decode DoP?
I don't believe so; my understanding is that upmpdcli doesn't touch the data and just pulls the strings of mpd so it looks like a UPnP renderer.
But, that's one of the avenues I'm checking out.
Ray
Maybe the dropout are from the DAC chip, it the BIII filters are not set right I get dropouts, I don't remember which DAC you are using.
Acko, I'm qualified to answer this one. First of, just to be clear the term "native DSD streaming", doesn't apply in a networked enviroment as the flow runs between different systems.
The following applies for both UDP and TCP packets. Routing/switching a packet across a network needs additional data, hence application information (=audio bitstream) is put into for example an Ethernetframe, which has an ethernet header (14Bytes) and a maximum MTU size (ex.:1500Byte), so the original stream gets chopped up, into these frames. In addition, a IP/network header (20Bytes) is added to be able to "route" a packet across a network. Each time a IP packet is switched/route at a "hop" a couple of ms of latency is added. In other words there is lot more to a network compaired to a point-2-point USB cable.
Due to the shared nature of a network, end-2-end data rates are variable. Some other application or host can throw some traffic onto the bit of network your audio feed is running over, and mess things up
Therefor the next importent aspect of what makes networks work, are buffers, every network interface (and processors for that matter) has these. Buffers, often Fifo (first in first out), handle variation in data rate and latency..
There are definitly ways to optimize a LAN for streaming, but unless you want to become a networking expert its best to throw enough bandwidth at it to not create any bottlenecks and to not connect to many other hosts on your LAN or make them do network intensive things like big file copying jobs etc... It's also good to install very few application, some are surprisingly chatty (Apple/Adobe) and watch out for mallious software which can also put load on a network..
Hope this helps.., & hope I'm not telling anybody how to "suck eggs"
Well you have a point, meaningful information about JRiver native DSD streaming is hard to find. But I just did some more Googling, and I see an interesting Jriver forum thread here -
DSD streaming to OPPO BDP-103/105 - DFF and DSF files
Several forum members modified a JRiver configuration file (FileAssociations.xml) in order for native DSD streaming to work - between JRiver server and an Oppo 105. This seems conclusive, since the Oppo does not support DoP/DoPE. So if DSD audio can be streamed to the Oppo, then the stream must certainly be native DSD.
In context, I'm guessing you meant "native DSD (bit)streaming solution" and if so, then no - there are certainly several UPnP server applications (apart from JRiver MC) which will stream native DSD: oShare, MinimServer, and Twonky.
... but none of this helps with nautiboy's problem with BubbleUPnP controller failing to handle DSD. I actually mentioned this potential problem back in January in the "Slice Media Player" thread.
It appears to me that some interoperability issues need to be sorted out by the BubbleUPnP developers.
Acko, do you understand that DoP is nothing other than a transport mechanism, a way of encapsulating DSD data for transport over a PCM interface? Aside from the waste of 8 bits of every 24 bit frame for the DoP header, to identify the data as being DSD, to whatever it is that is going to be receiving the data, it is still pure DSD data that is being transported, not transcoded.....
Ultra pure..... DoP won't cut it..... The start of an urban myth and catering to people afflicted with audiophile nervosa!
Acko, do you understand that DoP is nothing other than a transport mechanism, a way of encapsulating DSD data for transport over a PCM interface? Aside from the waste of 8 bits of every 24 bit frame for the DoP header, to identify the data as being DSD, to whatever it is that is going to be receiving the data, it is still pure DSD data that is being transported, not transcoded.....
Ultra pure..... DoP won't cut it..... The start of an urban myth and catering to people afflicted with audiophile nervosa!
Agreed and understood
I also became better informed after reading more on this at DoP open Standard | DSD-Guide.comSo DoP delivers native DSD. I stand corrected!
Acko, I'm qualified to answer this one. First of, just to be clear the term "native DSD streaming", doesn't apply in a networked enviroment as the flow runs between different systems.
The following applies for both UDP and TCP packets. Routing/switching a packet across a network needs additional data, hence application information (=audio bitstream) is put into for example an Ethernetframe, which has an ethernet header (14Bytes) and a maximum MTU size (ex.:1500Byte), so the original stream gets chopped up, into these frames. In addition, a IP/network header (20Bytes) is added to be able to "route" a packet across a network. Each time a IP packet is switched/route at a "hop" a couple of ms of latency is added. In other words there is lot more to a network compaired to a point-2-point USB cable.
Due to the shared nature of a network, end-2-end data rates are variable. Some other application or host can throw some traffic onto the bit of network your audio feed is running over, and mess things up
Therefor the next importent aspect of what makes networks work, are buffers, every network interface (and processors for that matter) has these. Buffers, often Fifo (first in first out), handle variation in data rate and latency..
There are definitly ways to optimize a LAN for streaming, but unless you want to become a networking expert its best to throw enough bandwidth at it to not create any bottlenecks and to not connect to many other hosts on your LAN or make them do network intensive things like big file copying jobs etc... It's also good to install very few application, some are surprisingly chatty (Apple/Adobe) and watch out for mallious software which can also put load on a network..
Hope this helps.., & hope I'm not telling anybody how to "suck eggs"
Thanks Stijn001, all understood now. Put it another way, does not matter if data is delivered by the postman or the bucket brigade. All gets assembled in the buffer and the actual streaming happens afterwards
Did anyone actually express that opinion here?
In case it isn't clear, the situation we have here is that BBB/Botic is a native DSD capable network renderer. To the best of my knowledge based on the recent dialogue, it cannot handle DoP. Therefore we can aim to get native DSD to it or it needs to be modified to accept and process DoP, either will deliver 'pure' DSD data to the DAC.
Ray
Just to eliminate one or two possibilities, I've done a completely clean install of Botic V4 and then updated to V5. Incidentally, upmpdcli is now included within the distribution so no need for a separate installation.
The updates made no difference to the recognition issue I'm experiencing but at least I'm now on the current versions of software.
The quest continues.
Ray
The updates made no difference to the recognition issue I'm experiencing but at least I'm now on the current versions of software.
The quest continues.
Ray
For what's it worth this is what I used with the Amanero, I think
- FOR Amanero Hi Resolution INPUT
- Quantizer 6 Bit, The best measured performance is reached when the quantizer is set to 6-bits, and differential is set to True, HifiDuino software automatically sets 6 Bit Differential to TRUE.
- FIR Roll Off Slow
- IIR = Normal = for PCM
- DPLL BW, LOW = less jitter HIGHEST = better lock. Note: May need to adjust depending on lock
- Notch = in 6 bits mode run at 64
- DPLL BW Multiplier = 128x I found this gave better Lock
- Oversampling = ON
Ray,
Sure and I understand that. That is your technical reason.... There is no reason for wanting it (BBB/Botic) to output DoP, when speaking directly to a DAC (like the BIII) that can accept "native" DSD. (Not that DoP is some kind of "lossy" DSD format, second class citizen, and inferior to "native" DSD. Would hate to see that being put across as an argument. Because it wouldn't be true.
)
(Not that DoP is some kind of "lossy" DSD format, second class citizen, and inferior to "native" DSD. Would hate to see that being put across as an argument. Because it wouldn't be true.
Completely agree, what DSD data arrives at the DAC should be identical regardless of the mechanism used to get it to the renderer.
I'm hoping that utilising native DSD will be the path of least resistance in my set up.
Ray
BTW, are you the same Clive that I travelled to Seattle with a few years back?
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.