Assuming it's a sigma-delta ADC, the input filter isn't very important. It samples at several MHz, and on-chip digital resampling produces the desired output rate with proper suppression of aliases. Regardless, the ADC clearly (from the 192 kHz sweep) has reasonable attenuation of input frequencies above 22 kHz. The behaviour seen can never occur in a linear system operating at 44.1 kHz sample rate. Therefore, something else had to be going on, and we found it: the repeated samples.
-
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!
Interface Mystery
- Thread starter Joakim
- Start date
- Thread Starter
- #42
Yeah, the next step is to hear back from the manufacturer about what's up with those repeated samples. Thanks to everyone who pitched in, and to mansr for figuring it out!
In case anyone is interested, here's a not very mathematical illustration of what's going on:
1. A 1000 Hz sine tone at 44.1 kHz.
2. The same 1000 Hz tone recorded by the mystery device. Note how the repeated values at every other sample point forces a number of superimposed cycles.
3. The result is an additional frequency peak at 21,000 Hz.
4. This hints at why there's an inverted sine sweep when the frequency moves from low to high (or the other way around). There's always an added frequency at 44,100 / 2 minus the original frequency. Below is an example of a high-pitched tone with a superimposed lower frequency.
In case anyone is interested, here's a not very mathematical illustration of what's going on:
1. A 1000 Hz sine tone at 44.1 kHz.
2. The same 1000 Hz tone recorded by the mystery device. Note how the repeated values at every other sample point forces a number of superimposed cycles.
3. The result is an additional frequency peak at 21,000 Hz.
4. This hints at why there's an inverted sine sweep when the frequency moves from low to high (or the other way around). There's always an added frequency at 44,100 / 2 minus the original frequency. Below is an example of a high-pitched tone with a superimposed lower frequency.
- Joined
- Feb 23, 2016
- Messages
- 20,759
- Likes
- 37,612
The question is with a broken design on the ADC, and Cirrus DAC what are the supposed advantages of this mystery device? Why bother at $1500 when many other devices offer excellent performance and additional DSP features vs this device.
People purchased the below goofy DAC which was only 16 bit at fairly high prices screwed to a wooden board. Altmann Attraction.
Beats me as to why?
People purchased the below goofy DAC which was only 16 bit at fairly high prices screwed to a wooden board. Altmann Attraction.
Beats me as to why?
- Thread Starter
- #44
I'm happy to report that the AD converter no longer is broken! I received an email with a firmware update this morning and all the weird artifacts are gone. If I understand it correctly, an error had been introduced while optimizing the audio routines and this caused the inputs to be read twice.
So here (finally!) is the Mystery Device:
http://www.gotharman.dk/ld3_mkii.htm
It's an eight-channel granular stereo sampler based on the work in computer music by people like Iannis Xenakis and Curtis Roads. There really is nothing like it in hardware form and I think this explains some of the unusual design choices. For example, it's capable of processing a lot of audio at once, so a lower sample rate is useful for that, and it does it with a latency of a single sample, or around 22 microseconds. Latency can be a big deal when recording and processing audio and this is orders of magnitude better than just about anything else on the market. I don't know for sure, but I'm guessing the whole anachronistic assembly language thing has something to do with it.
I really can't thank everyone who helped out enough. If you'll excuse the rockist analogy, it's as if you've given a fresh set of strings to a bunch of people who had been playing their 1959 Jazzmasters with a rusty E, A and D.
So here (finally!) is the Mystery Device:
http://www.gotharman.dk/ld3_mkii.htm
It's an eight-channel granular stereo sampler based on the work in computer music by people like Iannis Xenakis and Curtis Roads. There really is nothing like it in hardware form and I think this explains some of the unusual design choices. For example, it's capable of processing a lot of audio at once, so a lower sample rate is useful for that, and it does it with a latency of a single sample, or around 22 microseconds. Latency can be a big deal when recording and processing audio and this is orders of magnitude better than just about anything else on the market. I don't know for sure, but I'm guessing the whole anachronistic assembly language thing has something to do with it.
I really can't thank everyone who helped out enough. If you'll excuse the rockist analogy, it's as if you've given a fresh set of strings to a bunch of people who had been playing their 1959 Jazzmasters with a rusty E, A and D.
- Thread Starter
- #46
Ha, I guess it did. 
I actually think this is why the problem went unnoticed for a while. The Little deFormer is known for its lack of hand holding and extreme sample manipulation capabilities — some of which can get very ugly if you want them to — but it wasn't meant to be doing this. Now it can play nice too.
I actually think this is why the problem went unnoticed for a while. The Little deFormer is known for its lack of hand holding and extreme sample manipulation capabilities — some of which can get very ugly if you want them to — but it wasn't meant to be doing this. Now it can play nice too.
As I suspected. It's somewhat damning that they allowed it to be released with such a flaw. To their credit, they fixed it without ado.
- Thread Starter
- #48
I agree, it is a bit concerning that something like this could slip through and it wouldn't be acceptable if it were a larger company. As it is, it's one person in Denmark making very unique devices according to his own eccentric tastes. It don't think the cost of time or components figures into it much. He builds what he wants and then makes more to sell on his website if someone else wants one too. Sometimes that's quite a few people (>50) and sometimes it's one or two, or no one at all.
When I've worked on speed-critical code, I've always started out writing a reference version in C before identifying the hotspots and optimising those in assembly, always having tests to ensure that the versions match. Compilers have come a long way in recent years, and CPUs have become a lot faster, but in some cases hand-written assembly still gives a very welcome speed boost.
Tks
Major Contributor
- Joined
- Apr 1, 2019
- Messages
- 3,221
- Likes
- 5,497
Any ballpark or cases you recall of the speed differences? I can't fathom anything these days being THAT critical. But then again, what would I know of mission/speed critical applications. Ive spoken with architects of high frequency trading software, don't recall even they mentioned even looking at Assembly, let alone using it. What sort of software would necessitate Assembly usage in the modern day?
Of course ignoring funny memes like "If you know Assembly, everything is open-source" ;P
For the critical parts, I have seen speedups in excess of 10x with 4x being more typical. This was before compilers could vectorise loops automatically. They've got a lot better at that lately, so the gains from hand-optimising are smaller now, but even the best compilers often miss a trick or two, and turning to assembly can still be worthwhile. Although vector code is the obvious target, linear code can also benefit when the compiler stumbles. Modern CPUs with out-of-order execution have, however, reduced the need for optimising these cases by hand.
The code I've worked on has been mostly codecs (audio, video, and images). Signal processing in general is amenable to assembly optimisations since you're typically dealing with relatively large chunks of work with few conditional branches (not counting loops). The longer an uninterrupted instruction sequence, the better your chances of doing something clever with it.
These days, you're probably most likely to need assembly level optimisations in real-time microcontroller applications, especially battery powered, where you want to get as much as possible done before the deadline. There is less demand for extreme optimisation of regular desktop or phone applications. Too bad, it paid really well.
Similar threads
- Poll
- Poll
