@AaronD my guess is that the USB plugs into the source (camcorder, to save space) and then you plug the RCA cables into your TV. Alot of the information on that Amazon listing seems "incorrect" but it's listed as USB to RCA, not RCA to USB.
That makes sense. Twisted sense, on the part of the manufacturers - for wrecking the idea that USB is trying to go for, that if something fits with their stuff, "it just works" - but still sense. Cheap connector, I guess, with no further consideration.
(USB itself is digital only. If you plug a dumb wiring adapter from something analog into an actual USB port, it won't work, and may even end up damaging something in some cases, if multiple things violate the spec at the same time, in common ways.)
Do you mean this switch? That is listed as 2in/1out or 1in/2out.
Yes. There's supposed to be an approval, but practically there's not. Anyone can sell anything, and it's up to the ignorant consumers to not buy the bad stuff despite it being cheap and "working". So it stays on the market.
See the teardown videos on YouTube, of counterfeit phone chargers, for a more spicy example. Those can kill you. Seriously.
What you're playing with here, doesn't carry that risk, but it's still not what the original engineers intended.
It just dawned on me that I can connect the Behringer and the IO Date cable to separate USB input ports on the desktop. Effectively, selecting the record device in OSB will be the switch.
Yes. You don't need a switch in that direction, hence the complete lack of standards-compliant ones.
Thanks. I don't really understand violating USB specs or what it means to connect USBs from the host only, with a controller or hub behind it.
USB is rigidly a single-master, multiple-slave system. Or, single-host, multiple-device, as USB calls it. Slaves/devices don't talk except to answer the master/host. No arbitration, because the single master/host controls everything.
Because of the complete absence of arbitration, it doesn't work to connect two masters/hosts together. They'll just talk when they want, over each other, and get nowhere. Maybe even damage something. Thus the prohibition on host-only to host-only cables.
Once upon a time, there were USB file transfer cables that appeared on the surface to do exactly that, but the way they would have had to work is to be a slave/device for each master/host, and then transfer data between the two internal slaves/devices. That's what the "bump" or box was for in the middle of the cord. They could not have been straight-through wiring adapters.
Anyway, the master/host controls everything, and the module that does that is called the host controller. A hub turns one port into several, and is also entirely controlled by the host. The entire tree has to fit within the data rate of a single port, because that's all the controller actually has. (If a controller itself has multiple independent ports, we call that multiple controllers, and they appear as such in the computer's Device Manager. So the logical structure still holds, even in that case.)
There's a sort of "contract" between host and device, and sometimes the device presents a choice of "contracts" for the host to pick from. One of the "clauses" in that "contract" is a certain update rate. That is, the host will ask periodically, at that rate, if that device has anything to send, and then give it the space to send it. If several of those "contracts" add up to more than what a single USB port can handle, as in the case of several video streams, we have a problem, even if you're not actually using all of them.
It's up to the device to say, "I don't have anything to send." The host is still required to ask. And it makes the device's firmware easier, to eliminate things that make it behave any differently at all. So it very well *could* spew out a video stream, even if you're not using it. Thus the recommendation to only have one video device physically attached to each host controller, regardless of hubs or ports.
There's also a sleep mode, but it's not always used while the host is running, and works almost the same as if you unplugged the sleeping device. So there's still the problem of the computer mishandling a hardware change, because it effectively *is* a hardware change. It's really designed to not drain the host's battery when the host is turned off, and doesn't have the circuitry to turn the ports' power off.
