Voivode + Aether

[Dr Pan K]

Έπεσα επανω στο Orange Pi6+ που εχει 2 θύρες ethernet αλλα και πολύ τσουχτερή τιμή

http://www.orangepi.org/html/hardWare/c ... -Plus.html

[Chris1967]

Έβαλα επάνω και hat Ian Canada TransportPi Digi https://www.audiophonics.fr/en/dac-and- ... sgxH7mvDqP

To voivode αποδεικνύεται πολύ "πηδηχτούλη" (φράση του Δημήτρη) στα reboot αφού αλλάζει IP με κάθε reboot , κάτι που θια πρέπει να το δεις ΜΙχάλη αφού ο μέσος χρήστης δεν γνωρίζει πως να κάνει στατικές τις IP των συσκευών δικτύου.

Από την στιγμή που ρύθμισα στατική την IP κανένα πρόβλημα.

Πρέπει να βάλετε για hat το : Hifiberry Digi+ Prο

Έχει πάρει κι άλλο λίγο σε λεπτομέρεια και σκηνή σε σχέση με το USB.

Τώρα θέλει λίγο περιποίηση στις τροφοδοσίες και είμαι σε αναμονή του USB to Ethernet adaptor, για να τρέξω δύο rpi.

IMG_20260726_143724.jpg (988.89 KiB) Viewed 102 times

IMG_20260726_143711.jpg (828.51 KiB) Viewed 102 times

IMG_20260726_143701.jpg (942.77 KiB) Viewed 102 times

[Tzimisce]

Στο τελευταίο image έχω ενεργοποιήσει το avahl οπότε το βλέπει στο voivode.local όσο "πηδηχτούλι" και να είναι.
Το ότι αλλάζει ip δεν έχει να κάνει με το rpi αλλά με το router.

Παναγιώτη, το ξέρω το orange pi.
Δεν υπάρχει λόγος, το cm5 βγάζει 2 ethernet με το κατάλληλο io board.

Τελικά, μετά από δοκιμές, η τροφοδοσία του πρώτου rpi παίζει ρόλο.
Το να μπει switch ανάμεσα στα rpi και το πείραμα, το πρώτο rpi να κάνει τη μετατροπή σε wav, δεν πήγε καλά.
Αλλά περιμένω να φτιάξω ένα καλό καλώδιο δικτύου για να δοκιμάσω πάλι.

Κάπως όμως πρέπει όλα αυτά να μπουν σε ένα κουτί, γιατί άμα έρθει και το usb reclocker θα μετράμε 6 κουτιά για ένα streamer.

[Dr Pan K]

Με τοσο μικρο μηκος για καλωδιο και συνδεση ethernet υπαρχουν καποια θεματακια.

Signal reflections in short Ethernet cable runs are a real and well-understood issue, mostly stemming from impedance mismatches. Here's the breakdown:

## Why reflections happen

Ethernet (especially Gigabit and above, using 4-pair full-duplex signaling) relies on controlled impedance — typically 100Ω differential for twisted pair. A reflection occurs whenever the signal encounters a discontinuity in that impedance: a connector, a kink, a poor termination, a mismatched cable segment, or an open/short circuit.

The reflected energy travels back toward the transmitter and can interfere with the outgoing signal, particularly problematic because Gigabit Ethernet transmits and receives simultaneously on all four pairs (hybrid echo cancellation assumes a well-behaved, matched line).

## Why *short* runs are actually a special case

You'd think short cables would have fewer problems, but they introduce a specific quirk:

- **Near-end reflections return faster.** On a short cable, a reflection from a poor connector or termination bounces back to the transceiver very quickly — sometimes fast enough to interfere with the transmitter's own echo-cancellation training window, which assumes signals return within expected timing bounds for a "normal" length link.
- **Insertion loss is minimal**, so reflected energy isn't attenuated much before it gets back to disturb the transceiver. On a long run, the same reflection would be weaker by the time it returns.
- **Return loss standards still apply** — TIA/EIA-568 specifies minimum return loss (a measure of how little energy reflects) even at short lengths, precisely because this is a known failure mode.

## Common causes in short runs

