USB to I2S receiver (WaveIO/Amanero etc)

Σωστή εγκατάσταση οδηγών για Amanero σε Foobar

H συζήτηση περιλαμβάνει αρκετές επιλογές, έχουμε δει λύσεις με CMedia, Xmos, Amanero, Wave κ.α

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

Πρόσφατα, μπορώ να πω ότι πέρασα ένα μικρό γολγοθά με την Amanero, εξαιτίας αλλαγής λειτουργικού συστήματος. Επηρεασμένος λίγο από το πως έβαζε τους asio οδηγούς η emu...εδώ τα βρήκα σκούρα γιατί ενώ κατά την εγκατάσταση (είτε σε WinXp είτε σε Win7) με τους τελευταίους οδηγούς (1.0.57) φαίνεται ότι περνά και asio οδηγούς, εντούτοις μέσα στο foobar (καθαρή εγκατάσταση) asio δεν ανέβαζε.
Αυτό είχε ως συνέπεια αφενός η δειγματοληψία να σταματά στους 192KHz, αφετέρου σε έλεγχο μέσω FFT και παλομγράφου τόσο το jitter όσο και το πως χρησιμοποιούσε τα εσωτερικά ρολόγια (amanero) να ήταν εντελώς λάθος!

Η σωστή λύση (για foobar) είναι αφενός να κατεβάσεις κα να περάσεις την 1.0.57 έκδοση, όπου περιλαμβάνει όλα τα λειτουργικά είτε 32 είτε 64bit, αφετέρου να κατεβάσεις asio ή kernel plugin για τα XP / asio ή wasapi για τα 7ρια.
Μετά από όλα αυτά η κάρτα θα λειτουργήσει σωστά τα εσωτερικά της ρολόγια και θα ανεβάσει την αναπαραγωγή μέχρι και τα 384 δίχως προβλήματα.

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

Αναπαραγωγή μέσω foobar σήματος 24/48 jitter [είτε σε περιβάλλον WinXP(32) είτε σε Win7(32)], μέτρηση πάνω στην amanero στο master clock, σύλληψη του συνολικού Jitter amanero+dac, από την έξοδο του DAC, έτσι όπως το "έπιασε" το ADC της EMU0404.

H μέτρηση του mclk έγινε δυστυχώς με παλμογράφο και προμπ 100MHz, τουλάχιστον χρησιμοποιήθηκε short gnd στο probe. Επειδή το σήμα μέτρησης είναι 22-24MHz κανονικά ήθελε 250άρη τουλάχιστον παλμογράφο για να συλληφθεί σωστά όλη η πληροφορία. Η καμπυλότητα που θα δείτε στα γραφήματα είναι λόγω περιορισμένου BW του παλμογράφου μου στο συγκεκριμένο σήμα.
Καλό θα ήταν η μέτρηση παλμογράφου να επαναλαμβανόταν από μέλος του φόρουμ με καταλληλότερο εξοπλισμό μεταξύ asio και wasapi οδηγών.

Εν κατακλείδι, τόσο στο jitter όσο και στη σύλληψη του παλμογράφου δεν παρουσιάζονται αξιοσημείωτες διαφορές που να θεωρηθούν σημαντικές για επιλογή μεταξύ των δύο οδηγών. Οι όποιες διαφορές στο mclk, κυρίως στον ρυθμό ανόδου (RT) ή καθόδου (FT), φαίνονται να είναι μέσα στο σφάλμα της μέτρησης.
 

Attachments

  • jitter winXP red asio black kernel.png
    jitter winXP red asio black kernel.png
    28.1 KB · Views: 266
  • wasapi win7 mclk.png
    wasapi win7 mclk.png
    15.6 KB · Views: 265
  • asio win7 mclk.png
    asio win7 mclk.png
    14.4 KB · Views: 264
  • kernel winXP mclk.png
    kernel winXP mclk.png
    14.6 KB · Views: 419
  • asio winXP mclk.png
    asio winXP mclk.png
    14.6 KB · Views: 264
  • jitter win7 red asio black wasapi.png
    jitter win7 red asio black wasapi.png
    27.9 KB · Views: 265
