"DHCP sounds worse than a fixed IP address"

[Chrispy]

LOL that's hilarious. File it with most audiophile silliness with digital.

 

[sam_adams]

California internet sounds worse than Texas because all the internet content moderators

Like everything else in California, the Internet gives you cancer. Just ask ChatGPT.

 

[Hayabusa]

Imagine how dark the background is with all those zeroes in IPv6.

no no no! you see it all wrong!
the physical interface is '0' -> minus voltage and '1' -> plus voltage.
So we have to balance the number of ones and zeros to be equal so average is zero voltage -> optimal blackness!

 

[pablolie]

Audio is like what, 10Mbps tops if you do 24/192? And it consumes a negligible amount of CPU cycles even on a 10 years old CPU (<6% total utilization as I right now listen to 24bit lossless on Spotify on a 10 year old Lenovo X250?). Even 4K video is 20Mbps tops as per Netflix.
We obsess about the networking and computing stuff in utterly unnecessary ways when it comes to home media stuff. Even in if one had 12 kids glued to 4k, 1GE (wired) and Wifi5 would be completely sufficient. It is really down to basic math. Really. Far more critical applications than audio depend on very basic connectivity.

 

[BeeKay]

does not like multiple DHCPs on the same network

Nobody likes this tbh

 

[pablolie]

Nobody likes this tbh

Totally unnecessary in our homes unless you want to live with complexities there too. Personally I don't. There is a use case for that in business-grade networks (for security and domain ownership reasons) but none at home I can think of.
I do have an MX204 at home because it can host any feature for me to play with, but it is not a part of my simple home network and it is turned off as a rule.

 

[dualazmak]

If your IP has as many zeroes as possibly you get quieter blacker background 10.0.0.1 is much better than 192.168.1.99 the 9 are the worst’s
/s

Very nice, and good fit for the fun thread!

 

[Palladium]

Totally unnecessary in our homes unless you want to live with complexities there too. Personally I don't. There is a use case for that in business-grade networks (for security and domain ownership reasons) but none at home I can think of.
I do have an MX204 at home because it can host any feature for me to play with, but it is not a part of my simple home network and it is turned off as a rule.

Yeah, but it fits into placebophilia's axiom of making anything overcomplicated.

 

[xray]

The best static IP addresses to use are the ones ending in a fibonacci number. 144 is the sweet spot for critical listening.

 

[BeeKay]

Why even bother with higher levels of the OSI model. TCP/IP isn’t needed for audio

 

[dualazmak]

The best static IP addresses to use are the ones ending in a fibonacci number. 144 is the sweet spot for critical listening.

I have a different perspective.

In IP addresses in our audio chain, we should always use prime number(s) since it/they cannot be interfered by any other natural numbers ensuring less/minimal noises. This has been predicted/hypothesized by Bernhard Riemann, but still not yet proved. Many people believe, however, it is true!

 

[xray]

I have a different perspective.
We should use prime number(s) since it/they cannot be interfered by any other natural numbers ensuring less/minimal noises.
This has been predicted by Bernhard Riemann, but still not yet proved. Many people believe, however, it is true!

The fibonacci ratio occurs in nature so will be more natural sounding. The golden ratio is for golden ears. Prime numbers sound too clinical which is why 144 is the sweet spot.

 

[xray]

It's so sad that our jokes aren't that far off from what some people actually believe.

 

[fatoldgit]

