If the underlying technology allows it, there is no reason a driver should not handle it. If RME can handle 768kHz ASIO, I do not see a reason why Thesycon or any other driver could not handle 1536kHz. ASIO does not need Microsoft to allow that, it is a separate path.
So far driver developers had no USB audio hardware to test with, soon RPi4 with stock firmware will send/accept anything up to any combination of samplerate/channel count/sample size 65Mbps max to/from the USB host, a few commands to start the stream. Async playback will be next. IMO no reason to not have a driver like that on the market within a year, if the driver authors decide so (i.e. are pushed by windows users).
Maybe, but have you checked the pricing model for the Thesycon driver? And I don't see any competition in the Windows space jumping in (proprietary solutions are no good). Apparently it's a niche market (as anything else related to Audio outside of the mobile devices realm).
The easiest route is to do what QuantAsylum did and use a Cypress or FTDI USB 3.0 FIFO chip and write your own application using their APIs to acquire data. That's not an audio device, so it might not be what you are all looking for, but it solves the problem of just getting the data onto a PC fast enough. Works in Windows and Linux.
Hi again,
It seems a misunderstanding has crept in ... the 1.536 MHz sampling frequency spectrum in #168 was from a file - not streaming. So I don't know if wavespectra will handle these frequencies streaming.
Cheers,
Jesper
It seems a misunderstanding has crept in ... the 1.536 MHz sampling frequency spectrum in #168 was from a file - not streaming. So I don't know if wavespectra will handle these frequencies streaming.
I have also been thinking about these - would be great if someone with programming skills could customize "something" to handle some channels at 1.536 MHz. Wishing here ;-)
Cheers,
Jesper
6 channels of 384/24, 768 I've tested only 2 chans.
There were no problem with 16 channels, but 96k/24 max.
Or all the subjects involved could poll resources and hire someone to write a proper open source ASIO USB-audio class 2 driver for windows, available to everyone. Free BSD or bound by GPL, probably not important. Just like linux drivers are developed (apparently much more successful in the realm of USB-audio with lots of manufacturers involved - unlike in the closed graphics business with 2 players). Since that person could use all the linux USB-audio driver knowhow (including all the many specific hardware quirks which fix the manufacturers mistakes), IMO it could lead to results reasonably fast if done by someone skilled in windows drivers. Perhaps it could be based on linux alsa layer, with hooks written for the windows kernel (Cygwin being an example in user space). That would allow easier upgrades as linux usb-audio driver will be receiving new hardware support constantly (e.g. USB-audio class 3 is already included - no devices exist yet, developed with linux usb-audio cl. 3 gadget on the other side). The "shim" layer would be upgraded for new windows versions (usually completely different API), while the device-specific side from linux will keep continuity.
Everybody would gain.
Everybody would gain.
...and dump a wealth of good and (almost) free analyzer software in the process
Yeah, there is no good option here.
Quote from page 17.
It's impressive, I don't see thd-3 at 36 kHz. There is thd-2 where it's supposed to be, slightly higher than "typical" value charted in adc's DS. The issue I observed with 16/18-bits 1-2 msps adc (experimenting with AD7988/7984) is not sampling rate itself, adc quite happy with fast sampling, but THD level rising up starting about 10 kHz input and bumping up to -93 dBc at 100 kHz.
LTC2380 seems better, crossing -100 dBc at 200 kHz, but still would be hard to get those values, a lot 'd depend on a adc's front end driver. What OPA you are using?
Attachments
Hi all,
@phofman:
How much do you think this would cost - can you give a reasonable estimate?
@MagicianT:
Cheers - Jesper
@phofman:
How much do you think this would cost - can you give a reasonable estimate?
@MagicianT:
Oh, oh ... it's been a while so my memory on this is not entirely updated - but if I'm not mistaken I used either two ad797s in a "pseudo-balanced" buffer configuration or just fed Viktor's 12 kHz oscillator directly to the inputs of the 2380 (with resistor and capacitor input network). Also everything was placed on the table, unshielded, and wiyh quite long cables. The slightly "curvy" 12 kHz response seems to be associated with Viktor's oscillator (unshielded) as I have seen a similar response with the ak5572 and the ad7760.
Cheers - Jesper
Last edited:
There are quite a few people who can write a device driver on linux. Any new linux driver builds on huge work of previous people, it never starts from zero. Often it starts as copy/paste with minor changes from a driver (as little as one source file) of similar device, and then some refactoring all similar drivers to avoid code duplicity before posting the patches to the subsystem maintainer (who is usually pretty strict a picky about code quality, commit documentation etc.). You have all the people who wrote the code before you available, with contact information, they usually follow the respetive mailing lists.
Personally I do not know a single person who can write a USB-class driver for windows. Unless device manufacturers are provided with some source code from the core chip producer ((which obviously is not open source), they have to start from scratch, only using low-level windows drivers API. That would be USB-core (the layer which communicates with all the different device drivers and presents data to the USB controller), no USB-audio level.
I wrote a linux driver for one niche PCI soundcard a few years ago. My code ended up adding only rather thin layer to customize a large generic driver for Envy24 (ICE1724) on which the card was based (like ESI Maya, ESI Juli@, Revolution 5.1, 7.1 and countless other cards) to communicate with the additional chips onboard. It was a hobby project for me, I worked on evenings, while the fulltime developer of the korean card manufacturer was porting their existing XP driver to Vista. He sent me key pieces of his windows code to learn about the card internals - he had to build all the support for Envy24 himself, basically interfacing the PCI kernel layer. Huge work, because he had nothing to build on, nobody to turn to. Everyone else is a competitor, no sharing culture.
IMO the windows driver developer would start from the core USB too. He could not copy/paste from linux code (GPL breach), but he could get inspired to any detail, which is a huge help.
But then is this MS driver signature trouble, I know nothing about it.
My guesstimate - it could take up to 6-12 months for a person skilled in USB details, windows drivers and partly linux kernel (that being by far the easiest part). I wonder if such a combination walks on this planet...
I know that much, it's completely different in the Windows space. I have no knowledge of any Windows open source drivers, except for a few network cards aready in the garbage bins; to add insult to injury, windows drivers have to be certified and signed by Microsoft, otherwise they may not even install due to the UAC. You don't want to know how much the certification process costs.
P.S. Even if I would have the required skills, a 6-12 months full time project is not something I could afford to engage for free. I have a family to feed, you know...
Last edited:
I think you only need to purchase a cert to sign the driver, so I think a few hundred $, not full WHQL certification or whatever they call that program now. Still, it won’t be easy to find someone to do it for free.
I have the same EVM with the same intentions (but miniDSP on my side). It will work fine. Just remember that 0dB on a test record needs to be around -23dBFS and adjust to taste.
I really don't want to derail a useful thread, but you do realise you are talking rot?