lemon , όντως το asio ή wasapi δεν επηρεάζει το jitter.
Το jitter είναι χαρακτηριστικό του hardware.
Αντίστοιχα και η αλλαγή player ή λειτουργικού συστήματος δεν επηρεάζει το jitter. (Εφόσον παίζουμε στην ιδία δειγματοληψία, ίδιες ρυθμίσεις dac)
Οι μετρήσεις είναι βεβαία πάντα απαραίτητες, και εδώ έρχεσαι να επιβεβαιώσεις κάτι που λέμε χρόνια.
Θυμάμαι πρώτος που έκανε αντίστοιχες μετρήσεις σε usb ήταν ο Gordon Ranking της wavelength audio. Εκείνη την εποχή πολλοι χομπιστες έκαναν το λάθος να συνδυάζουν το jitter με όποια αλλαγή προγράμματος / software player.

Παρόλα αυτά μη ξεχνάμε ότι οι κατασκευαστές audio interfaces, είτε PCI ή PCIe ή Firewire ή USB, μη ξεχνάμε ότι αναγράφουν στη συσκευασία του προϊόντος τους τα χαρακτηριστικά της κάρτας, ανεξάρτητα από το software player ή OS! Σκέψου σε τι κόλαση θα ζούσαμε εάν η μετρητική σου κάρτα έπαιζε διαφορετικά στο ARTA και στο FOOBAR κάτω από τις ίδιες συνθήκες δε θα ξέραμε τι να μετρήσουμε….
Και γενικά ASIO ή WASAPI σε win7, οτιδήποτε σε MacOS, οποιοδήποτε Linux, στο ίδιο pc, και εφόσον τα settings είναι ίδια , τότε η μέτρηση πρέπει να είναι και ίδια.
 
Απάντηση: Re: USB to I2S receiver (WaveIO/Amanero etc)

tmjuju (Τάσο), συγχώρα με δεν μου πάει καθόλου το στερεότυπο των κοινωνικών μέσων διαδικτύου, να αποκαλείς τον άλλον με το ψευδώνυμο ακόμη και εάν το γνωρίζεις προσωπικά. Μπορεί να δείχνει ότι δεν είναι "παρεϊστικο" το φόρουμ, αλλά ο ανθρώπινος παράγοντας είναι πάνω από όλα.

Τάσο λοιπόν, ότι γράφεις τα πίστευα μέχρι που άρχισα εδώ και χρόνια να ασχολούμαι με τη σύλληψη μέσω FFT και έχω αρχίσει να αναθεωρώ πολλές παγιωμένες αντιλήψεις οι οποίες αναπαράγονται δίχως να έχουν εξετασθεί εμπεριστατωμένα.
Ελάχιστοι από εμάς έχουμε εξοπλισμό να μετρήσουμε απευθείας το jitter. Παλιότερα θυμόμαστε όλοι τον Ντίνο (dinos) που είχε παρουσιάσει σύλληψη στον παλμογράφο της απεικόνισης του jitter και είχε κάνει και εξαγωγή σε psec.

Εάν μας βοηθούσε ο Ivo Mateljan (είναι ο δημιουργός του ARTA) και στην απεικόνιση του jitter, είχε έναν αλγόριθμο μέτρησης, θα μπορούσα να εξάγω συμπέρασμα εάν για το jitter το αίτιο είναι μόνο το hw.
Έχω τώρα μια επιφύλαξη εάν το αίτιο είναι μόνο το hw και όχι και το sw.

Δεν έχω να ανεβάσω αυτή τη στιγμή συλλήψεις απεικονισης Jitter του ίδιου ακριβώς hw με αυτό που έγραψα με λάθος εγκατάσταση οδηγών, αλλά εάν με εμπιστεύεσαι ότι δεν λέω αρλούμπες προς χάρην εντυπώσεων, η απεικόνιση Jitter δεν είχε καμία μα καμία σχέση με αυτές που βλέπεις στο προηγούμενο μήνυμα.

Το συζητούσα το θέμα - off the record - με τα μέλη Sokmav/Dalanik, το πως επηρρεάζονταν τα ίδια τα ρολόγια της amanero εν προκειμένω, από τη λάθος λειτουργία των οδηγών. Όποτε ήθελε χρησιμοποιούσε το ένα μόνο ρολόι των 22+MHz για να παίξει όλες τις δειγματοληψίες από τα 44-192 και όποτε ήθελε κάρφωνε στα 24+MHz, αυτό είχε σαν συνέπεια η απεικόνιση jitter που ήταν πάντα σήμα 24/48KHz να απεικονίζεται είτε σωστά αλλά με αυξημένο κατώφλι θορύβου (noise floor), είτε με αρκετές αιχμές αμφίπλευρες της κύριας συνιστώσας των 12KHz, αναλόγως ποιο ρολόι ήταν εκείνη τη στιγμή σε λειτουργία.

