WRT the distortion compensation, I've found that the DAC sounds worst by having the block enabled - irrespective of the values programmed.
The values are so sensitive that its only practical to individually program (tune the values) for each unit.
Even once they are programmed the THD will drift with temperature etc...
I'm no software guy, I tried to learn "C" but it went over my head... BASIC + 8051 assembler is my limit... Yes, really showing my age!
The values are so sensitive that its only practical to individually program (tune the values) for each unit.
Even once they are programmed the THD will drift with temperature etc...
I'm no software guy, I tried to learn "C" but it went over my head... BASIC + 8051 assembler is my limit... Yes, really showing my age!
Hi John, Now that you mention it I recall you saying that about the distortion compensation before. Any other comments about the Sabre dacs?
On another subject, I am surprised we are seeing so few AK4499 dacs. I know its possible to make one sound better than what Topping has done with D90, but they sure seems to have nailed down the low cost end of the AK4499 spectrum with a very elegant design.
Of course, in addition we are all waiting to see when newer dacs will get introduced and also to see if anything will ever come of Rohm's new dac chip.
On another subject, I am surprised we are seeing so few AK4499 dacs. I know its possible to make one sound better than what Topping has done with D90, but they sure seems to have nailed down the low cost end of the AK4499 spectrum with a very elegant design.
Of course, in addition we are all waiting to see when newer dacs will get introduced and also to see if anything will ever come of Rohm's new dac chip.
Last edited:
Mark,
I think you said it well recently, improving the ESS is like flogging a dead horse - I suggest time is better spent working with the new AKM DAC's...
ESS is not that bad in DSD mode, but IMO something is wrong with PCM inputs. I dont really understand whats going on as the DSD inputs are re-modulated by the same modulators as used with PCM...
RHOM looks interesting - I understand the BD34301EKV it an Array type DAC - hence the telling need for a high performance regulator - BD37201NUX (for the Array / Clock rails etc).
I keep pondering designing a DiY community board with the AKM's - but I really need to keep my head down and complete my current projects...
I think you said it well recently, improving the ESS is like flogging a dead horse - I suggest time is better spent working with the new AKM DAC's...
ESS is not that bad in DSD mode, but IMO something is wrong with PCM inputs. I dont really understand whats going on as the DSD inputs are re-modulated by the same modulators as used with PCM...
RHOM looks interesting - I understand the BD34301EKV it an Array type DAC - hence the telling need for a high performance regulator - BD37201NUX (for the Array / Clock rails etc).
I keep pondering designing a DiY community board with the AKM's - but I really need to keep my head down and complete my current projects...
Oh dear - looks like RHOM have some crazy high aspirations for there Audio line IMO - based on the the pricing for the "Audio Grade" LDO:-
BD37201NUX-TR Rohm Semiconductor | Integrated Circuits (ICs) | DigiKey
This suggest not much hope for there BD34301EKV pricing - if it ever sees the light of day...
BD37201NUX-TR Rohm Semiconductor | Integrated Circuits (ICs) | DigiKey
This suggest not much hope for there BD34301EKV pricing - if it ever sees the light of day...
I've tried to learn "C" but its a steep learning curve even to perform even the most basic tasks - do you have any experience with Micropython / Circuitpython ?
MicroPython - Python for microcontrollers
Also:-
CircuitPython
I have no working experience with Python - but its seem quite similar to BASIC (well more so then say C)...
I will have to get more involved in coding - while C is more "professional" I wonder if its not a first step to far?
Last edited:
No, but that would't put me off from learning how to use one or the other if there was some good reason for it. However, I have used a lot of different computer languages over the years. Seems like they always have some similarities between them, but some differences too. At least, the similarities help make it easier.
Hi John,
After thinking about it some more, not sure if the only programming you have done is in Basic?
If so, there would probably be pretty substantial investment in time to learn "C" if that is your ultimate goal.
We probably have some people who are primarily programmers that read this thread. Maybe one of them could chime in with some advice for you, and or maybe with a few tips about getting started.
I will chime in here. My day job is software engineering. So here are my 2cts on the topic of choosing a programming language:
C is the modern assembler. It can be very fast in execution because you're working directly on the device's memory with no intermediate layers. On the other hand a lot of things ca go wrong regarding memory allocation and addressing. Nobody will protect you from modifying memory beyond the allocated space. On machines with an MMU it will protect you from modifying memory that doesn't belong to you, but you can still wreck your own data structures. On top of that the syntax is neither elegant nor concise. A lot of the syntax is cumbersome, especially for beginners, most of all the usage of pointers can easily get confusing.
I can highly recommend using python as a beginner. It will force you to do proper indentation as it is part of the syntax of python. The language itself is very compact, very near to spoken english and very very powerful. For doing simple register programming vias i2c micropython on an esp32 is probably way fast enough. What's most important to me is that python will do all the hard work of memory managment for you, for example arrays will grow/shrink automatically so you can focus on the task at hand, write simple and elegant code and focus on the principle of the algorithms you develop instead of low level implementation details.
I know that the choice of programming language is a hot topic, so please don't freak out everybody. All of the above is partly undeniable fact and partly my humble opinion
As with natural languages it also comes down to personal taste and preference. Some will people find English is easy to learn and speak, others might differ.
C is the modern assembler. It can be very fast in execution because you're working directly on the device's memory with no intermediate layers. On the other hand a lot of things ca go wrong regarding memory allocation and addressing. Nobody will protect you from modifying memory beyond the allocated space. On machines with an MMU it will protect you from modifying memory that doesn't belong to you, but you can still wreck your own data structures. On top of that the syntax is neither elegant nor concise. A lot of the syntax is cumbersome, especially for beginners, most of all the usage of pointers can easily get confusing.
I can highly recommend using python as a beginner. It will force you to do proper indentation as it is part of the syntax of python. The language itself is very compact, very near to spoken english and very very powerful. For doing simple register programming vias i2c micropython on an esp32 is probably way fast enough. What's most important to me is that python will do all the hard work of memory managment for you, for example arrays will grow/shrink automatically so you can focus on the task at hand, write simple and elegant code and focus on the principle of the algorithms you develop instead of low level implementation details.
I know that the choice of programming language is a hot topic, so please don't freak out everybody. All of the above is partly undeniable fact and partly my humble opinion
As with natural languages it also comes down to personal taste and preference. Some will people find English is easy to learn and speak, others might differ.
My thoughts for a long time now.
The Rhom BD34301EKV DAC has true high Z current source outputs. I believe it is an array type DAC but the PSRR will be more complex than a
straight resistor array depending on architecture.
Due to current source OP, it should be easier on I-V opamp but the current edge rates may be faster than an R array - not sure. The PCM179x current
OP DACs certainly have very fast current edge rates.
The Rhom DAC may have some promise but they keep delaying it. Maybe they are trying to achieve better numbers?
Yep, focus is the key. This forum can be a distraction, currently working on a
pro audio product and there's just a huge amount to do.
TCD
Yes, the syntax is really complex and non logical (atleast to us humans)... I can see how its closer to the machine langue...
One typical issue with C that gets very confusing to beginners like myself is to be constantly aware of the mathematical "units" / precision, (Short / Long etc).
As you say the Syntax really starts to get "needlessly" stupid...
Yes, this is all I need - just to write to device registers, get the hardware powered up and basic functional tests - getting this done before working with the firmware / software team solves so many headaches - at least it allows you to "interpret" the device datasheet and work though any documentation errors / lack of description in the datasheet.. (ESS / AKM)...
Once hardware is functional this prevents (OK reduces) the software team blaming the hardware design when things dont work as expected
My only issue with Python is that there seems far less "modules / code" around for common devices (display drivers, Common IC's etc) that you can use as the starting block for your own code...
With C - someone nearly always has already implemented the IC your working on and you can use there code as a basis of your project - your not the first to have to make the mistakes / decrypt the Datasheet / register set / configuration procedure etc...
Personally I prefer the simple Resistor style array - I find they sound better then switched CCS style outputs, but as you infer, "PSRR / performance" is at the mercy of the designer - OK there is no PSRR... but you know what I mean
its a shame that the pending AKM seperated Array stage is a Switched CCS rather then a nice "Simple" resistor style Array the we could drive via our modulators...
Tell me about it - seems like we are in the same boat...
Last edited:
up to now I always found the libraries I needed, at least for standard python. If you want to get started really quickly i would recommend using a RPi, a tinker board or similar. You can run fairly standard linux, have a desktop with mouse and keyboard an use the onboard i2c to send your programming signals. Or even use a standard PC, linux and a usb->i2c dongle.
If you want to dive into python I highly recommend a decent IDE. My favourite is PyCharm. Available as community edition free of charge, for those who don't need to use it commercially. (No, I'm not a jetbrains shill)
If you want to dive into python I highly recommend a decent IDE. My favourite is PyCharm. Available as community edition free of charge, for those who don't need to use it commercially. (No, I'm not a jetbrains shill
)John, For I2C stuff I have just been using Arduino which communicates with a laptop using the Arduino Serial Monitor text-based interface (basically, a dumb terminal emulator).
Existing code can read/write individual registers and or preset one or more sets of registers. Can read/write byte and 16-bit words, and read 32-bit words. Input in decimal or hex. Display in decimal, hex, and binary.
I have used it for dacs, asrc chips, frequency divider chip, doesn't matter what it is. Also once modified it to write SPI bus (aka 4-wire serial).
However, it could use some cleaning up. Some of the code in it is no longer used, and some could probably be rewritten more elegantly. Main thing is that it works reliably. Happy to give you a copy and explain how to modify it to your needs.
Existing code can read/write individual registers and or preset one or more sets of registers. Can read/write byte and 16-bit words, and read 32-bit words. Input in decimal or hex. Display in decimal, hex, and binary.
I have used it for dacs, asrc chips, frequency divider chip, doesn't matter what it is. Also once modified it to write SPI bus (aka 4-wire serial).
However, it could use some cleaning up. Some of the code in it is no longer used, and some could probably be rewritten more elegantly. Main thing is that it works reliably. Happy to give you a copy and explain how to modify it to your needs.
Last edited:
up to now I always found the libraries I needed, at least for standard python. If you want to get started really quickly i would recommend using a RPi, a tinker board or similar. You can run fairly standard linux, have a desktop with mouse and keyboard an use the onboard i2c to send your programming signals. Or even use a standard PC, linux and a usb->i2c dongle.
If you want to dive into python I highly recommend a decent IDE. My favourite is PyCharm. Available as community edition free of charge, for those who don't need to use it commercially. (No, I'm not a jetbrains shill
Thank you, I'll take a look at PyCharm...
I already use Arduino - but the environment is C based - which just reinforced the very steep learning curve required for C - anything I did involved a day or two getting to grips with Syntax etc... Almost wanted to bit bang a PIO port on a old Basic Z80 computer would have been quicker!
What attracts me to Python is its simple "Basic" like syntax - but without line numbers, and also more structured
Mark,
Thank you for the offer...
I use Arduino - its whats driven me to search for something simpler - I need to work with complex numbers and Datasets - not something that's easy for a beginner in "C"...Number formats in C make things so complex, forget trying to work with Stings - I want to remain a hardware guy with basic experience of programming - not to go down a deep rabbit hole
and become an expert programmer...If the Python route does not pan out - I'd have to reconsider Arduino "C" again...
Understood. I wouldn't use Arduino for that sort of thing either. However, IME for basic I2C register programming its fine.
EDIT: In any case, please let us know how you like the Python you look at. Maybe others will be looking for something similar and it could be helpful to have some user experience opinions.
Last edited:
Yes for sure - I'll drop a post with my experience with Python or what ever works best in the end...
Watched the video. Dunno, guess some experience using Micropython will be needed to decide how well it suits particular uses. I would agree that not having to learn as much programming minutia to use it should be attractive to more potential users.