• These commercial threads are for private transactions. diyAudio.com provides these forums for the convenience of our members, but makes no warranty nor assumes any responsibility. We do not vet any members, use of this facility is at your own risk. Customers can post any issues in those threads as long as it is done in a civil manner. All diyAudio rules about conduct apply and will be enforced.

USB to I2S 384Khz - DSD Converter

Hmmm, I got to try this. With another interface and Buffalo II 80 MHz, bypassing OSF did not solve the noise problem:
If I turned OSF off, I got the following:

SR<352Khz resulted in fast intermittent sound with the lock-led flashing like crazy. By increasing the dpll bandwidth setting to highest and the dpll bandwidth multiplier to x128 (this is the highest bandwidth setting possible), the lock-led flashing rate slightly decreased as though the DPLL was trying to lock. But there was no lock and no music
For sample rates 352.8K and below, the DPLL was able to lock but only when there was no music content (for example when the player is paused).
SR=384Khz resulted in “normal sound”
The frequency of the DPLL indicated was 64x smaller what it should be for I2S input. So for example, for SR=384Khz, the sample frequency determined by the dpll was 6000 Hz (if you multiply 6000×64 you get 384000 Hz)

I expect you may have been "fooled" by the HiFiDuino code...

I (some years back now) tested the HiFiDuino code, but after some testing i decided I could not use it due to the code was not conditional, the display routines displayed what the code was "believing" what the registers was programmed with and not the real register contents, and the display routines could not display volume levels in 0.5dB steps..
Also it did not use EEPROM for recall / storage of settings, did not control display contrast / backlight, did not control battery charging, did not have a register dump routine to the display for debugging, did not have good enough IRQ / realtime functions, did not display battery / PSU voltages or remaining battery time etc. etc..

It was impossible to know what values the ES9018 registers really was programmed with due to many registers have bits with very different functions and the HiFiDueno code programmed the very same registers from different places in the code without having a system taking care of the individual functions / bits.

The HiFiDueno code may have been rewritten so the basic inconveniences I experienced may have been rectified..
 
I expect you may have been "fooled" by the HiFiDuino code...

... the display routines displayed what the code was "believing" what the registers was programmed with and not the real register contents, ..

If you cannot believe what values are written to the registers, how can you believe what you read from them? :)

Happy New Year!
 
Originally Posted by RayCtech
I expect you may have been "fooled" by the HiFiDuino code...

... the display routines displayed what the code was "believing" what the registers was programmed with and not the real register contents, ..

If you cannot believe what values are written to the registers, how can you believe what you read from them? :)

Happy New Year!

Therein lies the "problem"....

You can count on your memories and your ability to have the logic of all code in your head...
Or make the code conditional...

As an example there are registers with multiple functions:

Code:
[color=#CC6600]if[/color] (REG14CH==1)
    {
    REG14 = DACmap + TrueMode + IIR + Slope ;
    I2C_TX(S32A, 14, REG14);   [color=#7E7E7E]// DAC3-4-7-8 Source, IIR Bandwidth, FIR Rolloff, Pseudo/True mode[/color]
    REG14CH=0;
    }

If I remember correctly the HiFiDuino code will when one of the functions are changed write to the register and thus also change ALL functions controlled by the register....
And if I also remember correctly - this will be done from several completely different locations and functions of the code....
And also the writes to the display are done in the same fashion.
Thus the programming and the displayed info may or may not be correct and it depends completely on if the programmer and code have incorporated enough "logic" to have total control of 2 million possible register setting combinations.

The conditional approach (as an example) allows for the IIR Bandwidth to be changed to a new value from the IR remote routine. Then only the variable for the IIR Bandwidth and the variable that tells that register 14 needs an update are changed in RAM.
Then the register programming routine are called and only registers witch need programming are updated.
Then the display routine are called and updates the display based on the true register settings.

With the conditional approach over 2 million possible register setting combinations can be selected in any combination - controlled from the IR remote - and the registers are programmed correctly and both the standard display info and the "register dump" display routine will show the actual and correct informations.
 
Easier than that:

Store value of register in a variable, set or clear bits of interest, done. Optionally save value in eeprom.

I do not think you got the "message" :)

The problem are however that the bits of interest are "set or cleared" from different parts of the code...
When a register have multiple functions the code may by "accident" change some unintended bits... and "forget" to change the displayed info accordingly etc. etc..

I have gone a bit further as I split each function of a register (as shown in my example) in separate variables and when changing one function only that functions variable are tinkered with. Thus when writing to the register all the variables a register may contain are summed (as shown in my example) - this allows the correct use of absolutely all combinations of a register failsafe.

I also (of course) both saves and recalls all variable to / from EEPROM.
Each configured input (I2S/PCM, I2S/DSD and SPDIF (multiple of all of them) also have separate sets of variables stored / recalled to allow the DAC optimized register settings pr. input. When register settings for one input have been tweaked optimally only a push of a button on the remote are needed to save all associated register values for that input to EEPROM. Thus each input can have different quantizer, DPLL, filter etc. settings and when the input selection are changed the DAC chip are reprogrammed optimally for each separate input device.
 
32 Bit playback possible under Jriver?

Hi,

I have finally had the time to play a bit with the Amanero adapter. I updated to the latest firmware and driver version 1.56.

I can select a 32 bit output format for foobar but I get an error when I do that for Jriver. I will check again tomorrow when I have access to that system but I seem to remembers that this works fine in Jriver with the Musiland adapter.

Cheers

Thomas
 
Hello everyone!
I ve had problem with recognizing device under Mac OS and win 7, so i upgraded firmware and installed newest driver - 1.0.56 - for win. After resolving that issue, i ve tried to connect amanero with Ak 4396, on this way:
amanero - ak dac

pin3 data - data
pin4 bclk - sclk
pin5 fsclk - lrck
pin8 gnd - gnd

No sound at all, Mac or Win7 - just noise on mac, silence on win. Is there anything wrong with setup? (with teralink USB-I2S everything works as earlier..)

Amanero is revD - if that is some important for helping me :D

Thanks for helping in advance!
 
yeeesss - now it works - tried on mac - perfectly..he he he. . just to hide out how to play dsd stuff on mac and i can fly :D and just to find out why kubuntu doesnt get me to use amanero as option for audio playback - i can see it in audio hardware, but not in the list where i can choose what device i want to use for playing music - then, i come to italia and buy huge booootle of finest beer to me domenico :D