advertisement


MDAC First Listen (Part 00101010)

Status
Not open for further replies.
As an addendum to the network streaming discussion:

I've examined AVB more closely and it seems like a very promising technology for "our" use case. Driven by the guarantees and low latencies required in the automotive industry, it can go really low (4uS delay on an unused Gbit link) and - most importantly - supports a "clock grandmaster", ie. a single clock hopefully honored by the sender ("talker").

It also is not just a RTP acceleration, turns out it primarily uses IEEE-1722.1 (no IP layer) and is pushed quite significantly by XMOS as well, with firmware available. In terms of OS support, it's getting there and it's multiplatform.

There are apparently still some outstanding issues, like sending devices not listening to external clock, etc., but give it a few years and we may have a decent standard. One that also allows vendor-specific data to be send (ie. firmware update), etc.

PreSonus seems to be already using it.
 
jirij said:
UPnP is a generic autoconfiguration / discovery "protocol" (actually again a set of protocols), not really tied to audio streaming in any way. It can be used for anything like printer discovery on a network, to automatically forwarding a port on your router (for computer games), to ie. discovery according to DLNA. It's "just" a convenience protocol, all the stuff it does can be done manually.
Click to expand...

Yes, indeed, but it negates the view that it's all very complicated and difficult.

- Richard.
 
JohnW said:
Out of interest what's wrong with the type "B" connector?
Click to expand...

The number which have broken on the MDAC.

The almost non availability of diy type B plugs.

The fact that a committee says they should used.

And I know of of no engineering reason to use them, happy to be educated otherwise though.

To save buying/using an A-B adapter, which in its availability surely demonstrates that the committee was ------.

It is only 5V not he same as an Iec plug/socket which could have lethal voltage on the pins.

Surely the hardware should determine wether it is required to transmit or receive power. How can a cable plug do this ?



Nothing apart from the above :D
 
jirij said:
As an addendum to the network streaming discussion:

I've examined AVB more closely and it seems like a very promising technology for "our" use case. Driven by the guarantees and low latencies required in the automotive industry, it can go really low (4uS delay on an unused Gbit link) and - most importantly - supports a "clock grandmaster", ie. a single clock hopefully honored by the sender ("talker").

It also is not just a RTP acceleration, turns out it primarily uses IEEE-1722.1 (no IP layer) and is pushed quite significantly by XMOS as well, with firmware available. In terms of OS support, it's getting there and it's multiplatform.

There are apparently still some outstanding issues, like sending devices not listening to external clock, etc., but give it a few years and we may have a decent standard. One that also allows vendor-specific data to be send (ie. firmware update), etc.

PreSonus seems to be already using it.
Click to expand...
I'm baffled by the difficulties of audio over Ethernet, but defer to your technical knowledge. Slimdevices seemed to manage it at least 10 years ago. How did they achieve it? All I ever understood was that the server doesn't know it's sending audio, just data. Which, to me, is as it should be. I was under the impression that there was a buffer and that the player told the server when it was filling up or emptying. What's wrong with any of this?
 
adamdea said:
I'm baffled by the difficulties of audio over Ethernet, but defer to your technical knowledge. Slimdevices seemed to manage it at least 10 years ago. How did they achieve it? All I ever understood was that the server doesn't know it's sending audio, just data. Which, to me, is as it should be. I was under the impression that there was a buffer and that the player told the server when it was filling up or emptying. What's wrong with any of this?
Click to expand...

Audio over ethernet. It's no problem. Has been around a while, in studios even (if it works there, it's absolutely fine for the home) - see for example the complete range of products by Focusrite, RedNet as it is called.
For the home, well I think the market for wired networking products is perhaps a little small (these days) anyway. Give someone the choice and wireless has a lot of advantages. I'm happy with it for my hi-fi, although I do also use direct connected USB etc on some devices. I'd use Ethernet audio if I had a big enough home (recording) setup to warrant it. Just in my hi-fi, nah really not worth it (IMHO). So anyway, audio over ether is fine, after all it's just yet another way of transferring digital bits down some wires.
 
jirij said:
UPnP is a generic autoconfiguration / discovery "protocol" (actually again a set of protocols), not really tied to audio streaming in any way. It can be used for anything like printer discovery on a network, to automatically forwarding a port on your router (for computer games), to ie. discovery according to DLNA. It's "just" a convenience protocol, all the stuff it does can be done manually.
Click to expand...
I think it defines rather more than that.

For AV, using uPnp, a 'controller' commands a 'renderer' to collect and render a file from a 'server'. So the renderer has complete control. I think uPNP goes wrong with library management and and other non-audio related ergonomic issues.

