-
WANTED: Happy members who like to discuss audio and other topics related to our interest. Desire to learn and share knowledge of science required. There are many reviews of audio hardware and expert members to help answer your questions. Click here to have your audio equipment measured for free!
Chord Hugo M Scaler - Stereophile Review (measurements also)
- Thread starter Tks
- Start date
what is a 1:1 SRC?
It means his filter is still in the path but the input and output rates are identical. I suppose that would be easily noticeable if it were a complete bypass because the latency would be much lower.
The reason I suggested that is he may be attenuating to give headroom for the reconstructed peaks he will see during the normal use case. A more sinister explanation is that he's well-aware that people will prefer a louder output so he attenuates in pass-through mode to ensure it wins in a quick A/B comparison.
That makes sense. The wording of the original quote lead me to believe something else was going on.
Last edited:
Yes I think asking @MC_RME about it is the best way. Hello MC, I suppose a PCIE soundcard should have reduced complexity as there is no need for FW/USB/TB interconnect, and I can't find another DSP chip on the card apart from the FPGA as well, so does it mean TotalMix FX is fully hardware-accelerated on this card? Thanks.
The complexity is pretty similar. Instead of an XMOS chip like a lot of competitors, you have an FPGA implementing their custom interfaces. It's probably easier to implement a PCIe DMA streaming interface than it is to perfectly implement UAC 2.0 from scratch, but then you have to write your own drivers from scratch for every OS you want to support. Definitely the best way to go for performance and control, but a lot of upfront work that RME has done. It should be easy for RME to implement TB3 since Thunderbolt basically just carries PCIe lanes. A Titan Ridge controller can probably be made to interface to their FPGA and it should behave almost as if it's a hot-swappable PCIe card. Might require driver work to handle that on some OSes.
I did say that I didn't think all of the DSP was in the FPGA, but the mixer could be. I don't know if @MC_RME will reveal all his secrets
. As convenient as USB is, USB is still a nightmare with host controller bugs and occasionally different behavior on different platforms, etc. Too bad there isn't an open PCIe audio IP core and matching open source driver.
A PCIe interface is more complex than a USB 2.0 device.
But excluding the device itself, for example a PC motherboard still has something like PCI-USB controller and USB root hub. So how does it compare to a Realtek codec for example?
Actually, that's not true for all types of devices. USB Audio Device Class 2.0 is a really annoying spec to implement and test all corner cases on.
I've worked on a small team implementing PCIe interfaces in FPGAs for streaming 4k video at rates well beyond anything audio needs. The complexity of my PCIe Linux driver is much lower than a full feature-complete UAC 2.0 driver. This is why even Microsoft licensed Thesycon's driver and there is not a lot of competition in that space.
I guarantee that I could implement both sides of a PCIe interface for a device I know the requirements of faster than I could fully implement UAC 2.0.
USB is actually a real disaster at many levels. There are only a handful of companies that can produce a working XHCI host controller. Of those, they all have a ton of bugs. You should look at the errata and quirks in the Linux drivers for them. It adds another entire layer of abstraction and is a polled bus, which is not great. Just Google AMD X570 USB issues, ASMedia USB issues, Synopsys USB issues, etc. The specs are a prime example of design by committee making life harder. Only Intel's controllers are finally pretty good, because they spend a ton of money and manpower beating it into submission.
Last edited:
I'm not talking about device drivers running on top of the OS generic PCIe support. That part pretty simple, usually. I'm talking about the hardware on the device side. USB is hugely annoying in many ways, but the hardware is simple enough to be available in cheap microcontrollers. To get PCIe, you have to move up to a different device class entirely.
An audio device developer doesn't have to worry about anything below the USB layer if they want to use USB. That silicon and those drivers are already designed and working. The reason I think USB is more complex to implement is just because of UAC 2.0. You could implement your own subset of the features from scratch and forego official class compliance, but then you have to write a custom driver and the effort isn't much less than doing PCIe, which will give you better performance.
It's actually easier to buy a Xilinx or Intel FPGA and add their ready-made PCIe IP core to the design and configure it than it is to find a microcontroller that will meet all the requirements of a high-res audio device and then figure out how to make it all work. Most "cheap" microcontrollers don't even have a 480 Mbps internal PHY. Almost none have I2S supporting rates beyond 192 kHz. You will notice that there are not that many products using an off-the-shelf ARM Cortex MCU for a USB to I2S bridge. The Thesycon offering is using a big and powerful STM32H7 @ 400 MHz and still can't match the feature set of an XMOS controller. You'll never get big channel counts out of one even if you get it working.
I've actually tried this stuff. You can get a PCIe interface running on a Xilinx development board in much less time than you will ever get UAC 2.0 working on, say, an NXP or ST MCU. Why else would so many people still be buying chips from XMOS, C-Media, ComTrue, etc. if they could buy a cheap MCU and be done with it? The C-Media chips are just an 8051 core with some custom peripherals anyway, but those peripherals and IO are important and there aren't many or any MCUs that will do what a CM6632A does.
Yeah, it's really simple if you want 2 channels of 24/96 only and can use a cheap MCU with FS PHY and example project. Beyond that, it is not. I understand where you're coming from, because on the outside it definitely seems like it shouldn't be this painful, but it can be.
For example: https://community.st.com/s/question...ronous-usb-feedback-problem-and-evenodd-frame
Just a poor guy that wants to use ST Micro's USB stack but finding bugs in it.
Last edited:
I have this question because I have used the RME Multiface II + HDSPe PCI card and it supports TotalMix (not FX at that time). I didn't open up the external box but apart from the card's FPGA, I suppose the external box also has another chip for the interconnect like this (which is an older version but similar product):
I also own this soundcard:
https://hardforum.com/threads/breat...-soundcard-creative-x-fi-titanium-hd.2003840/
The converters:
PCM4220, PCM1794A, WM8775
...as well as the main chip (CA20k2) and a RAM chip. This card can do unlimited multiclient ASIO with multiple effects running concurrently including the more complex one like reverb, as well as simpler ones like parametric and graphic EQ, with assignable aux send and inserts. It is a 10 years old product though I bought the card in 2013. Latency wise of course not as good as the RME products but the chip (perhaps driver?) on the Creative card can do these stuff. So far I don't know what this chip really is so let's say it is a custom ASIC, so I don't know how to compare it with these Xilinx chips, but should be quite feasible for a product released in 2020 I suppose?
I also own this soundcard:
https://hardforum.com/threads/breat...-soundcard-creative-x-fi-titanium-hd.2003840/
The converters:
PCM4220, PCM1794A, WM8775
...as well as the main chip (CA20k2) and a RAM chip. This card can do unlimited multiclient ASIO with multiple effects running concurrently including the more complex one like reverb, as well as simpler ones like parametric and graphic EQ, with assignable aux send and inserts. It is a 10 years old product though I bought the card in 2013. Latency wise of course not as good as the RME products but the chip (perhaps driver?) on the Creative card can do these stuff. So far I don't know what this chip really is so let's say it is a custom ASIC, so I don't know how to compare it with these Xilinx chips, but should be quite feasible for a product released in 2020 I suppose?
It's hard to compare, because the CA20k2 and it's predecessor the EMU 10k1 are indeed ASICs that happen to be audio DSPs. It would be no problem to implement what that chip can do in an FPGA for sure, or at worst an FPGA + external DSP. It's just a lot of work. Creative had a lot of manpower on their drivers too, I'd guess.
- Joined
- May 15, 2019
- Messages
- 879
- Likes
- 3,628
A bit off topic, IMHO. And no secret here at all. Start the time machine back to 2001:
https://archiv.rme-audio.de/old/english/techinfo/hdsp_tmhard.htm
Thanks. I think one should really appreciate the efforts being put in the software development side as well.
That's much more expensive than an STM32, NXP i.MX RT, or Atmel SAM microcontroller (yes, all of those lines have models with high-speed USB 2.0). If you need the level of processing power offered by the bigger devices, using PCIe is probably simple enough. For a plain DAC, it's a total waste. Why do you think that EVGA card uses an off the shelf PCIe to USB bridge hardwired an XMOS(?) as is usually found in external USB devices?
As for why XMOS is so popular for USB DACs, it's probably because they offer a ready-made solution, little or no actual engineering required by the would-be DAC manufacturer. If you need functionality beyond the standard options in the XMOS package, you might as well use a sane microcontroller.
Similar threads
