Isochronous – Asynchronous usb και Spdif

[farflung]

Gain dither και EQ
που γράφει , όλα έχουν σαν αποτέλεσμα κάτι Non-bit-perfect

Ξαναλέω, κάνε ένα πείραμα και θα διαπιστώσεις ότι μπορούν να δώσουν bit-perfect < εάν το σετάρεις σωστά.

Από εκεί και περά φυσικά , έχεις τη δυνατότητα να παίξεις με ένα κάρο άλλα πράγματα.

Δεν είναι σωστό να κυνηγάμε μάγισσες – χωρίς λόγο

δεν διαφωνουμε σε κατι αυτο ακριβως λεω οτι ολα μπορουν να παιξουν bit perfect υπο προυποθεσεις,
γιατι ακουγονται διαφορετικα ομως?
Μηπως παιζει dsp στους πλαυερς και bit perf.παιζει μονο το foobar και του Πετραλια.

 

[farflung]

Re: Απάντηση: Re: Isochronous – Asynchronous usb και Spdif

καμια επεξεργασια σε redbook πχ.
το σημα ειναι bit perfect, ολο-ιδιο με το αρχικο.
ΜΕΤΡΗΜΕΝΟ ΑΠΟΔΕΔΕΙΓΜΕΝΟ.
τωρα για μετρησεις σφαλματων χρονισμου, υπαρχει δρομος ακομα...

δηλαδη για να καταλαβω υποστηριζεις οτι το δικο μου ντακ με του χ ψ αλλου που εχει αλλο ντακ κανει το ιδιο σφαλμα χρονισμου ,απ την στιγμη που και οι δυο εγω και ο αλλος υποστηριζουμε οτι ακουμε καλυτερα με το αμαρα?
δηλαδη με την ατοπο φτανουμε στο συμπερασμα οτι εγω και ο αλλος εχουμε το ιδιο ντακ.

 

[Sonus Naturalis]

Η συζήτηση με τις απόψεις των κατασκευαστών βρίσκεται εδώ:

Εμένα μου φαίνεται ότι και οι ίδιοι οι κατασκευαστές ψάχνονται και υπάρχει πολύς δρόμος ακόμα ώσπου να κατανοηθούν πλήρως οι αλληλεπιδράσεις. Μέχρι τότε θα λέει ο ένας το μακρύ του κι' ο άλλος το κοντό του. Η πιο λογική και η μόνη άλλωστε υπόθεση είναι τα σφάλματα στο χρονισμό. Ποιές απ' όλες τις εμπλεκόμενες διαδικασίες επιδρούν κι' ως ποιό βαθμό δεν είναι ακόμα επακριβώς γνωστό.

Εντυπωσιακή η δήλωση των κατασκευαστών του JPlay. Ο ήχος αλλάζει με διαφορετικό user interface ακόμα κι' όταν χρησιμοποιείται το ίδιο plug-in ως η κύρια μηχανή αναπαραγωγής!

Οι απόψεις πάντως των κατασκευαστών του Purw Music αξίζουν την προσοχή μας.

Παραθέτω όλη τη συζήτηση για διευκόλυνση.

---

---

What makes one media player sound different from another?

Jonathan Reichbach, President, Sonic Studio (Amarra)

Most can agree that each software application sounds different. Each has a different "fingerprint" with regards to how they interact with the hardware and software in the computer and how it sounds. For great sound we find that the quality of the audio processing for gain, dither, and EQ all contribute to a different sound. Another determining factor is how the data (music) is read from the disk drive and processed. As Amarra uses the dedicated SSE we are able to optimize every aspect to fine tune your sound. Apple's Core Audio is much more general purpose and this comes with certain tradeoffs that can effect sound quality.​

Damien Plisson, Founder, Audirvana, (Audirvana Plus)

The audio signal path can be very different, with different level of optimizations. Not all include full optimized path down to the kernel CoreAudio implementation itself. The computer activity synchronous to the audio signal needs to be tightly controlled, especially for the purity of the bass frequencies.​

Tim Murison, Co-Founder & CTO, BitPerfect Sound Inc., (BitPerfect)

If we're talking only bit perfect playback then I'd argue that the efficiency of getting music to the DAC is the main determinant of sound quality.​