I musta missed some parts of your reply:
Why do you exactly need all of this costly 10GB network switches and Cat8 cables, for your 60k FLAC/WAV collection?
Wouldn't a local NAS and using a local DHCP for a local "static IP" suffice and result in *neater/*cleaner solution?
[*neater/*cleaner, only because I will not debate claims of better sound.]

I had an internal debate with myself about whether I should end my post with "/s" but I didn't.

I had assumed that statements like "Of course I need the headroom of this setup, which is capable of 5000 MBytes/second, to avoid contention/packet retries when playing back my 200 KiloByte/second FLAC tracks. You gotta have head room, just in case!!!!." would indicate where I stood on the computer audio bullshit/snake oil divide (i.e. pointing out why would anyone need such a high level of ethernet bandwidth when even 100mbit (10 MBytes/sec) ethernet has ample headroom for music streams.

Sarcasm is a national sport in my country and I sometimes err on the assumption that it is obvious to others.

Reassuringly, I have none of the things I listed aside from 60k of FLAC files (which I won't be converting to WAV for that extra level of fidelity)

My digital file delivery actually involves:

- A $200 used PC with a 4TB SSD drive ($200) running Linux (outside of my listening room in my server closet...down to 10 servers since retiring from Unix/Linux software development)
- A $200 fanless/diskless Intel PC (inside my listening room on my rack) running a ram booted Linux that mounts the flac files over NFS
- The fanless PC uses a $150 LPS and connects via USB into my DAC
- I have structured wiring in my house consisting of 48 runs of cat 6 that connects into a central patch panel
- The music server and the client are obviously connected via ethernet and I use an inline $50 ethernet isolater from a real world engineering company between them
- All external ethernet cabling (i.e. not inwall) is bog standard cat 6 (ie. what professionals such as myself use in data centers)

Total outlay is $800 (excluding the structured wiring)

I needed the structured wiring for my professional work where I had, at peak, around 20 different Unix and Linux servers (supporting various releases of HPUX, Solaris, AIX and the main Linux enterprise vendors Suse, Redhat and Ubuntu). Plus on top of that associated development workstations and backup servers that supported the workload.

Peter

 

[voodooless]

no no no! you see it all wrong!
the physical interface is '0' -> minus voltage and '1' -> plus voltage.
So we have to balance the number of ones and zeros to be equal so average is zero voltage -> optimal blackness!

Ironically this technique is called “date whitening” in some implementations. On Ethernet something similar happens, but it’s called “scrambling”. It’s not exactly the same, but close enough. Whitening is mainly use in RF, where scrambling is used on line links like Ethernet. Main reason to do this is EMI and clock recovery.

 

[solderdude]

More expensive = sounds better.
Everything matters.

Audiophool thinking in a nutshell

 

[fatoldgit]

The lease (resource consuming???) timer is a nonsense; there is no such thing,

While not an advocate of AI queries (but it saves time in this case), sticking "what checks dhcp lease time" into google returns.

How the Client Checks & Renews

1. Lease Expiration Timer: When a device gets an IP, it starts a timer based on the lease duration provided by the server.
2. Renewal Attempt (T1): At the halfway point (50% of lease time), the client sends a DHCPREQUEST to the server to renew.
3. Rebinding Attempt (T2): If the server doesn't respond at the 50% mark, the client waits until 87.5% of the lease time is up and sends another DHCPREQUEST (often to any DHCP server).

This can be cross referenced against any number of documents on the web, so a timer does exist as the client needs to check at 50% and optionally 87.5% into the lease time.

However, we can agree (despite my sarcastic first post on this subject) that the timer (nor anything else related to DHCP) can mean a fixed IP address is better for music reproduction.

Just more stupid FUD from the Network Audio Industrial Complex.

Peter

 

[phofman]

The lease (resource consuming???) timer is a nonsense; there is no such thing, When it expires, you just need to disconnect and reconnect (and it's getting done behind the scenes, usually)

Well, actually the process in charge of the dhcp client (dhclient, network manager, etc.) does wait for the dhcp lease to renew shortly before expiration. Of course it's waiting on blocking select, so no CPU is consumed, it only takes a slot in the scheduler queue.

 

[fatoldgit]

^^
Argghh, it took me near 6 months of ownership (of a NetGear DocSIS3.0 cable router) before I figured why its DHCP (by MAC address) was not fully working.
It turned out, this cable router' DHCP-table only allows a maximum of 8 static IP assignments and Dante Controller does not like multiple DHCPs on the same network.

Eight!!!!

that's crazy..

 

[phofman]

One could equally well argue that having the processor running at close to 100% all the time will be better because it will produce less switching noise from going through multiple power/idle states, and hence you will get much more inky blackness or whatever

Actually it has been discussed here and elsewhere that the processing delay incurred by cpu freq switch on RPi is up to several ms which ruins ultra-low-latency setups. The cure is to run with the "performance" cpufreq governor (i.e. fixed frequency), but with cpufreq lowered to minimum available (600MHz?). Quite a few people do so.