• 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

Jump to Latest
M

Marek

Member
Joined 2003
themystical said:
The TPA firmware is only active at DAC power up after which it goes to "sleep" so shoudn't be interfering with the commands. The I2C bus will be powered by the 3.3V supply I assume. Not sure whether you can actually measure this on SCL with a multimeter, ideally you need a digital scope. What I meant originally was a simple continuity test with a multimeter on the wiring. SDA is pin 21 and SCL pin 22 on the Sabre chip if you wanted to test continuity right to the chip.
Edit-
Oops just noticed that you are using 0xA for your register, it should be 0x0A. That should sort it!!
Click to expand...

In my 80MHz version of BII I2C is active all over the time - it sends some commands every 1s or less.
 
J

Jackal29a

Member
Joined 2011
From B2 the user manual and integration guide:

Using external I2C controllers
The onboard firmware controller (10) is an I2C bus master. Since only one master is allowed on this bus, remove the controller when using an external controller on the I2C bus (Volumite for example).

What I don't know is if the Combo384 is included in the "external controller" category or not.
 
T

themystical

Member
Joined 2006
Jackal29a said:
From B2 the user manual and integration guide:

Using external I2C controllers
The onboard firmware controller (10) is an I2C bus master. Since only one master is allowed on this bus, remove the controller when using an external controller on the I2C bus (Volumite for example).

What I don't know is if the Combo384 is included in the "external controller" category or not.
Click to expand...

It probably fits into that category as the Combo384 operates as a "master". Do you have Volumite or any other controllers in your system? There is an arbitration process for multimaster conflict in I2C communication as explained by Bunpei in one of the earlier posts.
 
J

Jackal29a

Member
Joined 2011
No Volumite nor any other master other than the firmware chip.

BTW, Amanero has told me there are 2 x 6.8K pull up resistors on the Combo384 right before the output pins so that part should be covered.

I'm going to try flashing 1069 with tool V.110 as per his intructions and see if it makes any difference.

Cheers
 
C

charly chile

Member
Joined 2011
Hi ,
I bought Amanero a few months ago.
I m running Vortexbox > amanero > buffalo III

When playing music with different sampling rate, sometimes the DAC don't get the sample rate change and starts playing music faster, and ugly.

I need to pause the vortexbox player and press play again and then it gets the right sample rate.

Anyone solved this issue?
Thanks
 
J

Jackal29a

Member
Joined 2011
glt said:
Should work with two masters talking to one server as long is the I2C is released after each use (which it should). You could try starting it without the on-board processor (certain things will be configured differently, but I2S or SDPFI should work) and try the mute/unmute...
Click to expand...

I went back to firmware 1069 (CPU only) using tool 110a and removed firmware chip and it worked fine.

For verifying I used:

On352Set
ADD: 0x48
REG: 0x0A
VAL: 0XCF

On44Set
ADD: 0x48
REG: 0x0A
VAL: 0XCE


Played a 352K track and output was muted then played a 44.1K track and it unmuted output.

It doesn't work with the firmware chip on the Buffalo though, all non default configs it provides would have to be assigned to an event though I don't know which one could be the optimal one.

There is something affecting firmware 1072 and the Buffalo's compatibility.
 
merlin el mago

merlin el mago

Member
Joined 2009
Paid Member
Jackal29a said:
I went back to firmware 1069 (CPU only) using tool 110a and removed firmware chip and it worked fine.

For verifying I used:

On352Set
ADD: 0x48
REG: 0x0A
VAL: 0XCF

On44Set
ADD: 0x48
REG: 0x0A
VAL: 0XCE


Played a 352K track and output was muted then played a 44.1K track and it unmuted output.

It doesn't work with the firmware chip on the Buffalo though, all non default configs it provides would have to be assigned to an event though I don't know which one could be the optimal one.

There is something affecting firmware 1072 and the Buffalo's compatibility.
Click to expand...

Congratulations:)
 
M

Marek

Member
Joined 2003
1072 firmware has increased I2C clock speed to 100kHz. Speed isn't a problem here because my atmega8 configured to send I2C commands as a master is working flawessly with Buffalo at 100kHz.
There is some unclear problem with Amanero I2C functionality - for example it was working to me for a while with 1069 firmware, then I upgraded to 1072 (not working) and back to 1069 and now it is not working... This is not just firmware related or OEMTool related - I can't figure out what is the reason
 
Last edited:
G

glt

Member
Joined 2004
diyaudio.com/forums/showthread.php?s=&threadid=140669
Jackal29a said:
I went back to firmware 1069 (CPU only) using tool 110a and removed firmware chip and it worked fine.

For verifying I used:

On352Set
ADD: 0x48
REG: 0x0A
VAL: 0XCF

On44Set
ADD: 0x48
REG: 0x0A
VAL: 0XCE


Played a 352K track and output was muted then played a 44.1K track and it unmuted output.

It doesn't work with the firmware chip on the Buffalo though, all non default configs it provides would have to be assigned to an event though I don't know which one could be the optimal one.

There is something affecting firmware 1072 and the Buffalo's compatibility.
Click to expand...

Yes, congrats!. If the other master does not release the bus, then no one else can acquire the bus. But you will need to capture the bus signal to see if this is what is going on.
 
J

Jackal29a

Member
Joined 2011
glt said:
Yes, congrats!. If the other master does not release the bus, then no one else can acquire the bus. But you will need to capture the bus signal to see if this is what is going on.
Click to expand...

I wish I knew how or have the tools to do that but even if I did and found the problem, how could I fix ? probably new firmware code from TPA would be needed and I highly doubt they'll be willing to write it as they already state that the chip needs to be removed if an external uC is used.
 
You must log in or register to reply here.
Top Bottom