Actually should the device fail to switch from fullspeed to highspeed, the effects may be like those reported. Checking the actual device speed in linux is with 'lsusb -t', no idea if it works on OSX too but you can try.
For last tests I did not use that cable - just straight commercial cables. Also, I tried with and without power added to via the isolator.
Yes, the whole ting is uncharted waters it seems. So many parameters...
I feel that it is strange that you get garbled analog audio - usually digital don't work like that.... its ,mote like on or off 😉
//
Yes, the whole ting is uncharted waters it seems. So many parameters...
I feel that it is strange that you get garbled analog audio - usually digital don't work like that.... its ,mote like on or off 😉
//
USB checks parity bit for each USB frame. If the frame is corrupted, it's dropped - causing missing data in the stream. I have had a few bad cables which caused currupted -> dropped packets. Since your device requests/sends packets every 125us (bInterval = 1), some dropped packets do not cause total loss of the stream, but an audible corruption.
Last edited:
Okey, so here comes the resolution of the case...
I just changed this one cable and everything works like a charm.
Thanks for the support and learning along the way!!
Here it is... never thought there could be such a difference with a USB cable... such low speed also... well, well...
Replaced by another no fancy black one from I don't know where....
Crazy....
//
- I had turned the isolator backwards... how could I... 🙂
- Yellow IKEA USB-A / USB-micro is no good.
I just changed this one cable and everything works like a charm.
Thanks for the support and learning along the way!!
Here it is... never thought there could be such a difference with a USB cable... such low speed also... well, well...
Replaced by another no fancy black one from I don't know where....
Crazy....
//