Fair warning.
I have used USB sticks for a long time, and have come to the conclusion that all models over 2GB ( coincidentally the approximate size of addressable RAM in 32bit O.S.'s ), are doomed to fail within a few months of purchasing them.
I have 16 USB sticks and have noticed that the 4GB/8GB versions all fail to post after a few months.
I am not sure why. Even the name brand ones have the same issues.
I have an experiment to see if they can be reformatted to work on another O.S. and will report back.
But I have 12 x sticks 4GB and over and all of them have failed on my DAW's as well as my internet PC.
The 1GB & 2GB versions I have had for years and they work like a charm.
Also noticed that any stick under 1GB will cause Scope to restart.
I have no idea why these problems persisit, but I have lot's of experience w/ these sticks and when all 3 computers I use have the same exact problems I can safely assune that M$ has buggy USB issues still.
Noticing that the all USB only Mobo's seemed to have gone back to PS/2 ports only confirms my suspicions.
Why if mobo manufacturers notice this and change their design, that M$ can't release a fix or at least make mention of it on their site?
Surely my findings are not all coincidental.
USB Sticks & XP32
Re: USB Sticks & XP32
There are lots of cheap and nasty Chinese USB sticks floating around right now...I had a 32GB one and it sucked from day 1 (file corruptions and other weirdness). I sent it back and bought an OCZ Rally2 - this is a 32GB stick which works amazingly well, and faster than any other USB stick I've tried.
I guess you just have to be careful - I've heard of Corsair sticks being faked too. Fucking Chinese counterfeit scams can get really annoying and tedious
Maybe the west is reaping the rewards of the absurd consumerist culture.
I guess you just have to be careful - I've heard of Corsair sticks being faked too. Fucking Chinese counterfeit scams can get really annoying and tedious
Maybe the west is reaping the rewards of the absurd consumerist culture.Re: USB Sticks & XP32
I've only used the corsair flash voyagers so far, and they all perform error free since the day I bought them. one 1gb (really good), one 16gb (slower write performance than it should have, but no errors. sold it) and a 16gb GT, perfectly fine, too.
there's definitely no problem related to xp32 and capacity, from what I can tell. All the people that had problems with a stick typically owned some cheap line model or whatever wannabe brand, like msi or intenso who don't produce memory chips in the first place, but just re-label what they buy from hell knows where.
there's definitely no problem related to xp32 and capacity, from what I can tell. All the people that had problems with a stick typically owned some cheap line model or whatever wannabe brand, like msi or intenso who don't produce memory chips in the first place, but just re-label what they buy from hell knows where.
Re: USB Sticks & XP32
I tend to agree 100%.
I will buy 2 x 16GB OCZ Rally2's.
I found a thread I should have read long ago before going for these cheapo's.
Funny thing though the SuperTalent 16's which are both dead also, used the same chips but cheaper front end I/O.
OCZ RAM, and PSU I still use on an ancient DAW and they have been 100% stable.
I thought the USA was good at having goods fall apart after the warranty expired, but the Chinese definately have the 3 to 4 month warranty thing dialed in.
I still think XP32 has wierd USB issues though.
I am finding that I cannot take devices out of one port and sticking them into another, etc.
This happened on my mobo I/O's and even w/ the HUB I use.
Especially the Syncrosoft dongle, USB Sticks, and Plextor DVD.
KS-88's work like a charm.
I will buy 2 x 16GB OCZ Rally2's.
I found a thread I should have read long ago before going for these cheapo's.
Funny thing though the SuperTalent 16's which are both dead also, used the same chips but cheaper front end I/O.
OCZ RAM, and PSU I still use on an ancient DAW and they have been 100% stable.
I thought the USA was good at having goods fall apart after the warranty expired, but the Chinese definately have the 3 to 4 month warranty thing dialed in.
I still think XP32 has wierd USB issues though.
I am finding that I cannot take devices out of one port and sticking them into another, etc.
This happened on my mobo I/O's and even w/ the HUB I use.
Especially the Syncrosoft dongle, USB Sticks, and Plextor DVD.
KS-88's work like a charm.
Re: USB Sticks & XP32
This isn't just Xp32, Windows loads a driver from identifying the usb device when inserted (as of sp1 or sp2 Xp32 uses the 'class complaint' driver it associates with the USB device's ID read from the device's ROM at the point it's inserted). That means that the usb device in question is then bound to that usb port. OSX 10.3 and up (iirc) and Vista have better class complaint support by default, and have more transparent loading of drivers (because the driver for that 'class' is already present on the system). This does reduce the number of prompts to install drivers but you'll still see notifications...XITE-1/4LIVE wrote: I still think XP32 has wierd USB issues though.
I am finding that I cannot take devices out of one port and sticking them into another, etc.
This happened on my mobo I/O's and even w/ the HUB I use.
Especially the Syncrosoft dongle, USB Sticks, and Plextor DVD.
KS-88's work like a charm.
At least that's been my experience & understanding.
Last edited by valis on Fri Dec 26, 2008 1:37 am, edited 2 times in total.
Re: USB Sticks & XP32
I'm not sure this is related to class-compliant drivers - I think it's more with Windows' isistence on associating an installed driver with a USB *port* rather than a *device*. While most of the time you can reinstall the driver on a different port, with my Korg Padkontrol I could not get the driver to install on any port other than the one it was connected to when the driver was originally installed. These days when unplugging a device from a Windows machine, I make sure to make a note of which port it needs.
So did they fix this on Vista?
So did they fix this on Vista?
Re: USB Sticks & XP32
You are exactly right.
The hardware pop ups occur on all of these devices, and even carry on out to the USB Hub.
This is no biggie as I leave all but 2 ports static, and swap sticks and DVD's, etc. through those.
When I have to rely on a dongle to use certain VSTi's or Giga 4 for the gig it tends to make me nervous.
On my XITE-1 laptop config I will be using zero dongles.
Reaper and Kontackt only. These products are hassle free and slowly but surely appear to be the best options for my future use. I pray XITE-1 has no dongle. The external PCI-e connector should be sufficient I hope.
The hardware pop ups occur on all of these devices, and even carry on out to the USB Hub.
This is no biggie as I leave all but 2 ports static, and swap sticks and DVD's, etc. through those.
When I have to rely on a dongle to use certain VSTi's or Giga 4 for the gig it tends to make me nervous.
On my XITE-1 laptop config I will be using zero dongles.
Reaper and Kontackt only. These products are hassle free and slowly but surely appear to be the best options for my future use. I pray XITE-1 has no dongle. The external PCI-e connector should be sufficient I hope.
Re: USB Sticks & XP32
It's been a long week full of tons of snow & heavy food, I tried to clarify what I had typed above through editing, but I might still be a bit unclear there so I'll continue here...
From what I recall, USB 'key' storage devices (as part of the USB specification) don't have a specific file system by default, though they will come preformatted (usually Fat32 though encrypted keys often use NTFS or hfs+ with additional encryption layers). Still, below that file system the low level interface itself uses the SCSI command set for the actual addressing of the data, which is defined by the 'USB Mass Storage' class. To 'recognize' the device, the OS first needs to recognize it as part of that given class of devices (USB Mass Storage' class), then load the 'class compliant driver' that provides the virtual SCSI interface.
There was a time when many class complaint drivers weren't present by default, nor was the mechanism for 'discovery', so above when I mentioned OSX (as of a certain point) & Vista having good class complaint support 'by default', what I mean is on non-updated systems you'll experience support for a far wider range of hardware (ie, from initial point of install). Certainly over its lifespan
Xp32 has gained more classes (usually with service packs or those updated USB drivers you may have installed early in Xp's lifespan to 'enable' better USB functionality and timing.) Any 'fixes' on Vista would be changes in the class complaint drivers or the handling of USB classes themselves. I've got no knowledge here only my experience, which is that I see confirmation of inserting devices there as well (just like in a current up-to-date Xp install). In fact if you don't disable UAC and other such 'niceties' in Vista, I think there are actually more prompts now from what I recall?
Anyway, once the OS sees the virtual SCSI layer it can then read & write the device like any other HD. It's convenient to think of this as a sort of 'bootloader' but I believe it really functions by recognizing the device ID & class of the device itself on a given addressing path, so attaching the usb key device to another port shows up as a separate device because the path to device has changed. So it's my understanding that this is the reason it's bound to a specific port, it's much like having /dev/hd0/ before the file system path on *nix. Change that to /dev/hd1/ and it's not magically seen as the same thing to the system, although the file system layer on top can mask that through its own pathing once you've initialized the drive itself (like the first USB device you insert as always showing up as J: once 'loaded', due to that being the next drive letter free, or whatever).
Now all of the above was only intended to reply to Xite-1/4Live's question about USB 'memory' sticks used for data storage.
Your (darkrezin) experiences with the pad kontrol could be an issue specifically with that manufacturer's driver, or with the OS's midi stack (as addressed by RME's "10 Entry Limit" article). Out of everything I have here the ONLY devices I have those issues with are from Behringer (BCF2000) and M-audio (ancient 'midiman' USB midisport 4x4). I have other devices that do the same functions (Bitstream 3x midi controller, 2 Motu micro express midi interfaces) and they don't have issues with 'losing' the device on different ports or sometimes being unworking until unplugged/replugged. Which leads me to believe the driver issues with them are not the fault of Microsoft's host OS.
Looking beyond this to other devices opens up a lot of different issues. Many devices do not present a filesystem layer to the computer (like usb keys do). But if they do (iPod, camera or printer for example), there's a whole realm of issues since it's difficult to get the usb spec to share a filesystem with more than one 'user'. So the devices in question usually need to be switched into the proper mode on connection to the host computer. Again think iPods and cameras where you can't interact with the device once connected, and anyway this is totally ancillary to our musical context atm.
In the case of non-storage usb devices they'll either be part of a different class of drivers (like the HUI USB driver class) or require a driver installation if there is no class that fits (or the manufacturer didn't make their device 'class compliant' to any claass). It does seem as if there is some class of USB devices that don't require a driver for midi though. For exampleas my Novation Nocturn and my Akai MPD32 both work without any driver install (though Novation's "automap" software is required for the nocturn to actually do anything useful). But most of the midi devices I see will have a manufacturer provided driver, rather than one enabled by the device's "class".
So to deal with why USB devices are 'bound' to a specific port, you mix in typical driver issues with the fact that ALL devices in a modern x86 compatible machine are addressed through memory mapping. Ie, moving a PCI card to a new slot requires the driver installation because the addressing path changed and the PCI card is 'discovered' anew by the OS...the same applies to the USB controller spec.
Again because the path to address the device changes, that driver will need to be reloaded for each port the device is moved to. Though again for non-class complaint devices the process is closer to normal windows driver installation in the prompts presented to the user. The OS will see the device ID and be able to 'find' any existing drivers already present on the system, but at least in the XP & Vista systems I've used you're still prompted for allowing the driver to install. Some devices (like the novation nocturn I have here) do claim class compliant drivers and only needed the client software (for the 'automap') installed. Others, like my akai mpd32, only require confirmation of the driver loading on that port (class complaint drivers load and no other softwre required).
All of the USB hubs I've used work as a typical networking hub would, providing copper connections through to the host controller, so I'm not sure if there's a class of USB hubs that work as a networking 'switch' would (using a chip to steer each connection individually). So I can't comment on how hubs may complicate things, all of my complications here usually wind up being grounding issues more than anything (with all the midi cables and monitor cables with a 'monitor' based hub, etc).
Finally, I'm fairly sure I understand the virtual SCSI layer complications (with USB storage & other things I use) but I could be slightly wrong on the pathing issues presented when addressing storage devices & other devices. If anyone knows more/better (more betterer?) feel free to correct me.
From what I recall, USB 'key' storage devices (as part of the USB specification) don't have a specific file system by default, though they will come preformatted (usually Fat32 though encrypted keys often use NTFS or hfs+ with additional encryption layers). Still, below that file system the low level interface itself uses the SCSI command set for the actual addressing of the data, which is defined by the 'USB Mass Storage' class. To 'recognize' the device, the OS first needs to recognize it as part of that given class of devices (USB Mass Storage' class), then load the 'class compliant driver' that provides the virtual SCSI interface.
There was a time when many class complaint drivers weren't present by default, nor was the mechanism for 'discovery', so above when I mentioned OSX (as of a certain point) & Vista having good class complaint support 'by default', what I mean is on non-updated systems you'll experience support for a far wider range of hardware (ie, from initial point of install). Certainly over its lifespan
Xp32 has gained more classes (usually with service packs or those updated USB drivers you may have installed early in Xp's lifespan to 'enable' better USB functionality and timing.) Any 'fixes' on Vista would be changes in the class complaint drivers or the handling of USB classes themselves. I've got no knowledge here only my experience, which is that I see confirmation of inserting devices there as well (just like in a current up-to-date Xp install). In fact if you don't disable UAC and other such 'niceties' in Vista, I think there are actually more prompts now from what I recall?
Anyway, once the OS sees the virtual SCSI layer it can then read & write the device like any other HD. It's convenient to think of this as a sort of 'bootloader' but I believe it really functions by recognizing the device ID & class of the device itself on a given addressing path, so attaching the usb key device to another port shows up as a separate device because the path to device has changed. So it's my understanding that this is the reason it's bound to a specific port, it's much like having /dev/hd0/ before the file system path on *nix. Change that to /dev/hd1/ and it's not magically seen as the same thing to the system, although the file system layer on top can mask that through its own pathing once you've initialized the drive itself (like the first USB device you insert as always showing up as J: once 'loaded', due to that being the next drive letter free, or whatever).
Now all of the above was only intended to reply to Xite-1/4Live's question about USB 'memory' sticks used for data storage.
Your (darkrezin) experiences with the pad kontrol could be an issue specifically with that manufacturer's driver, or with the OS's midi stack (as addressed by RME's "10 Entry Limit" article). Out of everything I have here the ONLY devices I have those issues with are from Behringer (BCF2000) and M-audio (ancient 'midiman' USB midisport 4x4). I have other devices that do the same functions (Bitstream 3x midi controller, 2 Motu micro express midi interfaces) and they don't have issues with 'losing' the device on different ports or sometimes being unworking until unplugged/replugged. Which leads me to believe the driver issues with them are not the fault of Microsoft's host OS.
Looking beyond this to other devices opens up a lot of different issues. Many devices do not present a filesystem layer to the computer (like usb keys do). But if they do (iPod, camera or printer for example), there's a whole realm of issues since it's difficult to get the usb spec to share a filesystem with more than one 'user'. So the devices in question usually need to be switched into the proper mode on connection to the host computer. Again think iPods and cameras where you can't interact with the device once connected, and anyway this is totally ancillary to our musical context atm.
In the case of non-storage usb devices they'll either be part of a different class of drivers (like the HUI USB driver class) or require a driver installation if there is no class that fits (or the manufacturer didn't make their device 'class compliant' to any claass). It does seem as if there is some class of USB devices that don't require a driver for midi though. For exampleas my Novation Nocturn and my Akai MPD32 both work without any driver install (though Novation's "automap" software is required for the nocturn to actually do anything useful). But most of the midi devices I see will have a manufacturer provided driver, rather than one enabled by the device's "class".
So to deal with why USB devices are 'bound' to a specific port, you mix in typical driver issues with the fact that ALL devices in a modern x86 compatible machine are addressed through memory mapping. Ie, moving a PCI card to a new slot requires the driver installation because the addressing path changed and the PCI card is 'discovered' anew by the OS...the same applies to the USB controller spec.
Again because the path to address the device changes, that driver will need to be reloaded for each port the device is moved to. Though again for non-class complaint devices the process is closer to normal windows driver installation in the prompts presented to the user. The OS will see the device ID and be able to 'find' any existing drivers already present on the system, but at least in the XP & Vista systems I've used you're still prompted for allowing the driver to install. Some devices (like the novation nocturn I have here) do claim class compliant drivers and only needed the client software (for the 'automap') installed. Others, like my akai mpd32, only require confirmation of the driver loading on that port (class complaint drivers load and no other softwre required).
All of the USB hubs I've used work as a typical networking hub would, providing copper connections through to the host controller, so I'm not sure if there's a class of USB hubs that work as a networking 'switch' would (using a chip to steer each connection individually). So I can't comment on how hubs may complicate things, all of my complications here usually wind up being grounding issues more than anything (with all the midi cables and monitor cables with a 'monitor' based hub, etc).
Finally, I'm fairly sure I understand the virtual SCSI layer complications (with USB storage & other things I use) but I could be slightly wrong on the pathing issues presented when addressing storage devices & other devices. If anyone knows more/better (more betterer?) feel free to correct me.
Re: USB Sticks & XP32
Appreciate the long reply Valis, but I'm still convinced there's 2 separate issues here. Whenever I change the USB port for any device, be it the Padkontrol, a USB mass storage device or anything else, the familiar 'found new hardware' prompt comes up. To me this means that Windows needs to reinstall the driver for the new port. Sometimes you can click on 'automatic' and Windows will find the driver, but sometimes it doesn't happen. I'll see if I can verify this with a few devices when I have time. I should also add that I'm using SP1 but I haven't seen anything in SP2 that's different in this case. It's true that the Padkontrol driver could definitely have some issues on Windows, but this is a side-issue too - the main problem is that Windows asks for a driver when it's been installed already for a different port.
Re: USB Sticks & XP32
That must be lost somewhere in my verbose response above, there are several layers interacting. First is the issue of addressing the device itself, then there's the issue of what type of device it is and whether there's a common specification that can be used (class compliant device) with a generalized driver, or if the device needs a specific driver.
In my text above look for the PCI card comparison, or just understand that the USB ports on your board are 'seen' as different addresses to the cpu/OS/apps. If you plug something into a new address it requires the OS load the driver anew to be able to properly talk to the device at the new address. Yes, sometimes the device uses a 'class compliant' driver, which means the OS has a generalized driver that will work with that USB device. Other times the OS uses a driver specific to that manufacturer/device and that causes the additional step of having to confirm the driver is correct (if the OS finds it automatically) or present the proper location to find the driver to the OS.
Now some boards may use 2 physical 'ports' per onboard 'USB controller', which can confuse things even more. For instance one of my boards has 8 physical ports, but there are 6 USB controllers implemented in the 'south' bridge chip, and 6 'USB hub' devices seen off of this. This is because the 2 internal USB headers share copper with 2 of the back panel plugs. The internal headers are connected to a backplate in a blank PCI slot, moving a device from a shared slot above to it's companion slot there will cause no new driver prompt, but moving between 2 different slots will cause the prompt. Most motherboard makers don't document their boards well enough to determine what is shared easily, requiring trial & error to map this stuff out. Most people don't bother with that and rely on experience, which gives a mixed impression of what's going on.
Also what's different in Xp Sp2 isn't the mechanism through which drivers are loaded for USB devices, but the wider support for USB driver classes. So some devices that need manufacturer provided drivers in Xp sp1 may not need drivers to be manually located (ie, downloaded or loaded off of a provided disc) as an appropriate 'class complaint driver' will already be present. Again the example of HUI mode devices (keyboards, mice) and other USB 'classes' applies.
In my text above look for the PCI card comparison, or just understand that the USB ports on your board are 'seen' as different addresses to the cpu/OS/apps. If you plug something into a new address it requires the OS load the driver anew to be able to properly talk to the device at the new address. Yes, sometimes the device uses a 'class compliant' driver, which means the OS has a generalized driver that will work with that USB device. Other times the OS uses a driver specific to that manufacturer/device and that causes the additional step of having to confirm the driver is correct (if the OS finds it automatically) or present the proper location to find the driver to the OS.
Now some boards may use 2 physical 'ports' per onboard 'USB controller', which can confuse things even more. For instance one of my boards has 8 physical ports, but there are 6 USB controllers implemented in the 'south' bridge chip, and 6 'USB hub' devices seen off of this. This is because the 2 internal USB headers share copper with 2 of the back panel plugs. The internal headers are connected to a backplate in a blank PCI slot, moving a device from a shared slot above to it's companion slot there will cause no new driver prompt, but moving between 2 different slots will cause the prompt. Most motherboard makers don't document their boards well enough to determine what is shared easily, requiring trial & error to map this stuff out. Most people don't bother with that and rely on experience, which gives a mixed impression of what's going on.
Also what's different in Xp Sp2 isn't the mechanism through which drivers are loaded for USB devices, but the wider support for USB driver classes. So some devices that need manufacturer provided drivers in Xp sp1 may not need drivers to be manually located (ie, downloaded or loaded off of a provided disc) as an appropriate 'class complaint driver' will already be present. Again the example of HUI mode devices (keyboards, mice) and other USB 'classes' applies.
Re: USB Sticks & XP32
Thanks for the clarification Valis, it makes sense. When you put a PCI card in a different slot it's not such a big deal because it's not something you do every day. But with USB ports its just so impractical and annoying. I really don't think it can be that hard to set up some kind of driver pool for the USB slots and identify them with USB devices according to whatever info they have in their ROMs, so that when you put them in different ports they are intelligently recognised. It's quite amusing to play around with hackintoshes a bit and see just how much better it's possible to manage exactly the same hardware resources.
Re: USB Sticks & XP32
Well the underlying technology is the same of course, the difference is how transparently OSX deals with drivers then 
Anyway sorry for being so long winded, I think I've got a bit of cabin fever from the all the snow we've had.
Anyway sorry for being so long winded, I think I've got a bit of cabin fever from the all the snow we've had.
Re: USB Sticks & XP32
I have a couple of 4GB ones i never had trouble with. one of them was free at siggraph.
the 2gb limitation is for filesize not drive size, i mean a drive can be 1.2 TB and no problem.
i noticed that with XP32sp3 it doesnt keep re-detecting stuff all the time when you use a different port. i had plugged my monome in to a hub instead of the usual port by mistake and it didnt even pop up the found new hardware thing(and it is not class compliant). just worked.
the 2gb limitation is for filesize not drive size, i mean a drive can be 1.2 TB and no problem.
i noticed that with XP32sp3 it doesnt keep re-detecting stuff all the time when you use a different port. i had plugged my monome in to a hub instead of the usual port by mistake and it didnt even pop up the found new hardware thing(and it is not class compliant). just worked.
Re: USB Sticks & XP32
I use a Buffalo RUF2-R8GS as my standard workhorse-carry-around-stick
copies about a Gb in a minute to the stick, flawless for a year or so... great device
(obviously Buffalo doesn't supply them to US market currently due to a lawsuit pending by Sandisk)
cheers, Tom
copies about a Gb in a minute to the stick, flawless for a year or so... great device
(obviously Buffalo doesn't supply them to US market currently due to a lawsuit pending by Sandisk)
cheers, Tom
Re: USB Sticks & XP32
the picture in that post looks pretty OCD, what with all those nice collections and stacks...XITE-1/4LIVE wrote:Fair warning.
I have used USB sticks for a long time.....................................................................Surely my findings are not all coincidental.
Re: USB Sticks & XP32
cdcdcdcdcdcdcd
lighterlighter
sharpeesharpeesharpeesharpee...
stickstickstick
it takes one to know one....
hey, stardust! nice goatse!
lighterlighter
sharpeesharpeesharpeesharpee...
stickstickstick
it takes one to know one....hey, stardust! nice goatse!
Re: USB Sticks & XP32
well, this IS the internet.
did you change it?
did you change it?
Re: USB Sticks & XP32
whats that leather keychain usb stick. is it one of the ones which died?