06-06-2015, 12:59 AM#13
Superdad
Music lover; Owner, UpTone Audio
Join DateApr 2008
LocationMariposa, California
Posts3,750
Originally Posted by jabbr
I don't think Audirvana is playing in the streaming space. HQPlayer with NAA already has this nailed. Nothing for Ravenna to add (IMHO). Can't comment
on XXHighEnd ... but would be willing to if a NOS1a happened to show up on
my doorstep
What I meant is that I wonder about the compatibility between the
06-06-2015, 01:42 PM#18
Superdad
Music lover; Owner, UpTone AudioJoin DateApr 2008
LocationMariposa, California
Posts3,750
Originally Posted by Cebolla
What I was attempting to point out in my first post is that the Ravenna model
uses the network between the audio file player and DAC, whereas
the
majority of current music file streaming devices use the network between a
udio file storage device and audio file player (ie the streaming
devices are
the audio file players).
Ravenna uses the network to carry the (realtime) digital audio
signal, so the
DAC is subject to any network timing issues and Ravenna needs
to account for this. On the other hand the streaming devices
(network audio players/renderers/streamers) I mentioned use the network to carry audio
file data (ie, non-realtime and yet to be decoded to a digital audio signal),
so any DAC further down the chain is not subject to network timing issues.
That's better; Glad we are on the same page John.
That's also what I was alluding to (barely because I was really tired) inI think you know this more than most.
All that said, I think Ravenna/AES67 has to make it out into the real
06-06-2015, 06:28 PM#21
Serge_S
Freshman MemberJoin DateSep 2013
Posts49
Originally Posted by Cebolla
Ravenna uses the network to carry the (realtime) digital audio signal, so the DAC is subject to any network timing issues and Ravenna needs to account for this.
John, do you mean to say that Ravenna encodes clock with audio signal similar to AES/EBU? Thanks
09-15-2014, 02:07 PM#33
Miska
Masters Level MemberJoin DateApr 2010
LocationFinland
Posts6,685
Blog Entries12
Originally Posted by tranz
But if all the user wants to do is serve audio files unaltered, unprocessed, without upsampling to the DAC, why would DLNA not suffice?
That's quite limited use case...
I didn't even get to dealing with digital room correction and multichannel setups yet.
Are there packets or bits getting lost without the user knowing?
For getting unaltered data to DAC, DLNA is not good either. First, to get anything started it requires very delicate dancing between three devices. And it requires processing from the renderer (decoding source content). It is not very good for unprocessed either, because you don't know if and how the server is messing with your data.
At the end, It is practically same as telling your web browser to play content from a web server, like YouTube. Control Point is telling which content Renderer (you web browser) should load from the Media Server (web server). If you need to seek backwards, Renderer needs to disconnect from the server and issue a new HTTP GET request, because you cannot go backwards in the stream. Since the GET request is made with byte offset it is only whereabouts with any compressed stream (like FLAC), because exact position cannot be calculated on a variable bitrate.
I didn't like UPnP before, and after implementing UPnP/AV support to HQPlayer I like it even less. It is also very prone to all kinds of network issues which are hard to track down. For example I had two dumb gigabit switches (non-managed) that didn't pass UPnP for some strange reason, but for example NAA was working fine through those. I spent lot of time chasing down why it didn't work and at the end, using Wireshark I discovered that the mDNS packets sent to the switch didn't appear on any other port. It's a tech support nightmare.
09-15-2014, 05:36 PM#41
Miska
Masters Level MemberJoin DateApr 2010
LocationFinland
Posts6,685
Blog Entries12
Originally Posted by vortecjr
I'm sorry your having problems with your UPNP implementation, but they are your problems not mine.
Again, I'm not talking of any particular implementation, I'm talking about the standard.
UPnP standard is built on top of HTTP standard and limitations and stupidities of HTTP standard have nothing to do with my implementation. You can also read yourself what UPnP/AV standard says about server side transcoding and what DLNAstandard says about mandatory and optional codecs.
It is not my implementation problem either if BubbleUPnP nor PlugPlayer can find MinimServer (or Sony TV, game consoles, Windows or anything else) over UPnPbecause switch doesn't let the necessary ethernet packet through. I've also heard of similar problems for certain internet routers between their built-in WiFi and ethernet too. And I've read reviews of UPnP gear on magazines too.
None of this has nothing to do with my implementation.
By the way, I cannot find Rendu from the DLNA product search:
Product Search
10-24-2014, 11:46 AM#58
Superdad
Music lover; Owner, UpTone AudioJoin DateApr 2008
LocationMariposa, California
Posts3,750
Originally Posted by Cebolla
Certainly it doesn't matter about the music player software's actual music file playing functionality, because that's built into the UPnP renderer and no reason why it can't be designed to be every bit as good.
My best laugh of the day so far. You ought to look closer at what it takes to implement a DLNA renderer. The processor and processing it goes through is immense. And from the s/w side, the architecture sucks as well (for just one developer's screed see: Why do I hate DLNA protocol so much ? | Ben's Lost World - Diary of a GeeXboX developer). Sorry, but to me, DLNA and purist audio are like oil and water.
10-24-2014, 12:52 PM#60
Superdad
Music lover; Owner, UpTone AudioJoin DateApr 2008
LocationMariposa, California
Posts3,750
Originally Posted by Cebolla
Does that mean that you don't believe UPnP devices like the any of the ones mentioned in the above posts, can be considered purist audio ones?
No, I did not mean that. But I also don't want people to think that the Ethernet input/renderer hardware to offer UPnP/DLNA is a walk in the park or all the same. There is just as much affecting the SQ of such inputs as there was/is with USB. And remember all the crappy USB inputs that were/are added to DACs or players in the rush to include USB?
By no means am I saying that MSB's Ethernet/DLNA input module is crap, but I am certain if you asked Dustin what it took to do it right he would tell you a long and tortured story.
There are a VERY few properly done Ethernet/DLNA audio input modules available for OEMs to use in their products. Here is one example: Network Audio Renderer | ABC PCB 100 piece OEM wholesale price for it was almost $400 in 2012.
As for the s/w side of things: Yes, some of the player people seem to manage, but ask them if they like the architecture. DLNA is by no means an elegant or universally compatible solution.
10-26-2014, 03:03 PM#81
Superdad
Music lover; Owner, UpTone AudioJoin DateApr 2008
LocationMariposa, California
Posts3,750
Originally Posted by Miska
In good case, that's called a PC with PCIexpress sound card.
Miska: Along those lines, what might be clever would be do a nice DAC (perhaps a variant of your DSC1) on a PCIe card, but plug it into the far end of an Adnaco fiber PCIe extender (Adnaco-S1B: 5Gb/s Over Fiber Optic Expansion System – 4 PCIe Slots) to provide galvanic and EMI/RFI isolation from the computer. At the computer end (with the PCIe fiber extender card installed), the OS would see the DAC as a sound card (hopefully just using ASIO or WASAPI drivers). So one gets to skip USB, Ethernet, and S/PDIF altogether, and should still have broad compatibility with player s/w.
10-26-2014, 03:25 PM#83
Superdad
Music lover; Owner, UpTone AudioJoin DateApr 2008
LocationMariposa, California
Posts3,750
Originally Posted by Habanero Monk
Not sure what you guys are doing that Dante isn't or Crown or Meridian.
We researched all the audio over Ethernet APIs and systems: Audinate's Dante, Cirrus Logic's Cobranet, Digigram's Ethersound, etc. Some were interesting in that they use data link layer packets instead of TCP/IP packets. But they all had more layers and complexity than what we are after--even if they do manage the very low latency and multicasting required for broadcast and alive sound reinforcement us. Not to mention rather steep licensing costs and the same player software limitations as with DLNA.
Originally Posted by Habanero Monk
Curious as to how you are going to supersede I2S (if I'm reading your post correctly). That would require custom sand I believe.
What I meant was that the Ethernet (and optionally USB) input module at the DACside may not output I2S directly; rather the board would run a high-speed, raw signal (in a format with chip types we are keeping secret for now) over to ether:
a) the DAC board where the licensee would receive it with isolators and flops and feed their own clock, etc.;
or for the DIY version
b) a small board with isolators, flops, and good clocks (which could even be skipped if the user wanted to feed his own clock back), and which would output I2S.
10-27-2014, 04:29 AM#91
Miska
Masters Level MemberJoin DateApr 2010
LocationFinland
Posts6,685
Blog Entries12
Originally Posted by Superdad
Miska: Along those lines, what might be clever would be do a nice DAC (perhaps a variant of your DSC1) on a PCIe card, but plug it into the far end of an Adnaco fiber PCIe extender (Adnaco-S1B: 5Gb/s Over Fiber Optic Expansion System – 4 PCIe Slots) to provide galvanic and EMI/RFI isolation from the computer.
It wouldn't be a single-box solution anymore. Thunderbolt could be used to make it external too (Thunderbolt is just 1x PCIexpress on a cable).
Nice thing is that it would allow busmaster-DMA and could easily do something like DSD1024 at 8 channels...
