LAN Input DACs

[johann]

I think you are missing the point, which is my desire (since 2005 in fact) for a computer to see an Ethernet port as a sound card so ANY s/w can be used. I think the open source netJack might have had the bones for that, but the DAC side was still an issue and there were other problems with that.

 

If you referring to our not needing to pair using IP addresses (just using the unique MAC address that every EN device has), that was simple and is not what necessitated the need for breaking apart the USB stack and inserting a signaling protocol.

 

You're the one missing the point here.

Now you had to build a protocol with Ethernet for OSI level 2 rather than using an existing one (IP with TCP, UDP, IGMP, etc.)

I wonder why.

[prot]

@superdad

sounds like a fun experiment...good luck.

But why do you keep usb in the mix? Compat with existing env (apps/devices/etc)?

Looks to me that the simplest chain is PC > ethernet > eth-to-i2s 'device' > DAC

You only need to build a single eth-2-i2s device (isolated, regulated, etc)...admitedly a much more complex one but the whole chain is simpler... and simpler should sound better too.

Or am I missing something?

[johann]

Looks to me that the simplest chain is PC > ethernet > eth-to-i2s 'device' > DAC

 

Since USB presents a known audio interface to existing sw and hw, I suppose.

[YashN]

johann,

 

If you're really interested in understanding the rationale, there is a lot of information already posted on the subject here by Alex (Superdad) and John Swenson. Use either the search feature or the profile to find these.

 

And when I say a lot, it's a lot.

 

You're the one missing the point here.

Now you had to build a protocol with Ethernet for OSI level 2 rather than using an existing one (IP with TCP, UDP, IGMP, etc.)

I wonder why.

[johann]

And when I say a lot, it's a lot.

 

There is indeed a lot of words, not as much explanation IMHO.

Just curious why one would chose to not use the IP (even TCP) for such an application since it already has error correction, sorting of all packages and instead invent all that (again). Clearly DCHP cannot be such a big problem to overcome.

[YashN]

The explanations are there, in many posts, in several threads.

 

Knocking out one layer of the OSI model will help in their implementation to reduce noise at the DAC's reception PDN.

 

That's the shortest I can describe it as.

 

So, if you're really interested in understanding rather than more interested in trolling (like our friend prot does every day), you'll spend the time and read and think rather than come back here and post.

 

You haven't read anything, have you?

 

Take some time to read all of John Swenson's posts.

 

There is indeed a lot of words, not as much explanation IMHO.

Just curious why one would chose to not use the IP (even TCP) for such an application since it already has error correction, sorting of all packages and instead invent all that (again). Clearly DCHP cannot be such a big problem to overcome.

[prot]

There is indeed a lot of words, not as much explanation IMHO.

Just curious why one would chose to not use the IP (even TCP) for such an application since it already has error correction, sorting of all packages and instead invent all that (again). Clearly DCHP cannot be such a big problem to overcome.

 

Mostly with you but not sure tcp & errorcorrection are best here... those may be more of a headache than gain ... since we are talking less than 10m (and audiophile network cables:) ) udp may be the better choice ... should be good enough (btw, usb audio doesnt have error corection either)

[johann]

The explanations are there, in many posts, in several threads.

 

Knocking out one layer of the OSI model will help in their implementation to reduce noise at the DAC's reception PDN.

 

That's the shortest I can describe it as.

 

They will not remove one layer, just replace it it with their own implementation of that layer.

Besides ti would not work with VLANs or routed networks, But I should probably read more of John's posts first.

 

So, if you're really interested in understanding rather than more interested in trolling (like our friend prot does every day), you'll spend the time and read and think rather than come back here and post.

 

You haven't read anything, have you?

 

I find that quite offensive! If you don't like my posts just simply don't respond.

[johann]

Mostly with you but not sure tcp & errorcorrection are best here... those may be more of a headache than gain ... since we are talking less than 10m (and audiophile network cables:) ) udp may be the better choice ... should be good enough (btw, usb audio doesnt have error corection either)

 

