It's not a problem as long as the ADC does not have missing codes or bad DNL. The only benefit of using a non-integer ratio between Fc and Fs is that you can oversample and average out missing codes/DNL. It's of little benefit on mainstream audio ADCs because almost all of them are delta-sigma architecture and are already oversampling.
When I tried your link it went to something else: "http://www.data-odyssey.xn--nls-so0a/" Something was corrupted. Typing the correct end (.nl) works fine here.
Also thanks, Edmond for shearing your nice "Diana" around, I run it on WinXP with a EMU0202 and it works fine 1.53.5 .
I try on (arch)linux with wineasio 32bit and compiling with int instead of float with no luck, but Arta works fine with ASIO.
I would love your software (and others) being compiled for linux it make sens for DIY and the future ( I see 1/3 of the comment is about getting windows to work :--) ) and you wrote the program i "C" so it should be easy to complie it with gcc ? Or am I wrong
Anyway, I leaned alot from you and the rest of the guys here, and maybe I do not need a RTX after all
I try on (arch)linux with wineasio 32bit and compiling with int instead of float with no luck, but Arta works fine with ASIO.
I would love your software (and others) being compiled for linux it make sens for DIY and the future ( I see 1/3 of the comment is about getting windows to work :--) ) and you wrote the program i "C" so it should be easy to complie it with gcc ? Or am I wrong
Anyway, I leaned alot from you and the rest of the guys here, and maybe I do not need a RTX after all
Hi Boros,
First, thank you for your kind words. Regarding your amplifier design, it also runs in my simulator without any complains. But for meaningful comments I have to do some more simulations, for example THD analysis and phase margin of the feedback loop. At the moment however, I'm still busy with a few new features of DiAna and repairing some minor bugs. So first things first. I hope to find some time later to analyze your circuit (please don't hesitate to send me a reminder when it takes too long).
Cheers,
E.
Hi Thumb,
Cheers,
E.
Thank you for your kind words.
Good to hear it does work, the more so because someone else reported issues with an EMU sound card (though it was an EMU1212M). The weird thing is that I can't reproduce his error (with an EMU1212M).
Although I'm a noob to Linux, I don't think it's that easy to recompile the program for Linux. For example what about all those Windows specific Win32 APIs? It's far easier to make a compatible version that runs under Wine. That means a 64 bits Windows version (instead of the current 32 bits version), because the 32 bits version of Wineasio seems to be buggy. By the way, what kind of issues you had with Wineasio-32? Does it hang or did you get a format error, to name a few things.I try on (arch)linux with wineasio 32bit and compiling with int instead of float with no luck, but Arta works fine with ASIO.
I would love your software (and others) being compiled for linux it make sens for DIY and the future ( I see 1/3 of the comment is about getting windows to work :--) ) and you wrote the program i "C" so it should be easy to complie it with gcc ? Or am I wrong
Anyway, I leaned alot from you and the rest of the guys here, and maybe I do not need a RTX after all
Cheers,
E.
Edmond I don't remember if I mentioned this. I asked an Linux guru if it was possible to compile stand alone win apps with wine. He said yes and pointed me to some literature on the subject. The idea is to compile a standalone with a version that is stable with the code. Theoretically once it works it should work forever.
I might be wrong about this being stable forever.
I might be wrong about this being stable forever.
@David,
That's what I understood too. But the problem seems to be that a few 32 bits applications do work fine under Wine+Wineasio and a few other apps don't work. Regrettably it's beyond my capabilities to figure out where and why this happens (see also comments from keantoken).
Cheers,
E.
That's what I understood too. But the problem seems to be that a few 32 bits applications do work fine under Wine+Wineasio and a few other apps don't work. Regrettably it's beyond my capabilities to figure out where and why this happens (see also comments from keantoken).
Cheers,
E.
Everything is possible with Linux, it's just never as easy as you'd hope. That's maybe the main difference between Linux and Windows or MacOS. Compiling Windows software for Linux is rarely a simple task because one usually needs to re-do the whole GUI stuff, which is not "just C++" (hat's why I stopped doing GUIs for my own code). Also, talking to the audio device(s) is very different on different operating systems, so that part of the code would have to be done from scratch, too. Or change to PortAudio.
That said, you might be lucky to get DiAna runnig on a virtual box running Windows on your Linux machine?
The question was about compiling the software in a way to run under wine properly (maybe it already does run). No need to change audio API etc. Wine fully supports windows audio API - e.g. Arta runs great under wine, with winealsa.drv direct access to the soundcard at full capabilities of the HW, no need to install any drivers for a linux-supported soundcard.
@Edmond Stuart : here is some screen grabs.
I run it with wineasio 32bit ver. It works well in Arta except at 192KHz.
On Diana the Freq. is wrong it look like bad interface to the EMU/Wineasio.
Would winealsa.drv as @phofman speaks of could be used ?
p.s a nice link to howto compile to windos and linux:
Compile C Programs for Windows and Linux | Programmer's Notes
I run it with wineasio 32bit ver. It works well in Arta except at 192KHz.
On Diana the Freq. is wrong it look like bad interface to the EMU/Wineasio.
Would winealsa.drv as @phofman speaks of could be used ?
An externally hosted image should be here but it was not working when we last tested it.
An externally hosted image should be here but it was not working when we last tested it.
An externally hosted image should be here but it was not working when we last tested it.
p.s a nice link to howto compile to windos and linux:
Compile C Programs for Windows and Linux | Programmer's Notes
Last edited:
Honestly, cross-compiling a simple Hello world snippet and a complex package with hooks to GUI and other subsystems is absolutely incomparable.
But wine support should be a different story. Theoretically, since I have absolutely zero experience in development for windows
Thanks.
For some reason loop back (of the test signal) doesn't work. Maybe something is wrong with the settings of the EMU patch panel. But at least the signal from the ADC comes through, though it's just noise. Because it's noise, it explains why the frequency is wrong (I suppose you mean the readout at the left bottom).
Sorry, I can't answer that question, as my knowledge of Linux is next to zero.
Anyhow, the program doesn't seem to freeze or crash, right?
Cheers,
E.
off topic
Hi Akos,
I have run a few simulations and they look reasonably well.
First, I put a gain probe at three different places. The phase margin was okay in all three cases, but in one case, the gain margin was little too low (10dB), though not dangerous too low. This figure will be slightly better (12dB) when using KSC3503/KSA3281 instead of MJE340/MJE350 in the input stage and VAS.
Clipping looks nice at overload.
The current limiter (of the output stage) trips at a way too high current. I would suggest to increase ree to 0.22Ohm from 0.1Ohm an omit R302 and R309. Now it trips at 7A per FET (instead of 30A).
One thing I could not check is the THD performance due to the simplistic models of the output FETs. Because the weak inversion (sub-threshold) isn't modeled, you will see a lot of cross-over distortion, which isn't there in real life.
After modifying the current limiter, I think you can go on with this project.
Cheers,
E.
Hi Akos,
I have run a few simulations and they look reasonably well.
First, I put a gain probe at three different places. The phase margin was okay in all three cases, but in one case, the gain margin was little too low (10dB), though not dangerous too low. This figure will be slightly better (12dB) when using KSC3503/KSA3281 instead of MJE340/MJE350 in the input stage and VAS.
Clipping looks nice at overload.
The current limiter (of the output stage) trips at a way too high current. I would suggest to increase ree to 0.22Ohm from 0.1Ohm an omit R302 and R309. Now it trips at 7A per FET (instead of 30A).
One thing I could not check is the THD performance due to the simplistic models of the output FETs. Because the weak inversion (sub-threshold) isn't modeled, you will see a lot of cross-over distortion, which isn't there in real life.
After modifying the current limiter, I think you can go on with this project.
Cheers,
E.
Winealsa.drv is just the software layer that translates between Wine sound and Linux sound. It doesn't have ASIO support. That's what wineasio is for.
There are some ASIO Java libraries, I did wonder if someone could write a Java program which could present the ASIO interface to WINE programs and connect to the Linux drivers.
There are some ASIO Java libraries, I did wonder if someone could write a Java program which could present the ASIO interface to WINE programs and connect to the Linux drivers.