1. **Poorly seated or crimped RJ45 connectors** — the biggest offender. Untwisting pairs too far back from the connector breaks impedance matching right at the termination.
2. **Cheap or out-of-spec patch cables** — inconsistent conductor spacing/dielectric changes impedance along the cable.
3. **Cascaded couplers/jacks** — each coupler is itself a discontinuity; two short cables joined by a coupler is often worse than one continuous longer cable.
4. **Category mismatch** — mixing Cat5e components with Cat6/6A in the same short link.
5. **Sharp bends or crush points** — deform the geometry of the twisted pairs, changing local impedance.

## Practical symptoms

- Autonegotiation succeeding but link dropping to a lower speed than expected (e.g., negotiating 100 Mbps instead of 1 Gbps)
- Intermittent CRC errors or retransmissions despite a "good" cable tester pass on continuity alone
- Problems that a basic continuity tester won't catch — you need a TDR (time-domain reflectometer) or a proper certification tester (Fluke DSX series, etc.) that measures return loss, not just wire-map continuity

## Fixes

- Use factory-terminated patch cables rather than field-crimped ones for short jumpers when possible
- Minimize couplers/joints in short runs
- Keep the untwisted portion at the connector under ~13mm (0.5")
- Match cable category to your NIC/switch spec end-to-end
- If troubleshooting, a TDR can pinpoint the exact distance to the discontinuity

[DomieMic65]

Χρήστο αν δεν έχεις πάρει ήδη αυτός εδώ ο adopter (Ugreen 25051) είναι από τους καλούς και προτείνεται και σε φόρουμ ήχου λόγω του chipset που έχει!
Εγώ τα δύο rpi μου τα συνδέω μεταξύ τους με δύο τέτοιους και όχι από την θύρα Ethernet τους!
https://www.skroutz.gr/s/56611493/Ugree ... ernet.html

[Chris1967]

Μιχάλη (Domie) έχω παραγγείλει ένα όχι αυτό, δεν μου είπε κανείς από τους επαΐοντες ότι το τσιπάκι παίζει ρόλο.

Γενικά βλέπω ότι η τροφοδοσία παίζει πολύ ρόλο για δοκιμές που έβαλα το απλό πακάκι ο ήχος πήρε την κατιούσα εμφανώς.

[Tzimisce]

Στα πειράματα έγινε το εξής.
Με δύο Switch έγινε σύγκριση μεταξύ τους.
Βάλαμε πρώτα το ένα, μετά το άλλο και βρήκαμε ποιο είναι καλύτερο.
Όταν μπήκαν σε σειρά, το αποτέλεσμα ήταν κάτι ανάμεσα στα δύο. Καλύτερο μεν από το "κακό". χειρότερο όμως από το καλύτερο των δύο.
Το ίδιο ακριβώς αποτέλεσμα είχαμε και όταν μπήκε το Α πριν το πρώτο RPI και το Β ανάμεσά τους.

Στο τελικό δεν υπάρχει νόημα καν για καλώδιο. Τα δύο RPI θα συνδέονται εσωτερικά μεταξύ τους.
Δεν θα βγάζει δηλαδή RJ45 το ένα για να μπει βύσμα -> καλώδιο -> βύσμα -> στο RJ45 του άλλου.
Θα είναι συνδεδεμένα μεταξύ τους με το τυπωμένο ή απλά με καλώδια.

Btw το πιο τέλειο USB to Ethernet by default είναι χειρότερο από το κανονικό ethernet.
Καθαρά λόγω αρχιτεκτονικής, το USB κάνει polling κάθε 125μs ενώ το ethernet έχει δικό του PHY και δουλεύει όταν του έρχονται πακέτα.
Πρακτικά προσθέτεις ακόμη έναν controller στην περίπτωση του USB.

[DomieMic65]

Από ένα γρήγορο ΑΙ chat:

https://share.gemini.google/nzc7GNbyTNJD

Για αυτό κάποιοι ειδικά αν μιλάμε για αρχεία πάνω από 192KHz και DSD προτιμούν τους αντάπτορες και δη αυτούς που ανέφερα πιο πάνω, που δίνουν πολύ μεγαλύτερες ταχύτητες και δυνατότητα Jumbo frames με πιο εύκολη ρύθμιση του MTU.

[Dimdim]

Σωστές οι απαντήσεις του LLM, αλλά η ερώτηση δεν είναι η κατάλληλη.

Για τις δικές μας ανάγκες είναι πιο σημαντικό να έχουμε τον λιγότερο δυνατό θόρυβο στις ethernet γραμμές και στο RPi γενικότερα, παρά να έχουμε το μεγαλύτερο throughput ή το μικρότερο latency.