For Squeeze I think the server can request the current buffer status from the player before sending more audio, so data flow is effectively controlled by the player.

Paul
 
adamdea said:
I'm baffled by the difficulties of audio over Ethernet, but defer to your technical knowledge. Slimdevices seemed to manage it at least 10 years ago. How did they achieve it? All I ever understood was that the server doesn't know it's sending audio, just data. Which, to me, is as it should be. I was under the impression that there was a buffer and that the player told the server when it was filling up or emptying. What's wrong with any of this?
Click to expand...

+ 1
 
I think that some of you are mixing thing up and making a apple and oranges comparison.

When discussing Ethernet there are two scenarios.

1. Ethernet is used between server and media render (streamer).
2. Ethernet is used as a data connection between streamer/computer to DAC equivalent to USB, SPDIF, Coax.

The FDAC is not a steamer else it would have to have a streamer build in and I believe this is out of scope.
 
Rune said:
The FDAC is not a steamer else it would have to have a streamer build in and I believe this is out of scope.
Click to expand...

I believe the FDAC will have a wifi option (John substituted wifi in place of his original idea to have bluetooth connectivity).
 
moosemeat said:
I believe the FDAC will have a wifi option (John substituted wifi in place of his original idea to have bluetooth connectivity).
Click to expand...
Yes but that solution is hardly relevant for the discussion, because it is only for airplay/or similar connection and not supposed to be a substitute for a HQ streamer.
What people is discussing is if Ethernet can be better than USB.
 
Rune said:
I think that some of you are mixing thing up and making a apple and oranges comparison.

When discussing Ethernet there are two scenarios.

1. Ethernet is used between server and media render (streamer).
2. Ethernet is used as a data connection between streamer/computer to DAC equivalent to USB, SPDIF, Coax.

The FDAC is not a steamer else it would have to have a streamer build in and I believe this is out of scope.
Click to expand...

Yes, Rune's summarised the point succinctly
 
BigDog said:
...and see that one attribute is impedance matching
and the addition of resistance to the USB hub

http://uptoneaudio.com/blogs/news/2...-bass-all-unshipped-orders-will-be-the-latest

which supposedly improves sonics particulary in the bass region.

How would either of these 2 things be relevant to the DETOX?
Click to expand...

Good questions... This sort of raving about product improvements and shipping now claims, smack of sales patter for the gullable...again no data/scientific explanation provided.... This was back in July, maybe JohnW has this improved version?
 
BigDog said:
...and see that one attribute is impedance matching
and the addition of resistance to the USB hub

http://uptoneaudio.com/blogs/news/2...-bass-all-unshipped-orders-will-be-the-latest

which supposedly improves sonics particulary in the bass region.

How would either of these 2 things be relevant to the DETOX?
Click to expand...

timola said:
Good questions... This sort of raving about product improvements and shipping now claims, smack of sales patter for the gullable...again no data/scientific explanation provided.... This was back in July, maybe JohnW has this improved version?
Click to expand...

On a simple level, it's just another element of filtering

Leave it to the designer to work out how he wants to implement the overall multiple filtering levels he's got planned and has outlined previously
 
timola said:
Good questions... This sort of raving about product improvements and shipping now claims, smack of sales patter for the gullable...again no data/scientific explanation provided.... This was back in July, maybe JohnW has this improved version?
Click to expand...
Improving one aspect of the frequency range of a digital signal seems like a pretty neat trick to me
 
adamdea said:
Improving one aspect of the frequency range of a digital signal seems like a pretty neat trick to me
Click to expand...

You are attempting to apply simplistic thinking to something you either don't understand or pretend not to understand. Auditory perception is far more complex than just a reaction to changes in frequency & amplitude of the signal. Certain differences, like reduction in jitter (& maybe reduction in noise modulation), can be perceived as an enhanced bass. I'm not saying that the addition of the resistors in the Regen necessarily results in noise modulation or jitter reduction - we don't know without measurements - but the simplistic statement that "Improving one aspect of the frequency range of a digital signal seems like a pretty neat trick to me" shows some lack of understanding of the underlying issues

Surely you have read JohnW's reports of the "second order" effects he has posted before & of the auditory perception of some of these effects he has experienced?
 
adamdea said:
If you say so. There have been streamer/renderers with built in dacs for some time.
Click to expand...

Yes but we have been through the same discussion many times before on this thread.

And the conclusion last time was that there will be no streamer build into the FDAC.

It would be impossible for John and Dominik to support a streamer and it is much better that Dominik focus on the advanced features that is possible with the FPGA.

There are lots of steaming platforms to choose from so you can choose your preferred flavor and I can choose mine and hopefully the Detox can make them very close to equal.
 
Status
Not open for further replies.


advertisement


Back
Top