Θα μου πείς ότι δεν είναι καθαρά θέμα sw αλλά συνδιασμός...

Οπότε, ποιο είναι το συμπέρασμα από αυτό; Για μένα εάν αυτές οι παράπλευρες συνιστώσες της βασικής συχνότητας δεν είναι jitter αλλά ποιος ξέρει τι ... δεν έχω λόγο να το αμφισβητήσω. Εάν όμως αποδεχθούμε ότι η απεικόνιση μέτρησης jitter του ARTA, απεικονίζει τουλάχιστον το jitter ως λάθος χρονισμό με τις παράπλευρες ισόγχρονες αιχμές από την κύρια συνιστώσα των 12KHz, ναι ακόμη και το sw βάζει το χεράκι του...έστω και εάν το παράδειγμά μας ήταν κάπως κραυγαλέο από άποψη σωστής εγκατάστασης οδηγών.

Πιστεψέ με, δεν ήταν κάτι που ένα απλό μέλος θα το έπιανε γιατί έπαιζε μέχρι και 192KHz τα δείγματα, από εκεί και πάνω δεν έπαιζε τίποτα!

Προσωπικά το κατάλαβα μόνο μετρητικά - δεν είχα κάνει αξιοπρόσεκτη ακρόαση, απλά ότι λειτουργεί - όταν είδα τα περίεργα στην απεικόνιση jitter και παράλληλα έβλεπα στον παλμογράφο που τον είχα πάνω στο master ότι τα ρολόγια είχαν γίνει "κούκοι"! -bye-
 
Μανολη με χαρα θα βοηθουσα στην απεικονιση του παλμου αλλα με στοχο την μελετη της ποιοτητας του παλμου. Το jitter ει αι μια αλλη περιπτωση και οπαλμογραφος δεν ειναι το καταλληλο εργαλειο για το ειδος του jiter που μας ενδιαφερσι στο audio. Επισης η συζητηση sw hw ειναι μεγαλη και πληθωρα πραγματων μπορουνναπανε στραβα. Αν βρεις jitter απο κακους οδηγους ανεβασε το. Επισης ειναι ενδιφερον πως επιδρουν τα συστηματα εξοικονομησης ενεργειας ιδιαιτερα στα φορητα pc.
 
Επισης ειναι ενδιφερον πως επιδρουν τα συστηματα εξοικονομησης ενεργειας ιδιαιτερα στα φορητα pc.

Ντίνο,πολλά προβλήματα επίσης δημιουργεί η λειτουργία διαχείρισης ισχύος στις USB 3.
Καινούργιο πρωτόκολλο,καινούργια προβλήματα.

Προτείνεται συνήθως η απενεργοποίηση της διαχείρισης,όπως τόσο καιρό τώρα προτείνουμε την απενεργοποίηση της κατάστασης μειωμένης λειτουργίας ή εξοικονόμησης ενέργειας.
(Αν και υπάρχει σε κάθε σχέδιο η επιλογή να αφήσουμε απέξω τις USB θύρες. )
 
Last edited:
Ντίνο, θα ψάξω στα αρχεία του φορητού, του υπολογιστή που έχω στο εργαστήρι και σε κάμποσα στικάκια...γιατί το θέμα μου ανέκυψε σε μια προσπάθεια να αντικαταστήσω τα Win'XP Pro σε Win 7 Starter και πάλι τούμπαλιν λόγων προβλημάτων στο δίκτυο του σπιτιού...μέσα σε αυτό το χαμό, πήρα χαμπάρι το θέμα των οδηγών, την αδυναμία αναπαραγωγής άνω των 192 και την παράξενη συμπεριφορά τους στην απεικόνιση του jitter.