Stephen F. Booth, Founder and Developer, sbooth.org, (Decibel)

I think that obvious variations in sound are due to differences in DSP applied by the player. For example, if software sample rate conversion is being performed the sound will be different based on which sample rate converter is being used and how it is configured. If digital volume is being used, the sound will be different based on how the gain is applied. For lossy file formats like MP3, smaller differences in sound can be caused by the type of decoder that is used. Each of these small differences adds up to a different sonic signature for each player.​

Jussi Laako, Owner, Signalyst, (HQ Player)

From my perspective, different processing (upsampling, dithering, etc) algorithms.There are also hardware dependent differences due to different software architectures of players. But this is less deterministic and smaller difference.
Another is digital volume control. Background noise of good quality DAC is so low that using digital volume control for adjusting volume within normal listening volume range is completely feasible. With DSD there are not even "bits to lose", DSD even works better when it's not pushed to the max.​

Josef Piri & Marcin Ostapowicz, JPlay (JPlay)

It would seem that almost everything can have an effect: for example, GUI. JPLAY plugins are available for JRiver, iTunes and foobar2000. In theory all these plugins should sound the same because the same JPLAY playback engine (which operates as completely isolated Windows service) is used. Yet, each plugin sounds different! GUI is just one example. There are many other factors like memory management, output method (direct sound, wasapi, asio or kernel streaming), buffering etc - all of which do not modify music bits in any way and yet have an effect on sound quality.​

Jim Hillegass, Founder and CEO, JRiver (JRiver Media Center)

The way it addresses the sound device may not be bitperfect. It may not be capable of upsampling or playing high sample rate files at their native bit depth.​

Dr. Rob Robinson, Director of Engineering, Channel D, (Pure Music)

This sort of question is impossible to answer without seeing the “innards” of all considered players, and comparing them. It is kind of like asking a question comparing high performance automobiles without taking a look under the hood. However, I can speak about the design of our products.I have discussed signal flow and streamlined algorithm design elsewhere, see for example the 2010 Advances In Computer Audio panel session video on the Rocky Mountain Audio Fest website and Jim Smith’s Get Better Sound website interview, among other places. There is no single or main factor or difference, it is a combination of many small things in the design, tied together in the implementation. On a high level, for example, the memory play feature that circumvents the need to access the music storage media / hard drive during music playback; the dithered volume control that reduces distortion caused by the word length reduction of a digital attenuator, and the upsampling feature which can deliver better performance. But these are comprised of many tiny pieces that must work together.
There are many ways of implementing a Memory Play feature, and we have probably tried all of them over the course of programming audio software on the Mac OS over the years. Circular buffer, double buffer; these easy to use and traditional techniques for handling streamed data have their place and are used in our other products. But we have diverged from the usual approach in Pure Music / Pure Vinyl and don’t use them, because a no-compromise music player allows an unconstrained choice of design approaches.
Then there are the not so concrete aspects of the design. This is part of our IP “sweat equity” that came about as a result of understanding best programming practices for smooth data throughput and instruction execution, developed over 27 years of experience writing software for the Apple Macintosh platform. This included writing driver level code to support custom hardware for specialized laboratory instrumentation.
Developing driver level code requires you to carefully contemplate the effect of small changes you might make. The timing of instruction execution and data transfers is critical. If you are designing a word processor or database application, those factors doesn’t matter much, if at all. But real-time processing such as audio playback is a different matter.
It’s a bit like designing a boat hull to carve through the water with the minimum of turbulence and drag. A small design change can cause an unexpected result (usually for the worse). Driver-level code has to run fast and smooth, and the same design principles apply to any real-time programming task such as audio player software. We want to create the minimum amount of “turbulence” (for example in the form of spikes in CPU usage) during the time when music is being played, parceling tasks to the CPU as smoothly as possible. As one example, computer power draw fluctuates with CPU usage, and these fluctuations can pollute power supply ground references, contributing to digital jitter (as I explained in the 2010 video referenced above). A steady-state, “non- turbulent” design circumvents this problem. Understanding driver design gives the insight needed for player software that uses the CPU and computer resources as smoothly and efficiently as possible.​

 

[VetNik]

