Agree this is silly, National Instruments has USB based instrumentation without problems. The BW is not an issue, downloading movies or copying one USB hard-drive to another while you are trying to measure a pre-amp is not a realistic limitation. Speaking of hard-drives, what is a good benchmark for sustained throughput on a USB one? I have never had a problem with storing huge files on one and doing processing/saving.
Chris makes a good point the people that make real money on audio stuff are very concerned with the latency issue, in fact almost everyone discussing ASIO support is worried about that and almost nothing else. Latency is a huge issue for gear intended for use in performance and/or recording. My musician friends are amazingly sensitive to it, baffles me.
Last edited:
By the way WinUSB does support isochronous transfers from a WinUSB desktop app.
https://msdn.microsoft.com/en-ca/library/windows/hardware/dn376866(v=vs.85).aspx
Not sure how well.
https://msdn.microsoft.com/en-ca/library/windows/hardware/dn376866(v=vs.85).aspx
Not sure how well.
The they shouldn't be using USB at all. This is nonsense. USB is fine for control but the work should be done in hardware. Not in a windows app. It's fine for editing and such but real-time?
When recording monitoring is done in software rather than hardware, latency can be a big problem. When overdubbing and listening with headphones, for example, one can hear one's self playing as an echo a few ms after actually doing the playing. That can make it hard to maintain one's timing along with the music. Of course, many people probably wouldn't notice a delay of a few ms, but some drummers, again for example, learn to hear very small timing differences, and a few ms of delay can be enough to throw them off. As little as 5 ms is enough to get complaints from some people.
Maybe i got lost in the hundreds of pages of this thread...
Are you not talking about low THD oscillator design anymore?
Why not use a notch and a soundcard/spectrum analyzer/distortion analyzer/xxx to measure the THD?
Otherwise i would suggest to open a new thread.
Udo
Yes the point, this has nothing at all to do with measuring THD of an oscillator, if the answer is 500ms late who cares?
The Raspberry Pi uses the same USB port for everything including network comm.
If you are moving a large file from a drive some delays can be ignored because the whole file will get through. To do that with audio samples you need enough local buffer to accommodate the worst case stall on the buss.
Every port on the PC or whatever does not have a direct path to main memory. Usually they are shared. Sometimes with unexpected things like a Bluetooth interface.
There are a lot of other issues that bite inside the PC as well. Fire up DPC latency checker to see what's happening.
Buffering doesn't work on playback easily since it's hard to refill a buffer fast enough. It's more severe on network or especially wifi. FireWire was designed to be isochronous to deal with these issues but it's dead.
Speed alone is not the fix. Or Wifi audio would never have been a problem.
USB has intrinsic latency that's due to the packet rate (1KHz on Fast and 2.5KHz on high speed I think). For closed loop tests you can deal with it but it's always there.
Sent from my LG-H811 using Tapatalk
If you are moving a large file from a drive some delays can be ignored because the whole file will get through. To do that with audio samples you need enough local buffer to accommodate the worst case stall on the buss.
Every port on the PC or whatever does not have a direct path to main memory. Usually they are shared. Sometimes with unexpected things like a Bluetooth interface.
There are a lot of other issues that bite inside the PC as well. Fire up DPC latency checker to see what's happening.
Buffering doesn't work on playback easily since it's hard to refill a buffer fast enough. It's more severe on network or especially wifi. FireWire was designed to be isochronous to deal with these issues but it's dead.
Speed alone is not the fix. Or Wifi audio would never have been a problem.
USB has intrinsic latency that's due to the packet rate (1KHz on Fast and 2.5KHz on high speed I think). For closed loop tests you can deal with it but it's always there.
Sent from my LG-H811 using Tapatalk
@ Davada and others,
maybe we need to look into what chris719 is saying
in a different light here.
David, perhaps "we" are using the incorrect interface here. USB = SUX.
That said, what is becoming more prominent and usable
might be better for all if "we" used this:
HDMI ?
maybe we need to look into what chris719 is saying
in a different light here.
David, perhaps "we" are using the incorrect interface here. USB = SUX.
That said, what is becoming more prominent and usable
might be better for all if "we" used this:
HDMI ?
If you're using a Raspberry Pi then yeah, I can see problems arising. The Raspberry Pi's Broadcom SoC uses a USB controller from a company called Synopsys (think it's called DesignWare). From my limited experience with it, it's not very good. It's pretty popular in ARM SoCs unfortunately. A couple years ago, the Linux drivers were incredibly unstable and didn't even support isochronous transfers correctly. The Raspberry Pi foundation guys rewrote a lot of it, but it's still not up to Intel quality. Might be a result of a lot of hardware errata, not sure.
USB is a compromise, for sure, but it's workable. I have an HD CableCard tuner that works over USB and presents itself as an Ethernet interface to the PC, which means it's using bulk transfers. I never get any dropouts and that's an HD video + 2ch PCM or 5.1 AC3 stream.
HDMI is probably not too helpful. I am not as familiar with the spec as some, but it might create more problems than it solves. I think the transport is the clock source too, just like SPDIF. Really dislike the whole licensing scheme and HDCP as well, although you probably wouldn't need HDCP for audio work.
If you want interoperability then you're going to use USB Audio Device Class as Demian mentioned. If not then you are free to do whatever you want. If you're going to go through the trouble of writing your own drivers you could try Ethernet. Seems to work for those networked HDTV tuners.
An internal PCIe interface card would work too if you use one of the CMedia PCIe audio chips or an FPGA, but it seems like an idea from 15 years ago and a lot of work.
Last edited:
HDMI probably won't get corrupted by a mouse click, eh?
Made for high through put.
Heck, then we could just view FFTs and such with our TVs in
the living room much to the chagrin of our spouses, eh?
Hey honey, look at this distortion artifact?
Perhaps not.
Made for high through put.
Heck, then we could just view FFTs and such with our TVs in
the living room much to the chagrin of our spouses, eh?
Hey honey, look at this distortion artifact?
Perhaps not.
Don't even think about using HDMI. If you use it as specified the audio is packetized in the horizontal refresh in one of the many video formats. You get plenty of bandwidth, the latest spec is for 22 channels of 1.5 MHz sample rate audio. Its all unidirectional over 4 6 Gbps differential links. Its also a PITA to get everything right. There is another "standard" using HDMI cables and connectors sending I2S over LVDS on the HDMI pairs. I think these are all ways to feed into audiophilia nervosa.
SPDIF works fine for everything up to 192/24. For captured data losing a bit is pretty much unknown with the receivers able to get data with jitter as high as 5 UI. For playback I have measured 20 pS jitter from a standard line receiver. Its a solved problem. There are plenty of PCI and PCIE cards that can handle multiple SPDIF in and out. They can be had cheap. And SPDIF can be fully isolated. Even Toslink. I used Toslink when measuring the 20 pS jitter from a spectrum. I have an HP 5370 but its noise floor is 20 pS leaving no new insights there.
SPDIF works fine for everything up to 192/24. For captured data losing a bit is pretty much unknown with the receivers able to get data with jitter as high as 5 UI. For playback I have measured 20 pS jitter from a standard line receiver. Its a solved problem. There are plenty of PCI and PCIE cards that can handle multiple SPDIF in and out. They can be had cheap. And SPDIF can be fully isolated. Even Toslink. I used Toslink when measuring the 20 pS jitter from a spectrum. I have an HP 5370 but its noise floor is 20 pS leaving no new insights there.
I wonder if anyone has actually tried simulating the Viktor oscillator in Spice ?
I tried today. The LM4562 model is faulty, so needs fixing later on.
For a quick check I tried using LT1115 instead, but could not get it to oscillate.
Anyone has more success ? Would be grateful for any pointers.
(And hope Viktor wouldn't mind, since schematics is already in public domain.)
Many thanks,
Patrick
.
I tried today. The LM4562 model is faulty, so needs fixing later on.
For a quick check I tried using LT1115 instead, but could not get it to oscillate.
Anyone has more success ? Would be grateful for any pointers.
(And hope Viktor wouldn't mind, since schematics is already in public domain.)
Many thanks,
Patrick
.