It sounds like you are a much more advanced SS user than me. For me the biggest turnoff for SS+ is the seemingly lack of option to load multiple biquads from a single .txt file exported from Vcad which is very easy in the old ss. It's possible to load them one by one in SS+ but that's just so annoying..
I would love to try it, but as I said I'm still a few months away from even testing the York for the first time.. I will gladly test it and am very happy to hear that you have improved some reliability.
Can you elaborate on what you have done? Is it just some i2c communication stuff?
Once I get confirmation from couple of users, I'll create a new thread dedicated to this and also show some data.
But what I did is quite simple: do not trust sigmastudio with transaction handling. It sends the data - grab it, put in FIFO and manage transactions with own code.
Sort of looks a lot closer to a more typical textbook/application_note approach. Probably not too hard to make some of it a little better. Could be a lot harder to make it a lot better. Thing is that most of textbook design is in relation to achieving good industry standard measurements, which is not exactly the same thing as good subjective sound quality (to some fraction of the population, at least). If the latter factor is more the goal then there may be more custom R&D work to do.
Last edited:
Nah--I just use SS to create the DSP "architecture". I use the microcontroller to compute the biquad coefficients and write the data into the Parameter RAM. So once SS puts the program into the EEPROM, I stop using SS and do all real-time control and parameter updates from the microcontroller. But I need to know the Parameter RAM address for each cell in order to develop the microcontroller code. To do this, I process the xxxPARAM.h file to generate a header file that defines the cell starting addresses. For example, the section of this header file for a 10-band equalizer looks like this, where the number is the Parameter RAM address for each biquad:
#define EQ_32 70
#define EQ_64 75
#define EQ_125 80
#define EQ_250 85
#define EQ_500 90
#define EQ_1K 95
#define EQ_2K 100
#define EQ_4K 105
#define EQ_8K 110
#define EQ_16K 115
I just checked version SS+ version 2.3, and it now generates a xxxPARAM.h file that includes the name I put on the schematic for the cell. It wasn't doing that in version 2.1. So, I'll be switching to SS+, because that is where all the new development and bug fixes will be.
The goal is to make something I think sounds good and is easy for me to use 🙂
But thanks for the insight. Something like those år what I will be going for once I have this simple pcm5102 setup working without excessive noise and other problems 🙂
Nice!! Good to hear they fix some of the issues. Once they fix the biquad thing then I'm also going over. I like it much more. It does compile and download wasasy slower than SS does though.. but writes the EEPROM faster xD
You might want to consider using an Arduino microcontroller to load the biquads and all the other cells. There is a lot of software involved, but I would give you the library files and some examples if you wanted to go that route. I haven't posted the libraries because I am not a programmer by profession, and I know that the code could be improved in many ways. But if you want it for your own use and agree to not distribute the source, you are welcome to have it.
The benefit of this approach is easily seen in implementing a loudspeaker crossover. Once you know how the compiler has assigned the biquad addresses, you can put those addresses into arrays. For example, a Tweeter-Woofer array of biquads can be defined as follows:
The real power of this approach is that you don't need to use SigmaStudio to load crossovers or change the volume or do other real-time control. The microcontroller can take messages from a remote user interface running on a cell phone or other devices to control the DSP. I have a nice user interface for Android that lets me control the microcontroller from my phone. I can also use Matter to control the DSP as an IOT device, with a simple PC or iOS GUI. I only need SS during development to string together the DSP cells and put the program into the EEPROM. SigmaStudio is great development software, but trying to use it as a real-time user interface imposes too many limitations, IMHO.
The benefit of this approach is easily seen in implementing a loudspeaker crossover. Once you know how the compiler has assigned the biquad addresses, you can put those addresses into arrays. For example, a Tweeter-Woofer array of biquads can be defined as follows:
This code defines an array of 10 biquads, 5 for the Low Pass Filter and 5 for the High Pass Filter. You can pass this array to a function that also takes the crossover frequency and crossover type as parameters:
This library function looks up the number of biquads and the biquad parameters needed for the specified enumerated crossover type from a table. It then does the bilinear transform to calculate the biquad coefficients for the specified crossover type and frequency. The function then calls the library functions that load the biquad coefficients into the biquad cells using the ADAU1466 safeload mechanism. So, with one simple function call you can implement just about any crossover type (up to tenth order) for any frequency. All of this code works well, although as I noted, it could be made neater and more efficient.
The real power of this approach is that you don't need to use SigmaStudio to load crossovers or change the volume or do other real-time control. The microcontroller can take messages from a remote user interface running on a cell phone or other devices to control the DSP. I have a nice user interface for Android that lets me control the microcontroller from my phone. I can also use Matter to control the DSP as an IOT device, with a simple PC or iOS GUI. I only need SS during development to string together the DSP cells and put the program into the EEPROM. SigmaStudio is great development software, but trying to use it as a real-time user interface imposes too many limitations, IMHO.
Okay. But still, with proper layout and thoughtful isolation you can make a definite audible difference. Take for instance the controversy/disagreements about the possible overuse of use of ferrite beads, arguably because that's what everyone else does and that's what the marketers promote. The people who make mixed signal videos don't necessarily do the experiments to find out if those practices have some adverse affect on sound. Such practices may my look okay in standard measurements, but whether or not you will like the sound better that way may be another matter altogether.
I certainly do not intend to use sigma studio as a user interface. But for what I currently need I can get by with a few potentiometers as user interface.
Eventually when I got the sound quality and basic functionality under control I would certainly like to add a Arduino, esp32 or other mC. A android app with a bit of eq and so on would be cool. But that's gonna be a seperate project waay out in the future 😛
I would love to get your Arduino library if you would share though. That would certainly give me a head start whenever I get to that in 5 years or so xD
I'm aware that layout is everything. Spacing and clear sectioning of the pcb. What is your thought on seperate gnd planes for analog and digital. From what I gather it seems like it's most likely gonna cause more issues than it would solve?
Do you think ferrites to isolate voltage rails on i.e a DAC sounds bad? I can maybe show you my DAC pcb tonight. Then you can say what's especially bad xD
I'll send the libraries via PM. I actually keep the main command library in the sketch folder because it keeps evolving with different projects and it is easier to work with that way. So, I'm also sending a simple sketch that has an early version of the command library.
None of this will probably make much sense without a lot of additional documentation. That documentation will take a lot longer, but sometime in the next year I intend to post a walkthrough on how to use and adapt this code on audiodevelopers.com. There is already some info on that site about the code, but some of it is out of date and it is not presented in a way that makes it easy to apply the code to other applications.
Probably best to avoid doing that in most cases. There may be some exceptions, but care has to be taken not to create a slot-antenna that would produce RF emissions.
A lot depends on clock and digital signal edge-rates. However, if there is enough separation/isolation between ground surface fill areas and if current loops are kept very small then it may be possible to design for it. Much simpler in most cases not to go there though. That said, Cestrian did something like that with his clock and reclocker board. One side is laid out for high speed digital, and the other side is laid out for analog RF: https://www.diyaudio.com/community/...2soverusb-pcm2dsd-rtz-dac.423401/post-7917601 The two sides are designed so they can be cut apart and separated to see if there is any problem with them being so close together.
There is a article on ferrites probably worth reading in my clock board thread at: https://www.diyaudio.com/community/threads/general-purpose-dac-clock-board.413001/post-7765137 In addition, I suspect there is more to it than just what is mentioned in that article. IME ferrites used in clock power circuits may have some tendency to give a "brittle" sound. Perhaps a consequence of ferrite hysteresis distortion/noise. However, we don't really know for sure if that's the best explanation.
Thank you very much! I will look at it when I get the time and get back to you!!
Thanks for confirming that! I will see what results I can get with a single gnd plane before I experiment too much!
Thanks for the link!! I will read it closely 🙂
And thanks for explaining your theory behind the impact of ferrites on the sound 🙂
So this is the current stage of my PCM5102 based DAC. This is mostly a proof of concept of the whole modularity of my DSP. Main goal is to test all the connectivity, fugure out if I will use FFC, or normal ribbon cables or U.FL connectors as well as how to distribute power. All while trying to reach decent performance (Not top of the line HiFi).
Schematic PSU:
Schematic DAC:
Layout still isn't finished but this will give you an idea of what it will look like:
And 3D render:
And how the four DACs will be mounted in the chassis:
The remaining two I/O modules are a SPDIF board and a ADC - those are far from done yet.
The goal is to later make some more fancy DACS based on the AKM4493S.
Any thoughts @Markw4 and others? 😀
Cheers, Daniel
Schematic PSU:
Schematic DAC:
Layout still isn't finished but this will give you an idea of what it will look like:
And 3D render:
And how the four DACs will be mounted in the chassis:
The remaining two I/O modules are a SPDIF board and a ADC - those are far from done yet.
The goal is to later make some more fancy DACS based on the AKM4493S.
Any thoughts @Markw4 and others? 😀
Cheers, Daniel