Each has a different "fingerprint" with regards to how they interact with the hardware and software in the computer and how it sounds. For great sound we find that the quality of the audio processing for gain, dither, and EQ all contribute to a different sound
εγω δεν πηρα απαντηση
ολα αυτα ειναι γνωστα ,το ερωτημα παραμενει αφου ειναι bit περφεkt σημαινει οτι στο ντακ μας φτανουν 1000 ασσοι + 1000 μηδενικα σχηματικα μιλαω,απο τον ενα πλαιερ και τα ιδια και απ τον αλλον.
πως λοιπον μιλαει για fingerprint διαφορετικα,ο ψηφιακος κοσμος ειναι ανενδοτος σε τετοια θεματα,
αρα κατι αλλο παιζει που δεν μας το λενε γιατι δεν τους συμφερει,γιατι καταργει την εννοια του bit perfect,μαλλον κατι σε dsp.

συνομοσια ε?
μαλλον την πατησες...
αφου ειναι bit perfect ξεχνας τα dsp.
αυτο σημαινει bit perfect.
κανε μια προσπαθεια να καταλαβεις για τα σφαλματα χρονισμου. δυο τρανσπορτ μηχανικα που ταιζουν το ιδιο dac μεσω spdif ακουγονται ιδια? ιδια ψηφια δεν στελνουν?
Αν εχεις συγκεκριμενες απορροιες ρωτα.

 

[VetNik]

ναι μα, διαφορές από player σε player tmjuju δέχεσαι ότι υπάρχουν ?
Συγκεκριμένα από το foobar και το jriver. Και τα δύο με wasapi δηλαδή θεωρητικά bit perfect.
εμένα το jriver μου ακούγεται πιο ατμοσφαιρικό, με πιό σωστή 3d "απεικόνηση" της σκηνής, πιο ήσυχο άρα και λίγο πιο σκούρο.
Το foobar είναι πιο μπροστάρικο. Ακούγεται ακόμα πιο άμεσο, πιο βρώμικο και πιο φλατ από πλευράς χωροταξίας. Ο ήχος όμως κουδουνίζει πιό καθαρά στο σβήσιμο της εκάστοτε νότας.
Που οφείλεται η διαφορά?


edit: άσε δε που άμα ακούσεις και διαφορετική έκδοση του ίδιου προγράμματος και αυτό διαφορετικά θα ακούγεται κατά πάσα πιθανότητα

ωραιος.
αρα 2 bit perfect προγραμματα ακουγονται διαφορετικα.
εσυ με αυτα που διαβασες στο λινκ που εδωσα παραπανω, που πιστευεις οτι οφειλονται?

 

[VetNik]

Η συζήτηση με τις απόψεις των κατασκευαστών βρίσκεται εδώ:

Εμένα μου φαίνεται ότι και οι ίδιοι οι κατασκευαστές ψάχνονται και υπάρχει πολύς δρόμος ακόμα ώσπου να κατανοηθούν πλήρως οι αλληλεπιδράσεις. Μέχρι τότε θα λέει ο ένας το μακρύ του κι' ο άλλος το κοντό του. Η πιο λογική και η μόνη άλλωστε υπόθεση είναι τα σφάλματα στο χρονισμό. Ποιές απ' όλες τις εμπλεκόμενες διαδικασίες επιδρούν κι' ως ποιό βαθμό δεν είναι ακόμα επακριβώς γνωστό.

Εντυπωσιακή η δήλωση των κατασκευαστών του JPlay. Ο ήχος αλλάζει με διαφορετικό user interface ακόμα κι' όταν χρησιμοποιείται το ίδιο plug-in ως η κύρια μηχανή αναπαραγωγής!

Οι απόψεις πάντως των κατασκευαστών του Purw Music αξίζουν την προσοχή μας.

Παραθέτω όλη τη συζήτηση για διευκόλυνση.

---

---

Kαι το ποιο ενδιαφερον, απο τον ανθρωπο που εγραψε πρωτος ασυγχρονο κωδικα για usb!

Submitted by Wavelength on August 17, 2012 - 8:05am.
Gang,

Look I have been trying to figure this out for years. I have tested 3 of these apps in the following setup:

Computer<---USB--{USB Analyzer}-->USB->SPDIF===>Prism dScope.