Στο θέμα του παλμού, είσαι από τα λίγα άτομα που όντως μπορούν να βοηθήσουν...
Δίχως να χαλάσεις την εγκατάσταση του λειτουργικού σου (νομίζω έχεις και amanero, πρέπει να θυμάμαι καλά), πέρνα την έκδοση 1.80 στο fw και κοίτα εάν μεταξύ asio, wasapi (event χρησιμοποίησα αλλά οπτικά δεν είδα διαφορά με το άλλο) έχεις διαφορές.
Σε XP (θαρρώ 64bit χρησιμοποιούσες) μεταξύ asio και kernel.
 
Τα XP μας τελείωσαν, και εάν δεν υπάρχει πολύ σοβαρός λόγος, καλύτερα να μην ασχοληθεί κανείς πια.
Πάντως συμφωνώ, ότι άλλο πράγμα το τελικό jitter που καταγράφει παραπάνω το ARTA και άλλο θέμα η απεικόνιση του παλμού. Ένα καλό ή κακό παλμό, η επόμενη διάταξη μπορεί να τον αναγνωρίζει καλώς, ή κακώς. Τελικά, η end-to-end μέτρηση στην έξοδο έχει πολλά θετικά :-)
Όσο για τα usb, στην CES είδαμε και τα πρώτα usb3.1 με νέα φίσα, σύντομα θα μας κάνει παρέα και για audio. Παρόλα αυτά οι κατασκευαστές motherboards ακόμα και στην εποχή του 3.1 φαίνεται να δίνουν φιλτραρισμένες usb 2 θύρες για audio http://www.anandtech.com/show/8868/msi-goes-usb-3-1-at-ces-2015-the-msi-component-suite-tour . Καθώς τα ηλεκτρικά παράσιτα είναι και αυτά μεγάλο μέρος του προβλήματος. Παρεμπιπτόντως ακόμα και σε asus amd mobo των 70 ευρώ βρήκα να έχει φιλτραρισμένες εξόδους.
 
Δηλαδή ακόμη δεν μάθαμε τι κάνει η usb3.0 και πάμε για 3.1?
Τάσο (tmjuju) μήπως έχει εξηγηθεί το είδος φιλτραρίσματος πάνω στην έξοδο usb; Ήταν φιλτράρισμα με πυκνωτές αποσύζευξης για παράδειγμα ή πραγματικό στάδιο απομόνωσης (isolation) για το επόμενο στάδιο (audio);
 
Re: Απάντηση: USB to I2S receiver (WaveIO/Amanero etc)

Δηλαδή ακόμη δεν μάθαμε τι κάνει η usb3.0 και πάμε για 3.1?
Τάσο (tmjuju) μήπως έχει εξηγηθεί το είδος φιλτραρίσματος πάνω στην έξοδο usb; Ήταν φιλτράρισμα με πυκνωτές αποσύζευξης για παράδειγμα ή πραγματικό στάδιο απομόνωσης (isolation) για το επόμενο στάδιο (audio);

H gigabyte δείχνει αυτό το slide http://www.gigabyte.com.gr/images/assets/en/features/4245.png
Με πυκνωτή πρέπει να είναι τα περισσότερα φίλτρα, άντε σε κάποιες ακριβές να έχουν και έξτρα σταθεροποίηση. Ενώ η gigabyte έχει και έξτρα ασφάλεια για κάθε θύρα που προστατεύεται.
Αντίστοιχα η asus ακόμα και σε mobo των 60euro έχει esd protection, για τις usb, είναι ολοκληρωμένο με 6 ποδαράκια δε ξέρω τι περισσότερο κάνει.
 
Εκανα και εγω καποιες μετρησεις πανω στο Ι2S
Mανολη εδω χρειαζομαι την εμπειρια σου για τις κυματομορφες που πηρα .
LRCK
BCK
και η εξοδος του DAC σαν να βλεπω την κυματατομορφη απο τροφοδοτικο του Νικου με το κουμπι στα 5mv πιανει 1-2 γραμμουλες. στην εξοδο εχω βαλει πυκνωτη 6,8 uf παραλληλα 150nf Siemens -1kΩ αντισταση σε σειρα και ενα 10nf ΜΚΤ προς την γη .
 

Attachments

  • IMGP0029.jpg
    IMGP0029.jpg
    114.6 KB · Views: 101
  • IMGP0030.jpg
    IMGP0030.jpg
    126.2 KB · Views: 101
  • IMGP0027.jpg
    IMGP0027.jpg
    148 KB · Views: 101
  • IMGP0031.jpg
    IMGP0031.jpg
    129.3 KB · Views: 101
  • IMGP0032.jpg
    IMGP0032.jpg
    149.4 KB · Views: 95