Why would it be just 10 m or less, on the contrary I think it could be much more and having the error correction and package sorting already, would mean that all you need is a decent sized buffer and then you have a nice steady stream to the DACs USB input.

[YashN]

There is a bunch of code they will remove from the micro-controller libraries.

 

Not 'more of John's posts', all of them.

 

The fact that you came back here a few minutes later to write something wrong again shows that you haven't done that.

 

It will take you weeks to get it all.

 

They will not remove one layer, just replace it it with their own implementation of that layer.

Besides ti would not work with VLANs or routed networks, But I should probably read more of John's posts first.

 

I find that quite offensive! If you don't like my posts just simply don't respond.

[prot]

Why would it be just 10 m or less, on the contrary I think it could be much more and having the error correction and package sorting already, would mean that all you need is a decent sized buffer and then you have a nice steady stream to the DACs USB input.

 

Doubt anyone will need more than 10-20m between nas & dac...and even 100m is normally ok for udp.

 

But yours is of course another valid solution and the only way to decide is to test both tcp & udp. My bet is on udp for being simpler and (possibly) good enough ... but it's just a 50-50 bet.

[prot]

...

It will take you weeks to get it all.

no it wont ... cause there's no rocket science anywhere on CA ... on diyaudio.com alone there are tens, maybe hundreds of ppl talking about the same things and building various similar devices...chinese/asian forums are full of such ppl too .

 

P.S.

actually there is no science either ... havent seen a single proper science paper ... and various articles in audiophile journals mean exactly nada.

[johann]

The fact that you came back here a few minutes later to write something wrong again shows that you haven't done that..

 

What's the matter with you, that time of month, is it?

 

It will take you weeks to get it all.

 

And the wife is fine?....

[johann]

Doubt anyone will need more than 10-20m between nas & dac...and even 100m is normally ok for udp.

 

But yours is of course another valid solution and the only way to decide is to test both tcp & udp. My bet is on udp for being simpler and (possibly) good enough ... but it's just a 50-50 bet.

 

Assuming the actual DAC is very close to your amp and your NAS either there or just somewhere else, it could be cm or it could be a magnitude more, right?

 

Although UDP would work too, obviously.

[prot]

Assuming the actual DAC is very close to your amp and your NAS either there or just somewhere else, it could be cm or it could be a magnitude more.

 

That would be the standard setup for most ppl, yes. Dac &amp(s) near each other in an audiorack and the Nas somewhere else. Could be in the audiorack too (e.g. a streacom 10 case looks very much like a nice audiocomponent and can easily host 2-3 hdd-s) or could be in a diff room, closet, basement, etc... i'd say 100m should be more than enough for everyone .

Guess one can go even below ip/udp but you may run into serious issues with a router-in-the-middle config.

 

Anyway, the network part is relatively easy & straightforward ... problem is that no ethernet-to-i2s chip/board exists ... at least I never heard of any...no rocket science either since both are open standards but also not something you can easily do in your garage ... or maybe I'm wrong cause it shouldnt be so hard to find a simple fpga/xilinx/whatever chip that is up to the task. The player on Nas will stream the pcm/dsd bits, you just need to put em in i2s packaging.

[YashN]

Looks like you didn't appreciate the fact that I told you where the information could still be found even after Superdad told you he wouldn't be posting any more details about the project/product.

 

I'll reformulate: it will take you years to understand what Swenson says.

 

Even then, I'm not sure you have the ability to.

 

I'll leave you to dribble with prot the troll in private. You've earned a place on the ignore list.

 

 

What's the matter with you, that time of month, is it?

 

And the wife is fine?....

[johann]

Looks like you didn't appreciate the fact that I told you where the information could still be found even after Superdad told you he wouldn't be posting any more details about the project/product.

 

What's with the constant need to insult others and assert yourself?

[Superdad]

Gentlemen:

Please stop arguing. Or at least don't argue over things that John Swenson or I did or did not say.