Then off the USB->SPDIF converter I have an I2S analyzer.

So I have the following bit perfect transactions:

0) File dumped in standard PCM stereo format.

1) Timed USB Analyzer with buffers of PCM data.

2) Saved PCM from the Prism dScope III analyzer.

3) Saved PCM + TIme information from the I2S analyzer.

All three applications had the same results. This is a much better test than most bit perfect tests and they all passed the 1 minute song.

But again they all sounded different as does operating systems.

At this point I would rather look at more interesting testing and see what the differences could be.

Thanks

Gordon

 

[Panoramix]

Αμα ειχα καταλαβει δε θα ρωτουσα

 

[farflung]

συνομοσια ε?
μαλλον την πατησες...
αφου ειναι bit perfect ξεχνας τα dsp.
αυτο σημαινει bit perfect.
κανε μια προσπαθεια να καταλαβεις για τα σφαλματα χρονισμου. δυο τρανσπορτ μηχανικα που ταιζουν το ιδιο dac μεσω spdif ακουγονται ιδια? ιδια ψηφια δεν στελνουν?
Αν εχεις συγκεκριμενες απορροιες ρωτα.

ok μαλλον προς τα κει παει το παιχνιδι,δεν θα πω για το παραδειγμα του spdif γιατι εκει παρεμβαλεται κι αλλος ενας παιχτης που ειναι το καλωδιο,
ασ μεινουμε στα players και στο usb στριμαρισμα,εξηγησε μου το ντακ εχει το δικο του ρολοι,
το πλαιερ στελνει bit perfect σε πια φαση ακριβως χρονιζει το σημα αυτο ο πλαιερ σε σχεση με αλλον με τον αλγοριθμο του,και πως ξερει ο ταδε που εγραψε το προγραμμα τι καπνο φουμαρει το δικο μου ντακ ωστε να ταιριαξει.
αν κατι χανω διορθωσε με.

 

[VetNik]

ok μαλλον προς τα κει παει το παιχνιδι,δεν θα πω για το παραδειγμα του spdif γιατι εκει παρεμβαλεται κι αλλος ενας παιχτης που ειναι το καλωδιο,
ασ μεινουμε στα players και στο usb στριμαρισμα,εξηγησε μου το ντακ εχει το δικο του ρολοι,
το πλαιερ στελνει bit perfect σε πια φαση ακριβως χρονιζει το σημα αυτο ο πλαιερ σε σχεση με αλλον με τον αλγοριθμο του,και πως ξερει ο ταδε που εγραψε το προγραμμα τι καπνο φουμαρει το δικο μου ντακ ωστε να ταιριαξει.
αν κατι χανω διορθωσε με.

οκ σε ευχαριστω για την αναλυση, μαλλον καταλαβα τον προβληματισμο σου.
Ενα dac με ασυγχρονη usb συνδεση, τα δεδομενα τα ζηταει με βαση το ρολοι του μεσω της ασυγρχονης usb συνδεσης. ο κωδικας για αυτη την συνδεση ειναι συγκεκριμενος (wavelength, hiface και 2-3 αλλοι)
Η ακριβεια του ρολογιου και η ανεξαρτητοποιηση απο το λειτουργικο κανουν την συνδεση αυτη να ακουγεται παντα καλυτερα απο την απλη ισογχρονη usb.
Παρολα αυτα τα διαφορα software player ακουγονται διαφορετικα, παpολο που αποδεδειγμενα στελνουν το ιδιο ακριβως σε πληροφορια σημα.
Αυτο που φανηκε ειναι πως η αλληλεπιδραση του υπολογιστη με την usb και τον τροπο που αυτη ζηταει και παιρνει τα δεδομενα, εχει ακουστα αποτελεσματα. Ποιο μικρα μεν απο την διαφορα ισογχρονης με ασυγχρονη, ακουστα δε.
Η sonic studio βρηκε πως "παρακαμπτοντας" τις λειτουργιες AUDIO του λειτουργικου και κανοντας αυτη ολη την "βρωμικη" δουλεια εξασφαλιζει απροσκοπτη ροη δεδομενων στον χρονο που οριζει το ρολογακι του dac, με τις μικροτερες δυνατες διακυμανσεις.
Αυτα ολα ειναι "εικασιες" και ¨μισολογα" τα οποια ομως ακολουθησαν και αλλοι (πχ Audirvana) με αποτελεσμα την βελτιωση της αποδοσης των software player.
Αυτο τουλαχιστον "παραδεχονται…" με την εκφραση "signal path"
Damien Plisson, Founder, Audirvana, (Audirvana Plus)
The audio signal path can be very different, with different level of optimizations. Not all include full optimized path down to the kernel CoreAudio implementation itself. The computer activity synchronous to the audio signal needs to be tightly controlled, especially for the purity of the bass frequencies.

