Xite with Usb connector
Xite with Usb connector
Any chance to make Xite work with a USB connector? I want to go to a mini pc and i can't find any with express card. A USB connector would be very convinient.
Is there any express card to USB adapter?
Is there any express card to USB adapter?
Re: Xite with Usb connector
I know that currently doesn't work but is there any chance soniccore to consider it? Is it very difficult to implement from the hardware side? I think the bandwidth of USB 3 is adaquate, it is right? Or is it usb 3.1? Does anyone else has interest in such a scheme? Doesn't a USB will make xite compatible with a lot more pcs?
It would be great to have Xite with a fanless mini pc running reaper with dual monitors. I don't need anything else as i have moved full analogue and i just need the xite with a daw. I don't run any vst besides my analyzers. I need xite because i am used to it and i don't want to change my workaround... I seek to make a completely silent daw pc.
It would be great to have Xite with a fanless mini pc running reaper with dual monitors. I don't need anything else as i have moved full analogue and i just need the xite with a daw. I don't run any vst besides my analyzers. I need xite because i am used to it and i don't want to change my workaround... I seek to make a completely silent daw pc.
Re: Xite with Usb connector
there is plenty of bandwidth theoretically, but USB is several layers above hardware, unlike PCIe. there are timing issues for a realtime device. it might not be impossible, but it's not necessarily easy...
a silent pc would be a lot easier.
a silent pc would be a lot easier.
Re: Xite with Usb connector
Lol. He makes joke - someone with his knowledge.
TB3 would be cool though...imagine chaining 2 Xites ![😮](//cdn.jsdelivr.net/gh/twitter/twemoji@latest/assets/svg/1f62e.svg)
![:lol:](./images/smilies/icon_lol.gif)
Re: Xite with Usb connector
I think it is just a matter of driver and the type of device. If a device appears as an audio device the USB specification allows it to demand "guaranteed" timing and delivering of data. It is called "isochronous" communication. In this mode even windows or other non-real time os functions as realtime because the driver works from the kernel and not from user area.
Anyway. My damn english: "workaround-> workflow". Some time ago I wanted to write "as supposed" and written "as opposed"...
Anyway. My damn english: "workaround-> workflow". Some time ago I wanted to write "as supposed" and written "as opposed"...
Re: Xite with Usb connector
The last years I started learning electronics and after about 5 years I am able to design most analogue devices on my own. This year I learn "high voltage" (mains 220V) to make also tube designs. GaryB was right, analogue is the real thing and digital is good (as I say now) for recording, "daw-ing" and distribution. Digital seems to be one of the biggest dissapoinments of our era (for audio). I don't even like hybrid designs which are compromised for an example I got a roland se-02 and the whole thing with the presets and the quantised knobs spoils the instrument. (an analogue filter with 127 steps...) With analogue everything sounds better. Of course noone hears music anymore so it doesn't really matter. Analogue is still quite expensive so I think diy and "liy" (learn it yourself) is the way to go. This said, I still like my Xite workflow and I would like to carry it with me in this new period.
Ths Xite uses an "HDMI" cable that uses a PCI express inteface. I think with updated firmware and new drivers the device could be made to work with USB. Surely not something trivial but perhaps worthy because USB is abundand. If this is not possible, a PCI express to USB adapter should be feasible.
Ths Xite uses an "HDMI" cable that uses a PCI express inteface. I think with updated firmware and new drivers the device could be made to work with USB. Surely not something trivial but perhaps worthy because USB is abundand. If this is not possible, a PCI express to USB adapter should be feasible.
Re: Xite with Usb connector
it is feasible, it just won't work correctly. do you think it was never explored?
raw bandwidth numbers are deceiving. usb is bandwidth is about bursts of data, fine for a standard interface or a printer. what's needed is sustained throughput where timing can be maintained. if the data has to to through too many layers, that's impractical. if the XITE was simply an interface, things would be easier.
a good example is Thunderbolt. an Expresscard(PCIe) to Thunderbolt adapter works great because Thunderbolt is basically PCIe. if the Thunderbolt port is a combo USB3/Thunderbolt port, guess what? the adapter does not work. USB sucks, but it IS awfully convenient and useful. it's not very good for Scope, however.
raw bandwidth numbers are deceiving. usb is bandwidth is about bursts of data, fine for a standard interface or a printer. what's needed is sustained throughput where timing can be maintained. if the data has to to through too many layers, that's impractical. if the XITE was simply an interface, things would be easier.
a good example is Thunderbolt. an Expresscard(PCIe) to Thunderbolt adapter works great because Thunderbolt is basically PCIe. if the Thunderbolt port is a combo USB3/Thunderbolt port, guess what? the adapter does not work. USB sucks, but it IS awfully convenient and useful. it's not very good for Scope, however.
Re: Xite with Usb connector
But aren't there many audio interfaces that use USB or i am mistaken? I suppose streaming data works right otherwise these wouldn't be operating. I actually read for capacity to record 64+ channels in 192kHz
Check:
https://www.thomann.de/gb/usb_audio_interfaces.html
I can't see why Xite is different
Check:
https://www.thomann.de/gb/usb_audio_interfaces.html
I can't see why Xite is different
Re: Xite with Usb connector
https://www.thomann.de/gb/rme_fireface_ufx_2.htm
188 Channel USB and Thunderbolt Audio Interface
Up to 24 bit / 192 kHz
94 input / 94 output channels
Connections:
12 Analogue inputs (1-8 balanced jack, 9-12 balanced XLR / jack combo)
4 x Mic / Instrument Preamp (digitally controllable) with 48V phantom power individually switchable
12 Analogue outputs (1-2 Main XLR balanced, output 3-8 jack balanced, 9/10 + 11/12 stereo)
1 x AES / EBU I / O
2 x ADAT I / O (or 1 x ADAT I / O plus 1x SPDIF I / O optical)
2 x MADI I / O (optical & coaxial)
Wordclock I / O
2 x MIDI I / O
1 x Thunderbolt
1 x USB 3.0
188 Channel USB and Thunderbolt Audio Interface
Up to 24 bit / 192 kHz
94 input / 94 output channels
Connections:
12 Analogue inputs (1-8 balanced jack, 9-12 balanced XLR / jack combo)
4 x Mic / Instrument Preamp (digitally controllable) with 48V phantom power individually switchable
12 Analogue outputs (1-2 Main XLR balanced, output 3-8 jack balanced, 9/10 + 11/12 stereo)
1 x AES / EBU I / O
2 x ADAT I / O (or 1 x ADAT I / O plus 1x SPDIF I / O optical)
2 x MADI I / O (optical & coaxial)
Wordclock I / O
2 x MIDI I / O
1 x Thunderbolt
1 x USB 3.0
Re: Xite with Usb connector
again, it's because the XITE is a realtime device. it is not just an interface.
arguing with me about this is like arguing with your cat. i'm too stupid and not much will change. also, i'm liable to ignore you and just lick my balls.
i remember when Creamware was still in existence and Frank Hund came by my store and told me about his plans for USB and Scope and also told me about how it would be neutered to do so. for those who only wanted instruments, i'm sure it would have been fine. what we got were ASB boxes and Noah, and a company that went out of business.
arguing with me about this is like arguing with your cat. i'm too stupid and not much will change. also, i'm liable to ignore you and just lick my balls.
i remember when Creamware was still in existence and Frank Hund came by my store and told me about his plans for USB and Scope and also told me about how it would be neutered to do so. for those who only wanted instruments, i'm sure it would have been fine. what we got were ASB boxes and Noah, and a company that went out of business.
Re: Xite with Usb connector
I am not arguing just asking and taking opinions. At the end I don't really care, I am just passing my time questioning this or that. We are together at the stupid team.
I am pretty sure all these interfaces are realtime...
I had to read the USB specification because I had to interface an arduino due via USB with windows. Believe me "isochronous communication" is realtime capable in windows. Windows are nice enough to deliver realtime bandwidth to peripherals that are asking politely.
All these audio interfaces wouldn't work otherwise. USB 3 is very fast and 3.1 is even more.
USB Standards
Standard Also Known As Max. Data Transfer Speed
USB 1.1 Full Speed USB 12 Mbps
USB 2.0 Hi-Speed USB 480 Mbps
USB 3.2 Gen 1 USB 3.0 USB 3.1 Gen 1 SuperSpeed 5 Gbps
USB 3.2 Gen 2 USB 3.1 USB 3.1 Gen 2 SuperSpeed+ SuperSpeed 10Gbps 10 Gbps
I am pretty sure all these interfaces are realtime...
I had to read the USB specification because I had to interface an arduino due via USB with windows. Believe me "isochronous communication" is realtime capable in windows. Windows are nice enough to deliver realtime bandwidth to peripherals that are asking politely.
All these audio interfaces wouldn't work otherwise. USB 3 is very fast and 3.1 is even more.
USB Standards
Standard Also Known As Max. Data Transfer Speed
USB 1.1 Full Speed USB 12 Mbps
USB 2.0 Hi-Speed USB 480 Mbps
USB 3.2 Gen 1 USB 3.0 USB 3.1 Gen 1 SuperSpeed 5 Gbps
USB 3.2 Gen 2 USB 3.1 USB 3.1 Gen 2 SuperSpeed+ SuperSpeed 10Gbps 10 Gbps
Re: Xite with Usb connector
no, they are not realtime.
Windows is not realtime.
about arguing, i am just being funny.
USB is about bursts of data.
specs are funny. especially "up to". the Fireface is really a great product, though.
Windows is not realtime.
about arguing, i am just being funny.
USB is about bursts of data.
specs are funny. especially "up to". the Fireface is really a great product, though.
Re: Xite with Usb connector
fra77x2, if you would make a PCIe to USB adaptor that worked, that would be AWESOME!
Re: Xite with Usb connector
talking later...
Re: Xite with Usb connector
These are realtime btw
Re: Xite with Usb connector
2ms or 4ms latency is not realtime.
my Soundcraft 1600 mixer and spx90 are realtime.
Scope when connected to a sequencer has latency and is not realtime, but the unit itself IS realtime.
my Soundcraft 1600 mixer and spx90 are realtime.
Scope when connected to a sequencer has latency and is not realtime, but the unit itself IS realtime.
Re: Xite with Usb connector
For most of the other soundcards in the market, *including* UAD, the use of the USB/system bus is still going to be predictable to the driver. Keep in mind how many datastreams that Scope opens to the host system that have nothing to do with servicing the exposed software & hardware i/o's. Most of the cards you're listing (even UAD) also don't implement portions of their onboard FX in ways that are dynamically allocating resources in the same way as Scope (meaning the RME's effects on on the fpga alone, or they would not work standalone, and the UAD etc implement a realtively fixed processing block that keeps resources needed from the host system in use even when 'not in use'.)
Case in point here is how fixed the UAD software+hardware solution is, They currently set limits on bussing and latency (not adjustable like ASIO etc) to simplify these issues in a usage scenario much closer to Scope.
RME in your example has spent 2 decades tuning a single Xylinx FPGA. When a newer, more powerful FPGA became available to them they were able to extend the amount of i/o on offer, add onboard Fx and implement USB. But it's again still a single fixed unit that is used across ALL devices for over a decade now, and doesn't do anything dynamic once the driver is up and running with a card attached. They have made statements about how the USB protocol (software/chipset/cpu side) has improved in efficiency over the years, in fact now allowing the LOWEST round drip latency on the USB bus for this reason, but again this is doing nothing but delivering a fixed block of data each way to services the hardware attached to the software buffers. You know very well Scope does much more than this, and how much traffic goes across the system bus varies with too many factors to hardcode some kind of predictable/fixed amount of bus bandwidth and data moving around. Our limits tend to come from the system limits, which is why we tune our machines for maximum Masterverb Pro instances versus being hard fixed to say only enough resources for 6 regardless of the host system (which is closer to how your examples work, though I am oversimplifying still).
In addition, as an 'engineering' solution the problem is not likely to be 'this is impossible' but rather 'this is how Analog Devices, Sonic|Core, Creamware and the 3rd party players involved have decided to implement things and what you're asking would be more than a simple bolt-on replacement task'. GaryB doesn't engage in lofty discussion here as I do, for that you'll need to talk about something more exciting than computers and do so in person or on the phone. At least that's been my experience...
As for the rest of this discussion...
Servers != audio workstation. Semi related, but not really, just as 'server' itself is a very generic term and says nothing about overall workload (there's a vast difference between my Raspberry Pi--which runs a flavor of Windows btw--and a low end generically tuned 1u/2p 'rack' server with a storage pool, memory pool and a few low end cpu cores...and a server tuned for a specific type of workload under high usage and capacity.
Windows is "not" realtime because it's not a realtime kernel. There is/was a realtime kernel for windows decades ago, no idea how that's going. Preemptive multitasking was the first step towards 'breaking' the realtime model, but even in that case it simply used interrupts to 'change' to another task. The problem there was that any device needing to service data needed to wait its turn at that point. This was the 286 era... What *realtime* means in this context is that it takes a programmed, predictable amount of time to go through a code loop in the CPU. You handle each set of tasks (including doing nothing) in a predictable polling pattern, which is why ATARI for instance (and very old Macs) made stellar machines for midi timing.
There are realtime linux kernels btw, and it would be something you wouldn't even use for a router, let alone a server. This is more for embedded and industrial usage.
Now, we ditched 'preemptive multitasking' when we moved to OOP (Objective programming) and starting with the 386 onward the 'time slice' allocated to any given task became much more variable.
So, back to the topic at hand, this has nothing to do with how difficult it would be to reengineer Xite around USB. It's also worth asking WHY, so that it's more convenient and open to a wider usage audience (in terms of hardware platforms, sure, but possibly also buying audience due to being more standard). This makes total sense to a layperson, but GaryB gave the exact reason companies rarely dabble in the same sort of experiment twice.
Case in point here is how fixed the UAD software+hardware solution is, They currently set limits on bussing and latency (not adjustable like ASIO etc) to simplify these issues in a usage scenario much closer to Scope.
RME in your example has spent 2 decades tuning a single Xylinx FPGA. When a newer, more powerful FPGA became available to them they were able to extend the amount of i/o on offer, add onboard Fx and implement USB. But it's again still a single fixed unit that is used across ALL devices for over a decade now, and doesn't do anything dynamic once the driver is up and running with a card attached. They have made statements about how the USB protocol (software/chipset/cpu side) has improved in efficiency over the years, in fact now allowing the LOWEST round drip latency on the USB bus for this reason, but again this is doing nothing but delivering a fixed block of data each way to services the hardware attached to the software buffers. You know very well Scope does much more than this, and how much traffic goes across the system bus varies with too many factors to hardcode some kind of predictable/fixed amount of bus bandwidth and data moving around. Our limits tend to come from the system limits, which is why we tune our machines for maximum Masterverb Pro instances versus being hard fixed to say only enough resources for 6 regardless of the host system (which is closer to how your examples work, though I am oversimplifying still).
In addition, as an 'engineering' solution the problem is not likely to be 'this is impossible' but rather 'this is how Analog Devices, Sonic|Core, Creamware and the 3rd party players involved have decided to implement things and what you're asking would be more than a simple bolt-on replacement task'. GaryB doesn't engage in lofty discussion here as I do, for that you'll need to talk about something more exciting than computers and do so in person or on the phone. At least that's been my experience...
As for the rest of this discussion...
Servers != audio workstation. Semi related, but not really, just as 'server' itself is a very generic term and says nothing about overall workload (there's a vast difference between my Raspberry Pi--which runs a flavor of Windows btw--and a low end generically tuned 1u/2p 'rack' server with a storage pool, memory pool and a few low end cpu cores...and a server tuned for a specific type of workload under high usage and capacity.
Windows is "not" realtime because it's not a realtime kernel. There is/was a realtime kernel for windows decades ago, no idea how that's going. Preemptive multitasking was the first step towards 'breaking' the realtime model, but even in that case it simply used interrupts to 'change' to another task. The problem there was that any device needing to service data needed to wait its turn at that point. This was the 286 era... What *realtime* means in this context is that it takes a programmed, predictable amount of time to go through a code loop in the CPU. You handle each set of tasks (including doing nothing) in a predictable polling pattern, which is why ATARI for instance (and very old Macs) made stellar machines for midi timing.
There are realtime linux kernels btw, and it would be something you wouldn't even use for a router, let alone a server. This is more for embedded and industrial usage.
Now, we ditched 'preemptive multitasking' when we moved to OOP (Objective programming) and starting with the 386 onward the 'time slice' allocated to any given task became much more variable.
So, back to the topic at hand, this has nothing to do with how difficult it would be to reengineer Xite around USB. It's also worth asking WHY, so that it's more convenient and open to a wider usage audience (in terms of hardware platforms, sure, but possibly also buying audience due to being more standard). This makes total sense to a layperson, but GaryB gave the exact reason companies rarely dabble in the same sort of experiment twice.