Actually, I had an incident yesterday which demonstrated the all-or-nothing aspect of USB interfaces. I have a USB cable that I'd been using for a test mike and, out of laziness, ran it from my laptop to my USB->spdif box, instead of putting the original USB cable back in. Guess what? I thought the box was broken since my laptop couldn't recognize it. As Step 1 in troubleshooting, I replaced it with the original USB cable and suddenly, everything worked perfectly again.
Personally I think there are better methods of determining bit perfect data delivery, maybe I am tooooo cynical with audiophile related products but this test seems to be a test to light a LED.....
One case comes to mind: backing up multi-gigabyte program files through USB on an external hard drive, reading them back in and see if the program still installs and runs correctly.
Never had any issues with that.
Jan
PS I just hope nobody is so dense as to remark 'but, but, we don't listen to programs'... Keeping my fingers crossed just to be sure.
Never had any issues with that.
Jan
PS I just hope nobody is so dense as to remark 'but, but, we don't listen to programs'... Keeping my fingers crossed just to be sure.
backups use a different method though and have retry. However I suspect if you monitor the number of retries it is VERY low. BER of USB is exceedingly low.
Anyway as I was going to say🙂
If we don't have gremlins to chase we could sit back relax and listen to our tunes... I believe it borders on Audio paranoia in some, especially when the claim is hearing differences in files that have been transferred via drop box (even though the bit pattern is identical)...
If we don't have gremlins to chase we could sit back relax and listen to our tunes... I believe it borders on Audio paranoia in some, especially when the claim is hearing differences in files that have been transferred via drop box (even though the bit pattern is identical)...
I have also considered Kippers Zoo friends (or sumthing like that) to be my go to guide on best******😛
don't forget 10 grand kids.........
On USB and basic cables, I did get involved in a bun fight where a USB interface on a board I had done did not work!!!!! so firstly it was my routing, then it was the cable, after many hours on network analysers and other means of looking at everything they found it was bit perfect from the USB device on the PCB down the cheap cable to the source... After many weeks of pain, insults and threats they discovered the cheap add on they was using did not work properly, cheap unit made in foreign shores and sold at a price to good to be true.... all consumer grade low end stuff so the cable must have been peanuts worked perfectly.....
But then we don't listen to programs do we🙂
But then we don't listen to programs do we🙂
I didn't which is why I knew you would understand 🙂
Like you I kick back and listen. I have a 3m USB cable from my microserver to a cheap USB-SPDIF converter recommended by SY. It works and I get great music. I can focus on important things and not worry.
USB isochronous mode has checksumming but no retries, like UDP.
USB bulk mode (for mass storage) has checksumming and retries, like TCP/IP.
HDDs on the other hand... well, let's just say that if you stuff a few TBs on platters, wait a few years, and re-read them, there's a good chance a few sectors will have gone to la-la-land.
That's why we have self-healing zfs/zraid, and backups.
Totally unrelated to audio, of course.
Sectors may go bad, but generally you can back up a file, leave the disk for years and you can recover the data. Unless you have some evidence to the contrary?
Yeah : fill 6TB zraid, launch zfs scrub, it reports and repairs a few errors. HDDs error rates are small, but not zero. Considering the amount of data, even a very low error rate becomes significant.
When did you last fail to get a file off a backup disk that was not a catastrophic HDD fail? Enterprise requirements and home systems are very different. For home use a raid is a waste. You need an off site backup and I still maintain a disk left alone on a shelf will not lose data.
Bit rot is a well known phenomenon, it just happens, nothing anyone can do about it, besides using checksumming and self-healing FS. Non-zero error rates multiplied by huge amounts of data simply make this unavoidable.
Bitrot and atomic COWs: Inside ?next-gen? filesystems | Ars Technica
> For home use a raid is a waste.
Seriously? With how cheap HDDs are, not using RAID these days is just... weird.
Bitrot and atomic COWs: Inside ?next-gen? filesystems | Ars Technica
> For home use a raid is a waste.
Seriously? With how cheap HDDs are, not using RAID these days is just... weird.
Most of us have had occasional weird behaviour from a computer. Most of these are due to faulty software, perhaps hitting a particular sequence of events which expose a bug. The rest are mainly due to data corruption, either in the RAM or on disc. It happens. If something is important, print it out and store it on paper.
I don't think so. Why would a bit or two of the wrong value cause a drop out? How would 100?
Not that bit perfect is all that difficult. I've tested it USB>SPDIF>USB with 2 sound cards and two computers. Not a single bit of the wrong value. Jitter is another matter.
Jan,
It's because it isn't about the numbers at all: the numbers can be recovered to bit-perfection, but if there is noise on the ground plane, noise on the power plane, noise produced within the DAC USB Receiver chip itself during bit definition, which affects the DAC (some also says the clock), then that's another thing to deal with.
People like Peter Stordiau (XXHighend, Phasure NOS1a) have measured some of things. John Swenson has observed/measure some if not all of it as well.
Ah, finally, someone other than barrows, myself and another member (borky) who gets it.
Lots of good stuff in the rest of your post, ecdesigns, so thanks for sharing.
Yes, we live in an analogue world, but if I write you a long integer in my analog handwriting you either read it as the exact same integer or you don't.
- Status
- Not open for further replies.