Ουσιαστικα, το software player αναλαμβανει τα παντα απο το διαβασμα απο τον σκληρο (πολλα palyer πλεον εχουν δικη τους μνημη/buffer/memory play klp) μεχρι τον χρονισμο με βαση το ρολογακι της usb του dac.
Εκει πλεον υπαρχει χώρος για διαφοροποιησεις, αναλογα με την βελτιστοποιηση.
Ελπιζω να σε καλυψα.

 

[VetNik]

ok μαλλον προς τα κει παει το παιχνιδι,δεν θα πω για το παραδειγμα του spdif γιατι εκει παρεμβαλεται κι αλλος ενας παιχτης που ειναι το καλωδιο,

να ρωτησω και εγω κατι,
πως το spdif καλωδιο κανει διαφορα?
(που κανει…)
δεν νομιζω να "κοβει" bit…

 

[ln()]

Γι' αυτό δες το συγκριτικό τεστ S/PDIF στο avmentor και τις μετρήσεις των καλωδίων.

 

[sokmav]

Απάντηση: Re: Isochronous – Asynchronous usb και Spdif

οκ σε ευχαριστω για την αναλυση, μαλλον καταλαβα τον προβληματισμο σου.
Ενα dac με ασυγχρονη usb συνδεση, τα δεδομενα τα ζηταει με βαση το ρολοι του μεσω της ασυγρχονης usb συνδεσης. ο κωδικας για αυτη την συνδεση ειναι συγκεκριμενος (wavelength, hiface και 2-3 αλλοι)
Η ακριβεια του ρολογιου και η ανεξαρτητοποιηση απο το λειτουργικο κανουν την συνδεση αυτη να ακουγεται παντα καλυτερα απο την απλη ισογχρονη usb.
Παρολα αυτα τα διαφορα software player ακουγονται διαφορετικα, παpολο που αποδεδειγμενα στελνουν το ιδιο ακριβως σε πληροφορια σημα.
Αυτο που φανηκε ειναι πως η αλληλεπιδραση του υπολογιστη με την usb και τον τροπο που αυτη ζηταει και παιρνει τα δεδομενα, εχει ακουστα αποτελεσματα. Ποιο μικρα μεν απο την διαφορα ισογχρονης με ασυγχρονη, ακουστα δε.
Η sonic studio βρηκε πως "παρακαμπτοντας" τις λειτουργιες AUDIO του λειτουργικου και κανοντας αυτη ολη την "βρωμικη" δουλεια εξασφαλιζει απροσκοπτη ροη δεδομενων στον χρονο που οριζει το ρολογακι του dac, με τις μικροτερες δυνατες διακυμανσεις.
Αυτα ολα ειναι "εικασιες" και ¨μισολογα" τα οποια ομως ακολουθησαν και αλλοι (πχ Audirvana) με αποτελεσμα την βελτιωση της αποδοσης των software player.
Αυτο τουλαχιστον "παραδεχονται…" με την εκφραση "signal path"
Damien Plisson, Founder, Audirvana, (Audirvana Plus)
The audio signal path can be very different, with different level of optimizations. Not all include full optimized path down to the kernel CoreAudio implementation itself. The computer activity synchronous to the audio signal needs to be tightly controlled, especially for the purity of the bass frequencies.

Ουσιαστικα, το software player αναλαμβανει τα παντα απο το διαβασμα απο τον σκληρο (πολλα palyer πλεον εχουν δικη τους μνημη/buffer/memory play klp) μεχρι τον χρονισμο με βαση το ρολογακι της usb του dac.
Εκει πλεον υπαρχει χώρος για διαφοροποιησεις, αναλογα με την βελτιστοποιηση.
Ελπιζω να σε καλυψα.