I am already thinking it was a mistake to say anything about our project. Nobody here has the details right, and I don't intend to spell it all out. My enthusiasm for what we are doing does not make me a fool. When our solution shows up in some notable DAC introductions from a couple of firms, everyone will get to see and hear it then.

Thanks,

ALEX

[Jud]

Thanks, Alex.

[johann]

Sorry guys!

 

@Alex

 

If it sounded like critic on the design, I was just curious on the design decision to skip IP completely.

I know there are many ways to skin a cat. All the best of luck with your project!

[prot]

@superdad

Would be great if you took that arduous 'fan' with you. Cause I was surely not discussing your proj with johann.

[YashN]

Keep at it, Alex. Don't mind the naysayers.

 

I sincerely hope your solutions get adopted.

 

Gentlemen:

Please stop arguing. Or at least don't argue over things that John Swenson or I did or did not say.

I am already thinking it was a mistake to say anything about our project. Nobody here has the details right, and I don't intend to spell it all out. My enthusiasm for what we are doing does not make me a fool. When our solution shows up in some notable DAC introductions from a couple of firms, everyone will get to see and hear it then.

Thanks,

ALEX

[MikeJazz]

Thanks all for the interest. But please, no more questions on this for a while. We must first get it out there and prove the concept.

 

HAPPY NEW YEAR,

--Alex C.

 

Alex, thanks for your clear and detail answer!

That gave me further food for thought.

 

In the future I might change my current solution and will certainly look into what you will have. So, good luck to your project!

[Kuro]

I just stumbled across this thread. I understand what Superdad and JohnS are trying to do. But I see a number of issues:

 

This whole thing is merely a way to extend the length of the USB cable b/w the computer and a USB DAC by inserting wired LAN in between. We all know how bad USB audio can be (i.e.: too many variables and dependencies on the PC; the software player used on the PC, the USB cable, the power supply that powers the PC, PC OS optimization, etc.) and now, you add the LAN cable type, LAN cable length, router/switch, router/switch power supply and LAN buffering into the equation. Personally, I found that different LAN cable (double foil shielded CAT7) and different length LAN cable can affect the sound. The router/hub too!

 

There are actually more processors involved in this topology compared to USB audio, one XMOS processor on the USB to Ethernet bridge and one XMOS processor on the DAC end. Not to mention the processors inside the router/switch. Even thought they are not full blown PC processors, they are nevertheless an embedded processor, much like the ARM processor in the Raspberry Pi. And we know the software and power supply on the Pi can greatly affect the sound whether it is USB or I2S.

 

Surely you eliminated DLNA, but compared to a PC wired directly to an USB DAC, I see this topology introducing more hardware variables and could make sonic tuning even harder.

 

I also don't see how it is better than the Squeezebox ecosystem. Can you synchronize a few players so they play the same track in different rooms in the house? One can already buy a Pi model B/B+ and attach an I2S DAC on top for low cost. You can install Squeezelite in the Pi and make it part of a Squeezebox ecosystem.

 

Sounds to me this is a remake of the Squeezebox system, except you pulled the processor out of the Squeezebox and place it somewhere else.

[reverendo]

Ok, so I just stumbled upon this thread since I am starting to look around for DACs with ethernet input, be they DLNA or not.

I actually have one of the very few DACs that work as a renderer with DLNA and with two Fiber Media Converters right before the DAC I'm a very happy camper. With this little tweak it beats all the other inputs at the moment, which is no small feat, especially taking into account that both my USB and Digital Coax cable are pretty expensive, not to mention the fact that I'm not using a digital transport.

I just started to look around since I'd love to find what possible upgrade options I would have if I wanted to stick to this means of doing digital audio. I'm especially looking for DACs that have an excellent pre in the DAC, preferably analogue and with tubes, since I'm starting to rethink my 100% SS setup after a very interesting encounter with Raven Audio equipment last weekend.

So, could someone be so kind and point me in the right direction without me having to go through the whole thread at the moment?

Thanks in advance