Last edited:
To LR Clock φαίνεται πολύ καθαρό και σωστό, το Bit Clock έχει άμβλυνση στο ανιόν κομμάτι του παλμού ενώ στο κατιόν είναι γρήγορο. Δεν μπορώ να το εξηγήσω εκτός και εάν είναι περιορισμός του παλμογράφου σου.
Νομίζω είχες πει ότι είναι 20άρης, τι συχνότητα έχει το Bit Clock σε αυτή τη μέτρηση;
Με 20ρη παλμογράφο μετράς καλά μέχρι και 2-3MHz παλμού εάν το probe και ο παλμογράφος είναι σωστά ρυθμισμένος.
Ο θόρυβος των 1-2mV (μάλλον με σήμα) είναι για demo Νικόλα...όλα ΟΚ. Είναι αυτό που είχες γράψει ότι βρήκες τη λύση;
Εάν ναι, πως προέκυψε η διόρθωση, βάση πειραματισμού ή βάση θεωρητικού;
 
20ρης ειναι Μανολη
Στο BCK το κουμπι του παλμογραφου ειναι τερμα δεν παει αλλο.
1-2mV (μάλλον με σήμα) Τι εννοεις με αυτο ?
Δεν εχω απαντησει ακομα για την διρθωση στην κυματομορφη του Dreflector γιατι δεν εχω βγαλει σαφη συμπερασματα,δεν εχω βαλει ακομα το RG179 2.5mm που πηρα .
Αυτη η κυματομορφη ειναι η εξοδος του DAC οχι του τροφοδοτικου ,
Εχω καταληξει περιπου στο εξης ,οτι τα καλωδια των sense δεν χρειαζεται να πηγαινουν πανω στην πλακετα του Dac .
 
Last edited:
Στο BCL το κόψιμο λόγω BW (εάν είναι αυτό) γίνεται αυτόματα από τον ίδιο τον παλμογράφο, κόβει το εύρος του παλμού οπότε μειώνει τα μέτωπα.

Για παράδειγμα ένας 100άρης ένα σήμα 12,2MHz θα το έδειχνε έτσι:

attachment.php


Ο ίδιος εάν μετρήσει ένα σήμα διπλάσιο 24,4 θα το "καμπυλώσει" κάπως έτσι

attachment.php


Ο ίδιος πάλι εάν μετρήσει ένα σήμα γύρω στα 45MHz το παρουσιάζει κάπως σαν ημιτονοειδή προς τριγωνική παρουσίαση παλμού.

Τα δείγματα που σου βάζω είναι τυχαία και δεν προέρχονται από την ίδια κάρτα, ως παράδειγμα τα έβαλα.

Φυσικά όμως ακόμη και με περιορισμό BW, μπορείς να έχεις μια βασική απεικόνιση των αλλαγών εάν είναι φυσικά εφανής οι διαφορές, για μικροδιαφορές θέλεις επαρκές BW από τον παλμογράφο. Εάν παίξεις με την καλωδίωση, μέτρα πάντα την αλλαγή στην απόληξη της καλωδίωσης εκεί που τερματίζει.

-> Μετρούσες δηλαδή το θόρυβο στην έξοδο του dac, δεν το έπιασα, νόμιζα ότι ήταν μέτρηση εξόδου από τροφοδοτικό και συνειρμικά πήγε το μυαλό μου στο θέμα που λέγαμε στο νήμα του Reflektor-D.
 
Σε ευχαριστω για τις επεξηγησεις με τις κυματομορφες .
Eκεινη την κυματομορφη που ειχα δειξει με το riple το επαιρνα πανω στην κλεμα του D-R . Bαζοντας jumperakia πανω στην κλεμα ( + και + sense ----- 0 και 0 sense) o θορυβος εφυγε .

1-2mV (μάλλον με σήμα) Τι εννοεις με αυτο ?
 
Στην περίπτωση που είχες μετρήσει τροφοδοτικό, όχι σε ηρεμία, αλλά με είσοδο σήματος στο κύκλωμα είναι άριστο! Αλλά κατόπιν εξήγησες ότι ήταν μετρούσες έξοδο του dac.