Εγώ αυτό που καταλαβαίνω σύμφωνα με το παραπάνω,είναι πως η διαφορά οφείλεται πιο πολύ στο ντακ,μιας και το κάθε ρολόι έχει τον δικό του τρόπο να ζητάει δεδομένα.
Κι έτσι είναι όντως εύλογο το ερώτημα αν οι προγραμματιστές λαμβάνουν υπόψιν όλα αυτά τα ντακ που κυκλοφορούν ώστε να προσαρμόσουν ανάλογα το softaware.
Αυτό βέβαια μπορεί να είναι και μια εξήγηση για τα τόσα και τόσα προβλήματα που συχνά αναφέρονται...
Δεν μας έφτανε δηλαδή να ματσάρουμε προ με τελικούς,τώρα θα ματσάρουμε players με dac's :flipout:

 

[VetNik]

Γι' αυτό δες το συγκριτικό τεστ S/PDIF στο avmentor και τις μετρήσεις των καλωδίων.

το εχω δει.
Ποιο ειναι το συμπερασμα?
εχει σχεση με το bit perfect?
Η με σφαλματα χρονισμου?
Ποια ειναι η διαφορα σε σχεση με μια usb συνδεση?
υπαρχει αλλο ενα εξαιρετικο τεστ για usb καλωδια στο hifi+

τελος να πω πως ολα τα παραπανω ειναι δικα μου συμπερασματα, χωρις να ειμαι καθολου ειδικος, το αντιθετο μαλιστα, ειμαι ημιμαθης, δεχομαι ολες τις αποψεις και προσπαθω να μαθω.
ολες οι αποψεις/παρατηρησεις δεκτες…

 

[VetNik]

Re: Απάντηση: Re: Isochronous – Asynchronous usb και Spdif

Εγώ αυτό που καταλαβαίνω σύμφωνα με το παραπάνω,είναι πως η διαφορά οφείλεται πιο πολύ στο ντακ,μιας και το κάθε ρολόι έχει τον δικό του τρόπο να ζητάει δεδομένα.
Κι έτσι είναι όντως εύλογο το ερώτημα αν οι προγραμματιστές λαμβάνουν υπόψιν όλα αυτά τα ντακ που κυκλοφορούν ώστε να προσαρμόσουν ανάλογα το softaware.
Αυτό βέβαια μπορεί να είναι και μια εξήγηση για τα τόσα και τόσα προβλήματα που συχνά αναφέρονται...
Δεν μας έφτανε δηλαδή να ματσάρουμε προ με τελικούς,τώρα θα ματσάρουμε players με dac's :flipout:

οχι.
το player "βλεπει" μονο το usb interface.
αυτο εχει συγκεκριμενο κωδικα, γραμμενο απο 2-3 εταιριες.
δεν το "νοιαζει" το player τι υπαρχει μετα…

 

[sokmav]

Απάντηση: Re: Απάντηση: Re: Isochronous – Asynchronous usb και Spdif

οχι.
το player "βλεπει" μονο το usb interface.
αυτο εχει συγκεκριμενο κωδικα, γραμμενο απο 2-3 εταιριες.
δεν το "νοιαζει" το player τι υπαρχει μετα…

