Your irrelevance to the discussion continues to inexpicably decline. Quit while you are behind….you remain off-topic.
Ethernet opinions
Hello everyone, I finally got my system setup. I had a few setbacks the past few months. My mom had lung cancer and passed away a month ago. It has been a journey getting my system set up which is part of the fun. I am running Pass Labs XP-12, pass 250.8, and Bricasti M3. My original plan was to run the Bricasti with a EERO mesh network since the modem is on the opposite end of the listening space. Needless to say the EERO mesh would not work and Roon could not see my M3. I was on the phone with Bricasti trouble shooting the issue. I removed my M3 from the system and double checked everything with it hard wired to the modem which worked. I was told I could really use any Ethernet for the most part as long as it’s cat 5 or 6. Well, I returned the EERO and got a 25 foot Ethernet cable from Best Buy for 10 dollars. The sound is much better then I was guessing running a 10 dollar cable, for me it’s deff a temp fix. Especially since I bought two audio quest vodka cables. I am using one of them now connecting the room nucleus to the modem at the moment. I have read a bit about blue Jean cables which seem to hold spec. I don’t see me buying a longer Audio quest vodka cable given the cost. In some ways I feel like I spent more then I should have on the Vodka cables at this point. Opinions please ?
- ...
- 131 posts total
@ghasley you are wrong. You started out saying no caching, and when to everyone caches! So you learned something. That's a win. |
@fredrik222 I don’t recall saying anything about “no cacheing”…you’ve still yet to point to where I called you a name. Your continuous, irrelevant posts are really cute though… |
Caching streamers save the track to cache, whether that is ram only (ie, innuous pulse mini uses 2gb Ram for this when playing from a service, or a streamer that uses a local drive for caching, ie, an ssd or a card to save the cached track to “offline content” which is configured in the app. Where there is no local storage for the app, qobuzz/tidal to use, you cannot save the cached stream long term as offline content. Where there IS local storage (playing on phone or ipad, uses that device’s storage for “offline content”), of whatever type, to use, there is a setting to save streamed content locally as offline content. That content is exclusive to the app. Or you can just download tracks as files that can be played through the streamer itself then through the dac. So a service such as tidal/qobuzz can do one of three things, caching to ram, saving cached to ram track out to disk as offline content, OR saving a downloaded file out to generic storage where any app that can read the format can use it. (For example stuff downloaded from, ie hdtracks.. I have yet to try the qobuzz download to see if those are only allowed to be played by qobuzz app) The error checking for “streaming” happens against the incoming data that assembles into the track in cache. If there are too many errors, the track “buffers”, ie the system requests that portion of the track that failed error correction, to be re-sent and wats for an error free response. If that happens with too many parts of the track, or there is a continuous, short term, issue with the connection, the entire track is requested to be sent again. This is evident on an unstable internet connection when requesting a service’s app to play a track. The download will start, and possibly start to play, then the bar showing the track’s progression will start again, playin the track either a few seconds for a few attempts, then it will start from the beginning, lr it just resets and tries to re-transmit the entire track. If the track is not able to be completely cached, error free, after a set number of tries, the app will end its attempts to play that track. If you have another track request queued, the app gives up on the first and moves on to the next queued track, else it just stops attempting to play anything. Enough with arguing jargon already, please. Whatever the precise terms are, this is what I observe in real life as a rural customer with crappy internet. Whether you want to refer to the saved tracks in the “offline content” for the app as “saved stream”, “saved cache” or “downloaded” doesn’t matter to me. Purchased and downloaded tracks serve me better for hires tracks, since I can get an entire file, and use with any playback system that can read flac, eventually, without the streaming app deciding there have been too many failed attempts and quitting on the track. Successful streaming for me is usually limited to cd quality, except on days when even that is failing. ALL Streamers “cache” or buffer each “streaming content” object and perform error checking on the incoming packets. Period. What they do with that successfully received track in buffer or cache, and the process for error check fails, is a function of the service and what configs you set/can set, for the hardware running the interface to the service. Downloaded tracks don’t buffer or cache as they are not “streaming content” but whole files and are not, usually, tied to a specific service to be able to play back and have a more robust, seemingly, process for getting a whole, error free, file. |
Once you sort out the 25 FT long LAN cable quandary, read up on posts by @audphile1, @grannyring and few others who are using Network Acoustics Muon Pro Kit for next level improvements with your network. There are many other tweaks that provides ethernet noise filtering but none can quite match the performance upgrade from both ENO and Muon passive filtering kits. And they come with 30 days no questions asked money back guarantee.
|
- 131 posts total