Jump to content

barrows

  • Content Count

    5549
  • Joined

  • Last visited

7 Followers

About barrows

  • Rank
    Senior Member

Personal Information

  • Location
    High above Boulder

Recent Profile Visitors

12823 profile views
  1. Indeed! I just wanted anyone reading here to be absolutely clear I was not referring to Sonore's systemOptique products.
  2. To be clear, the above quote was from 2016, well before development of the opticalRendu, and is out of context when referring to these new products from Sonore.
  3. Of course all parts add distortion, at some level. My question was concerning whether that test was done using the capacitors in series or parallel... I think most audiophiles already believe (understand) that in filter circuits polypropylene dielectric is better (and polystyrene better still, and teflon, maybe better still), and that foil caps are generally considered better than metalized (although advancements in metaled caps make that questionable these days). Also, these dielectric differences depend on what frequencies things are operating at as well... In Class D filter design, the size of the cap and its loop area may trump all other concerns for the performance of the amplifier as a whole. Mr. Putzeys has mentioned many times that he pays extreme attention to loop areas. Using large size capacitors in the output filter design of a class D amp is a no no...
  4. Is that for series or parallel connections? Of course in Mr. Putzeys' designs distortion of the output filter is inside the feedback loop and would be corrected...
  5. Go Chris go! I must admit I have a bit of speaker envy right now, as I know whatever you decide, you are gong to get something awesome.
  6. Remember to give it a little time to sound its best! The clock performance matters, and clocks need at least 24 hours of being powered up to stabilize (some suggest they even need 7 days to get to their best...) Although, I would expect folks to hear improvements over the microRendu and ultraRendu after an hour warm up or so... More better will come later in addition.
  7. I would also add parts inventory costs: the better parts one specs in their product, the higher the costs are of keeping those parts in stock, this ties up capitol, and for many companies requires operating on loans, so debt management and interest payments becomes another hidden cost. This why, even in very very, very expensive products, you often do not see the very best parts (like bulk foil resistors, for example).
  8. Yes, or: Server (could be a computer or NAS)-Router (could be + switch, or not)-Renderer-USB (really could also be I2S/SPDIF)-DAC. Just to be more clear. My system is: Server-CAT 6A-Router-CAT 6A-FMC-OM3-Signature Rendu optical-USB-DAC, but as far as I am concerned, generally, any Ethernet based audio distribution playing locally stored files, like one might have a DAC with direct Ethernet input as well (meaning an internal Renderer).
  9. "We are talking about streaming here... not playing a local file where you can ensure every bit is perfect. Streaming is real-time processing. In real-time processing latency on the input affects the output." Oh, I am sorry, I am not referring to streaming from the Internet, that would be another topic for me-I only play locally stored files. Although compromises involved in Internet based music file playback would be an interesting topic. One problem with the semantics here is that some people use the term "streaming" to refer to any playback delivery via a Networked set up, and others refer to "streaming" as Internet based playback from sources like Tidal/Qobuz... I have no knowledge of how Internet streams operate, are you suggesting that those streams really are real time operations? For example, USB audio is not really a real time operation, while there is no error correction, the USB receiving device tells the sender to speed up or slow down the flow of packets to keep the buffer from underpins or overflows. Locally stored files are not streamed in real time either. Are you suggesting that the Ethernet timing variances (packet jitter) only effect the sonics of playback of Internet based playback?
  10. That is just not correct. As long as the data received by USB is accurate, it is timed as perfectly as the design of the DAC and the local oscillator(s) allow. Unless, again, when you say "the stream it generates is not perfect" that you are saying the actual data values are corrupted somehow.
  11. I am not saying that I have not heard the improvement when the clock in the Renderer is upgraded to a Femto level part, quite to the contrary-I have certainly heard the difference. The point of this discussion is to try and determine what mechanism is responsible for this difference. And, subsequently, to to discuss whether, or not, improving clocks further upstream will make a difference as well. John Swenson appears to have suggested (I could not quite follow his explanation precisely) that it is the phase noise of the clock which may be causing some sonic degradation, and he is hard at work trying to figure out a way to confirm this through measurement. So far, there is no solid explanation yet. My point here is to suggest that timing issues of Ethernet data cannot be the problem directly, as these have no influence on DAC timing in a direct sense. To me, so far, it all has to come back to noise-maybe there is something about Ethernet that produces more noise when we have some packet jitter, and this noise gets to the DAC, and then causes issues.
  12. OM-1 LC-LC is the standard, recommended fiber cable. Any other options would be considered experimental.
  13. OK, so let's say there is no data loss then. There is a variance in the timing between packets. This is a timing problem then, but, as I mentioned before, there is no mechanism for this timing problem to matter to the DAC. The DAC only cares about two things: that the samples are accurate, and that they timed accurately (let's ignore power supply noise for this). The samples are accurate (no data loss), and the timing is only determined by the DAC clock, so there is no problem? Again, the timing of the packets has no bearing on the DAC, the DAC only cares about its own local clock's accuracy.
  14. This speculation sounds like you are talking about a loss of data, as there is no timing information here relevant to audio playback, the only possible thing is data loss. But, if there was data loss, it would audible as either an actual dropout, or a small "tic" sound, as USB audio has no mechanism which corrects for data loss-there is no "interpretive" aspect to USB audio. Those familiar with early days of USB audio, before async, will be familiar with these types of problems. This type of data loss would not result in a general type of audio degradation (say, less 'air" or "presence" or any other general audio quality description), it would only result in a dropout or 'tic" sound. Additionally, if this is actually something which happens, I suspect the ramifications for audio production would be extreme.
×
×
  • Create New...