Jump to content

recur

Full Member
  • Content Count

    355
  • Joined

  • Last visited

Community Reputation

178 Good

About recur

  • Rank
    250+ Post Club
  • Birthday 03/07/1974

Profile Fields

  • Location
    Victoria
  • Country
    Australia

Recent Profile Visitors

1,163 profile views
  1. Looks like it may arrive next month. I’m looking forward to bedding it in with my recently acquired Manley Chinook phono pre.
  2. Not really. Nothing Occam's Razor couldn't have fixed first.
  3. Item: DR HDMI EDID Manager Price Range: Free to a good home. Just pay for my postage Item Condition: Used but never used Extra Info: If you've ever had to chase out EDID / HDMI handshaking issues on your system, you'll want to try out a Dr HDMI EDID manager. https://www.hdfury.com/product/dr-hdmi/
  4. You could always get something from the ProAudio aisle in the supermarket: https://reverb.com/au/item/31804237-universal-audio-dcs-remote-preamp?locale=en-AU That would look sexy on the desk with the VU meters and a hell of a lot more flexible than a standard hifi preamp. That said, my computer setup is all based around a 16 channel digital mixer with an outboard headphone amplifier, so I'm probably not chasing the simplicity many on here would be seeking.
  5. Most would love that jet plane rush in the house. I remember when a supervisor module for one of these was in excess of $120k aud. Not bad buying these days but there are more elegant solutions now. i’ve always been more partial to Arista personally. I used to work at Cisco in years gone by and have sold a mountain of it over the years, but the elegance of Arista’s switching platform is next level. i’ve spent a bunch of time at their labs and with people like Andy and Jayshree on a number of EBCs they hosted for us. Lincoln Dale (a local switching legend) was also working there before he moved to Google as a network architect and now AWS as a principal engineer. i really should ping Lincoln to put his 2c in this thread. He’s knowledgeable well past Ethernet and deep into the asic design on these beasts. I’m sure his perspective would be interesting to say the least.
  6. While amazingly sceptical, if that's the case, isolate the DAC using fibre like you can do on a Lumin X1 with an inbuilt SFP. Another physical layer problem that networking has already solved.
  7. Absolutely. Networking depends on being able to guarantee payload integrity from end to end. If it didn't work, you wouldn't / couldn't do internet banking on it. The real crux of matters is, networking was designed and iterated to death to fix real problems (latency, packet loss etc) and has evolved to be overwhelmingly awesome at creating a super high performance mechanism of sharing digital data precisely and optimally between two endpoints. The underlying protocols from the physical layer up the stack to the application layer all have their own performance optimisation and inherent fault checking mechanisms to make sure if something goes bad in transmission, that the bad bit of data gets sent again. Most of the physical layer issues in the analog audio world, are mitigated and even negated through cabling choices, link layer protocols, network layer protocols, transmission protocols and then an application that sits on top of it all which can elect to do it's own end to end payload verification. This means we've built a highly resilient transmission technology that abstracts away things like noise that are a problem in analog audio to something that is overcome with judicious use of many layers of technology mechanisms. We know that the payload that you get is bit perfect. If it's not, we get to see at multiple parts of the transmission stream where the error exists and depending on the identified location, you can then fix at your leisure (new cables, new physical interfaces, new computer... select your poison). TCP knows a bad packet has arrived due to checksums and will ask for a replacement if this happens. Best of all, we can see these statistics in real time on a proper, managed networking device or endpoint; networking engineers even got so smart to put alerts on these kinds of events using a whole other set of protocols like SNMP to "save our bacon" when things broke. We know we have ways of making some packets go faster than others (queuing is a well defined and used system to achieve this, borne firstly for time sensitive applications like voice and video). We also know we have ways of making things get distributed over the network faster or more optimally (see multicast for an example). There isn't a problem that the traditional issues in the audio realm (noise, interference etc) have that doesn't have a compensating control in the networking stack to ameliorate it. If there was, it would have been fixed for much more important time critical or data sensitive applications like high frequency trading, financial settlements, video distribution networks or the plethora of IoT centric devices like PLCs that make your food, make your electricity or filter your water supply. Audio is a long way down the list of essential services IP networking provides and offers no unique problems to solve that haven't already been solved for other purposes. Audiophiles are about as confused about networking as that kid with Beats headphones on his iPhone is with his Dad buying a $20k vinyl rig. I'd write a best practice guide for your audio network and device selection if I figured it would get read and not debated. It's not that hard. We've had the recipe for years.
  8. If you're really keen, I've read of people making their own XLR cables to match the turntable cartridge load impedance then doing the RIAA phono equalisation in software. Pretty much any audio interface for a PC from 2002 onwards would do this equalisation in software with a decent ADC stage. I've got an ageing Motu Ultralite on the shelf behind me that I'd drag out if I needed to do any mobile ADC work. Most of the time I just use my PreSonus StudioLive digital mixer if I need to digitise anything at home.
  9. I managed to squeeze it through Google Translate. They say it is a 100 Mbps "switching hub", which I'll say is probably an unmanaged switch. Networking might be complicated to the uninitiated, but there's no excuses for getting the terminology wrong if you're a manufacturer. I continue to love the furphy that abounds that a 100 Mbps port is better than a gigabit port because "noise". The big noise removal in the "switch" is apparently by getting rid of those LEDs that most switches have to let you know the thing at the other end of your cable is connected and turned on. Points loss for claiming LAN cables are directional, not knowing the difference between a hub and a switch and for thinking a better clock on the switch will make any difference to the IP traffic running above it.
  10. I think the name might be misleading. I've seen it advertised as both a hub and a switch interchangeably, although they are very different things in reality. It's hard to tell when the OEM website is predominantly all in Japanese. @Ittaku can you read the WsmartHub bit and translate for us? But yeah, not a router.
  11. John, I'm just a tad experienced in networking and have decades of experience delivering far more time sensitive and bandwidth heavy applications than audio. I've been involved in design and implementation of super low latency, high frequency trading networks here and in the US and also ran the team that delivered the biggest IP based video distribution network in this country. I also personally know people who design the switches that run our banking and internet industries and the IP backbones for companies like Google. Your assertions that you hear a difference because you spent money on something is understandable and I won't dispute it, but it doesn't make it anything other than anecdotal in nature.
  12. @rmpfyf I’ve lost interest in discussions about Ethernet, cables, switches and routers around here. Please leave me out. There are way too many people on here with a deep seated belief that spending excessive money on something that has been standardised and tested to death (Ethernet, tcp/IP) in much more high pressure environments (Eg HFT, content delivery networks etc) will yield a better audio outcome. Most don’t understand that the delivery of the audio stream is asynchronous to the underlying transport, that buffers handle most of the transmission issues comfortably. All I hear is anecdotal evidence and confirmation bias. Spend your money but I’d wager 100:1 that if the same money was spent on room treatment you’d get a much better outcome.
  13. Your matrix is a roon endpoint. You still need something to act as a roon server, be it a Mac pc, a NAS or a laptop. Install roon on a device that supports it, launch the roon app, go to settings / Audio and enable the matrix element M and you are off and running
  14. Start looking at pro audio brands like RME or Motu if you want decent but inexpensive ADCs. the RME ADI 2 Pro would be my go to if I didn’t already have multiple FireWire interfaces (Presonus StudioLive digital mixer, Motu Ultralite) laying around
  • Classifieds Statistics


    Currently Active Ads

    Total Sales (Since 2018)

    Total Sales Value (Last 14 Days)

    Total Ads Value (Since March 2020)
×
×
  • Create New...