also here I had posted this my questions and ideas about usbaudio through 2.0 “TT” HUBs, without any comment:
(see asio4all 2.7 driver, where author notices usbaudio chips with 1in/2out design = c-media cm-108, cm-109) and it seems he solved this problem - I havent currently time to test, but will do ASAP)
--------------------------------
YES! YES! its exactly what I need too …, I am quite new to ntrack and I had currently know only that SONAR can do master clock for resampled recordings. Its beautifull to hear that master resampling works for you in nTrack !!!
Now I am almost sure to pay for it ASAP!
Because I want to try this scenario in future also on linux and I had more troubles with CM108 based usb audio adapters, I have posted this to linux.alsa.user group:
---------------
Sure, in fact I had similar idea to use more usb-audio adapters with HUBs and as I researched about bandwith issues, there is possibility to have USB 2.0 HUB which does “Transaction Translation” for every slave port. This feature namess exatly that: “Transaction Translator”, or shortened “TT”. But almost none of HUB vendors notice about its possibilities (sure, its defined by HUB chipset, but almost none have it in specs too, grrr) . I have found only one which is assured by specs to have TT on each port - so I bought 4 of them to test even daisy chaining, adapter unique identification (very strange, need to re-connect to the same ports everytime and before boot-up…), adapter initialization order on tree of HUBs and so on… If usb device contains unique serial ID, then “MAY BE” to have it identified in system permanently no matter of port where it is inserted, but it is VERY rare case… “TT” feature on USB20 hubs does “injection” of slower 1.1 devices (base or full speed) to HIGH speed streams of 2.0. Most USB hubs specs does not care about that, but if you have multi TT HUB, then this hopefully works simillary as network SWITCH (which also allows speed translation, as opposite to network HUBs, which are designed only for eighter 10 or 100 Mb…), …HOPEFULLY - I think, that I have not reached any limits there yet… In fact, I want to test realtime simultaneous recording from all usbaudio devices then routing all into mixing matrix with effect plugins (ntrack / jack, jamin, ardour) then sending monitors back to all usb outputs … Sure, adapters sync issue IS trouble, but I am curious WHY “jack” does not have builtin internal MASTER clock to which all unsynced inputs can be resampled !!! - OK, MOST Windows multitrack recorders does not solve this too, expecting single multitrack adapter or more this (profi class) adapters synced by SPDIF or so … - BUT, at least Cakewalk Sonar NEVER had this problem even with 2 DIFFERENT internal PCI cards while recording (Cakewalk uses lowlevel WDM exclusivelly - THIS is THE company that KNOWS HOW TO do low latency audio on windows without ASIO); BUT even SONAR does not solved CM108 based LIVE mode trouble described below…
HUBs I have in testing are this:
HP QuadTT USB2.0 HUB
I tested to record at 48kHz/16bit/MONO from six CM-108 based usb phones to Adobe Audition and some more multitrack recorders successfully; phones was connected to 2 HP QuadTT HUBs and each one was conneted to third one and this one to single USB 2.0 port on PC (everything was tested on Windows, for now).
Most of my testing was done in nTrack multitrack recorder(ntrack.com), latest versions, but there is one more BIG issue with CM108 based adapters - they have REALLY only MONO (single channel) input and STEREO (two channels) output which causes difficulties for ntrack in LIVE mode (routing inputs through effect plugins to outputs in realtime). Creative Live! External works, cards with SONIX SN11116F (as worse Hercules Muse Pocket LT) or quite good Phillips UDA1325H based Griffin iMic (which uniquelly has DUAL channel +20dB preamp, even not highend) too.
!!! ANY CM108 based adapter caused start of periodic clicking at frequency given by buffering setup) after activating LIVE mode. Still no progress here. I think that usbaudio.sys or nTrack even SONAR does not know how to deal with (this?) 1-in/2-out adapter…
Every my test on Windows was using usbaudio.sys class driver only. I dont know where is really unsolvable trouble, but I want to test this in Linux ALSA too (unfortunatelly, I still have no knowledge about it … grrrr - but currently I am trying to play with UBUNTU and it looks fine for first attempts, then I want to try GENTOO or some realtime multimedia distro, may be PlanetCCRMA for Fedora)
Another possible issue of usb audio streaming through HUBs may be added latencies with each HUB on the way or possible problems during VERY intensive ISOCHRONOUS transfers through them. May be that this is not so much tested scenario and many HUB chips cannot solve some uncommon situatuion well. And, sure that HUBs needs to be powered itself.
BUT, it seems that IT MUST BE POSSIBLE TO HAVE MULTITRACK DONE THIS WAY, somehow )
-------------------------
To Flavio :-):
I also vote for possibility to sync for one of used recording adapters too, as MASTER - and may be some more polished settings for this scenario. May be, that if Flavio can look at “single channel input” CM108 chip support, or workaround (may be that CHIP works bad, it is not itself intended for any music apps, but with proper analog design, it is simply quite usable, it is DAT format!). Next good thing to have embedded in nTrack may be OWN MIXER API tool, handling persistent identity of more USB adapters, allowing RENAMING them to nTrack usage and save/restore all controls with project 
(at codeproject.com, there is some C# example for legacy mixer api and managed directdound classes in DX9 may help too)
Anyway, thanks for nTrack!!!
Petr Antos
this fragment of asio4all manual sounds good too:
Multi-device-setups require that all the devices involved are running from the same clock source. You achieve this by daisy-chaining devices via S/PDIF etc. Fortunately, most USB devices will automatically syncronize themselves for as long as the host controllers they are connected to have a common clock which is trivially true for the USB host controllers embedded in the south bridge on any mainboard.
fine I have never tried to expect this, but it sounds pragmatic and thus I am currently much more believing, that my original idea isnt so bad …
have you any experiences 