Μα κι εγώ αυτό έλεγα μέχρι τώρα.
Από αυτό όμως:
"Η sonic studio βρηκε πως "παρακαμπτοντας" τις λειτουργιες AUDIO του λειτουργικου και κανοντας αυτη ολη την "βρωμικη" δουλεια εξασφαλιζει απροσκοπτη ροη δεδομενων στον χρονο που οριζει το ρολογακι του dac, με τις μικροτερες δυνατες διακυμανσεις."
τι βγαίνει;
Πως κάποια players ζορίζουν τα ρολόγια των ντακ με αποτέλεσμα αυτά να μην δουλεύουν σωστά.
Και πως το δικό του player αυτά τα εξαλείφει δουλεύοντας σωστά.(Ή μάλλον λιγότερο λάθος εφ' όσον δεν λέει "καθόλου",λέει "μικρές" διακυμάνσεις.)
Έτσι δεν είναι;

 

[VetNik]

Δεν ζοριζεται το ρολοι.
Το dac ζητάει με βάση το ρολοι του.
Το pc στέλνει.
Καμα φορα λέει περιμενε λίγο," παρτα τώρα."
Αυτο το " περιμενε λιγο " εξαλείφεται η γίνεται ελάχιστες φορες όταν το software είναι βελτιστοποιημένο.
Δεν μπορώ να το γράψω ποιο απλά.

 

[sokmav]

Απάντηση: Re: Isochronous – Asynchronous usb και Spdif

Δεν ζοριζεται το ρολοι.
Το dac ζητάει με βάση το ρολοι του.
Το pc στέλνει.
Καμα φορα λέει περιμενε λίγο," παρτα τώρα."
Αυτο το " περιμενε λιγο " εξαλείφεται η γίνεται ελάχιστες φορες όταν το software είναι βελτιστοποιημένο.
Δεν μπορώ να το γράψω ποιο απλά.

Οκ,το ίδιο λέμε,Για αυτό το "περίμενε" μιλάω κι εγώ.
Κι όταν λέω ζορίζεται αυτό εννοώ,πως περιμένει.
Πράγμα που είναι πολύ παράξενο,μιας και η επεξεργασία ενός αρχείου ήχου δεν είναι δα και άθλος.
Εαν ήταν έτσι,τι θα γινόταν με την αληθινή επεξεργασία σε πολυκάναλες κονσόλες με τα φίλτρα τους,κλπ;
Ή ακόμα χειρότερα τι θα γινόταν με την εικόνα (βίντεο,κλπ..) που ο όγκος της είναι τεράστιος σε σύγκριση;

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

(Δεν τα θέλω απλά,αυτά τα ξέρω,τα περίπλοκα θέλω,τα πολύ μέσα,να τα δω κομπιουτεράδικα που νογάω πιο πολύ.):ernaehrung004:

 

[farflung]

Δεν ζοριζεται το ρολοι.
Το dac ζητάει με βάση το ρολοι του.
Το pc στέλνει.
Καμα φορα λέει περιμενε λίγο," παρτα τώρα."
Αυτο το " περιμενε λιγο " εξαλείφεται η γίνεται ελάχιστες φορες όταν το software είναι βελτιστοποιημένο.
Δεν μπορώ να το γράψω ποιο απλά.

ok εισουν πολυ σαφης και ευχαριστω για τον κοπο σου να γραψεις ολο το κατεβατο αυτο.
εχω ομως ακομα κανα δυο ενδοιασμους.
ο πρωτος ειναι οτι παρακολουθω το αμαρα απ τα πρωτα βηματα του,
ειναι σαφες βεβαια οτι διαλεξε μια πλατφορμα πολυ πιο σωστη απ τα windows,και λιγοτερο χακευσιμη απο ανιδεους χρηστες.
πως εξηγεις οτι πανω κατω σε ολα τα updates μια μικρη διαφορα στον ηχο,
σε πολλα update εχει γραψει για sonic improvements,καθε φορα δηλαδη βελτιστοποιουν τον αλγοριθμο,(οκ στην ουσια αυτο λεω απ την αρχη οτι ειναι θεμα software και οχι παραφερναλιων).
εγω θα μου επιτρεψεις να πιστευω οτι αν και ειμουν υπερβολικος περι συνομωσιας κατι πειραζουν,
πεστο φιλτρα pre ringing κλπ ή οπως αλλιως θες πεστο.
επισης το αμαρα αν προσεξεις στο midi του μακ δεν περναει στο ντουκου το core audio σε αντιθεση με το audirvana sto direct mode,
και εχει και ρυθμιση sta options toy γιαυτο το θεμα το core audio δηλαδη.

 

[antonisgr]

ok εισουν πολυ σαφης και ευχαριστω για τον κοπο σου να γραψεις ολο το κατεβατο αυτο.
εχω ομως ακομα κανα δυο ενδοιασμους.
ο πρωτος ειναι οτι παρακολουθω το αμαρα απ τα πρωτα βηματα του,
ειναι σαφες βεβαια οτι διαλεξε μια πλατφορμα πολυ πιο σωστη απ τα windows,και λιγοτερο χακευσιμη απο ανιδεους χρηστες.
πως εξηγεις οτι πανω κατω σε ολα τα updates μια μικρη διαφορα στον ηχο,
σε πολλα update εχει γραψει για sonic improvements,καθε φορα δηλαδη βελτιστοποιουν τον αλγοριθμο,(οκ στην ουσια αυτο λεω απ την αρχη οτι ειναι θεμα software και οχι παραφερναλιων).
εγω θα μου επιτρεψεις να πιστευω οτι αν και ειμουν υπερβολικος περι συνομωσιας κατι πειραζουν,
πεστο φιλτρα pre ringing κλπ ή οπως αλλιως θες πεστο.
επισης το αμαρα αν προσεξεις στο midi του μακ δεν περναει στο ντουκου το core audio σε αντιθεση με το audirvana sto direct mode,
και εχει και ρυθμιση sta options toy γιαυτο το θεμα το core audio δηλαδη.

σωστή η παρατήρηση για ηχητικές διαφορές μεταξύ των εκδόσεων ,

 

[dinos]

Μια απόπειρα για ερμηνεία των όσων παραδόξων ακούμε νομίζω πως προέρχεται από τους αστάθμητους παράγοντες κατα τη λειτουργία του υπολογιστή. Έστω ότι έχουμε υπό εξέταση δύο διαφορετικούς software players με bit perfect έξοδο, στον ίδιο υπολογιστή, με το ίδιο DAC, ώστε να είναι δυνατή η εναλλαγή τους.
Τότε έχουμε δύο βασικά προβλήματα να αντιμετωπίσουμε.

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

Δεύτερο έστω ότι υπάρχει στατιστικά επιβεβαιωμένη διαφορά (πολύ πιθανό, κάνοντας καλό και στον διαγνωστικό εγωισμό μας). Κατά τη γνώμη μου πρέπει να σκεφτούμε πως ο κάθε player παρά το bit perfect που μας στέλνει, φορτίζει με αρκετά διαφορετικά καθήκοντα τον υπολογιστή π.χ χρήση μνήμης, δίσκων, CPU, χρήση interface και γραφικών (δείτε στο task manager πως αυξάνει η χρήση της CPU όταν ο Foobar είναι εμφανής στο desktop και όταν είναι minimized). Κανένας δεν εγγυάται πως η χρήση των πόρων του υπολογιστή θα είναι ίδια και με τους δυο players, ασχέτως αν δίνουν τα ίδια bit perfect δεδομένα. Και διαφορετική χρήση πόρων σημαίνει διαφορετική κατά περίπτωση, ενεργοποίηση ή/και απενεργοποίηση, των τοπικών τροφοδοσιών που παράγουν αθροιστικά αρκετό θόρυβο. Με τη σειρά του ο ηλεκτρικός αυτός θόρυβος (με αρμονικές συχνά ισχυρές και εντός του ακουστικού φάσματος) περνά στο DAC, παρέα με τα bit perfect δεδομένα (μέσω ανεπαρκών γειώσεων και τροφοδοσιών ή και επαγωγικά στις γραμμές των data) και αυτό με τη σειρά του έχει επίπτωση στο ρόλοι του DAC (jitter).
Θα μου πείτε υπάρχει και η γαλβανική απομόνωση. Σίγουρα είναι μια λύση αλλά δυστυχώς ακόμα δεν εφαρμόζεται πλήρως διότι δεν υπάρχουν έτοιμες αξιόπιστες λύσεις γαλβανικής απομόνωσης στο USB 2 High Speed και USB 3. Μέχρι τότε οι διαφορές (αν είναι ανιχνεύσιμες από του ακροατές) μπορούν αν αντιμετωπιστούν με προσεκτικό σχεδιασμό των κατά τόπους τροφοδοσιών του DAC, εφ’ όσο στις Motherboard των Η/Υ δεν μπορούμε να κάνουμε κάτι, πέρα από το να διαλέξουμε αυτές που είναι ...σχετικά ήσυχες. Φυσικά υπάρχουν και άλλα σχήματα απομόνωσης, κυρίως στο επίπεδο του I2S, αλλά επάγουν επίσης jitter.