MQA decoding is not mentioned anywhere in the Es9038pro datasheet so I think this is just wishful thinking from my side.
MQA support in DACs uses to be implemented in the XMOS USB interface... but MQA licenses is not being granted to DIY, only to whole certified products.
No.
I'm an owner of Manhattan II as well as of SE9028 and SE9038 pros from TPA (and also of other few DACs capable of DSD512). The Manhattan II is capable of MQA decoding by the hardware equipped with it but I rarely use this function because I'm little interested in MQA.
Regards,
MQA decoding can be done at application level via several players - no real need to do it at hardware level.
Not a huge fan in any case - better to just use native 88.2/96K bit rates or let the player decode and pass 88.2/96K. TIDAL in particular can decode MQA for you.
Not a huge fan in any case - better to just use native 88.2/96K bit rates or let the player decode and pass 88.2/96K. TIDAL in particular can decode MQA for you.
I finished integrating the Pro38 and the Merqury and rewriting a new firmware for the DAC this weekend. The Buffalo 38Pro is a big upgrade in SQ over the Buffalo II with IVY it is replacing. The sound is warmer with more details and bigger soundstage.
My Frankenstein DAC:
The Dac consists of one Buffalo III dac with 6 channels and one Buffalo III 38pro with 2 channels. The USB card is a Exau2i 8 channel i2s card. The DAC can be controlled by remote, rotary knob or PC. The dac truns of and on 3 power amps and also turns on/off a projector. I also use a relay to use the dac and amp (2 channels) on different speakers in another room. I use eventghost on the PC to control the DAC. I made some hydrid cables for i2s on the new Pro38 to connect to the Exa U2i.
Wow impressive project! Really glad to read that it is working.
Cheers!
Russ
Support Forum
Support forum Do not function. How to mount the 10 pin input header? The big into PCB or the small?
Support forum Do not function. How to mount the 10 pin input header? The big into PCB or the small?
Support forum is fixed. We are having some hosting provider issues.
Not sure I understand your question.
Buff PRO 9038/Mercury up and running here... Fed by Amanero/Hermes/Cronus and a single 45.1584 XO on the Cronus (sync clocking). Even with just a little warm up sound is very good, impressive! Nice work Russ.
I oversample all PCM to DSD 128, and send DSD files at their native rate. One problem though, the Amanero appears to switch channels R to L for DSD! WTF... As I only use DSD I can swap the u.fl cables to fix it, but what is the cause, just bad firmware from Amanero?
(I am still waiting for the Amanero/Dom to "finish" the Amanero firmware which allows for native DSD with linux (with full reliability).
I oversample all PCM to DSD 128, and send DSD files at their native rate. One problem though, the Amanero appears to switch channels R to L for DSD! WTF... As I only use DSD I can swap the u.fl cables to fix it, but what is the cause, just bad firmware from Amanero?
(I am still waiting for the Amanero/Dom to "finish" the Amanero firmware which allows for native DSD with linux (with full reliability).
Greetings Barrows.
Wasn't their a channel swap option in the Amanero firmware? It was a box you ticked. I think there was a DSD and PCM channel swap choices.
I'm going to check mine with left, right DSD tracks. I have an Amanero/Hermes/Cronus feeding a 9028Pro. I am using Vortexbox 2.4 on an older Signature Series Sonore Server with Roon.
Last edited:
I...
I just used the Amanero as it came from TPA as I have no windows machines here to program it with. I figured it would be configured to work correctly with TPA/Buffalo DACs. It is programmed in slave mode, as it is working fine with sync clocking (no dropouts). But channels are definitely swapped for DSD. Source is Sonore Signature Series Rendu SE, and DSD channels are correct with my other USB interface (as per ESS DSD/I2S mapping).
I just used the Amanero as it came from TPA as I have no windows machines here to program it with. I figured it would be configured to work correctly with TPA/Buffalo DACs. It is programmed in slave mode, as it is working fine with sync clocking (no dropouts). But channels are definitely swapped for DSD. Source is Sonore Signature Series Rendu SE, and DSD channels are correct with my other USB interface (as per ESS DSD/I2S mapping).
It's not a fault of the device and is mere reflection of the firmware (including CPLD) you are using. To solve this problem, you need a CPLD with channel swap which is available from the online site of Amanero but unfortunately there is no CPLD with channel swap for slave mode, necessary for Amanero-Hermes, for now. Previously I requested Amanero for this type of CPLD but never received any answer to it.
Regards,
Hmmm?
Russ/Brian, is this correct? It seems a bit odd that TPA would provide Amanero PCBs which swap DSD channels when used with ESS chips? Perhaps some people are OK with this? Really??
Russ/Brian, is this correct? It seems a bit odd that TPA would provide Amanero PCBs which swap DSD channels when used with ESS chips? Perhaps some people are OK with this? Really??
TPA should not be blamed. If they provide the Amanero board for the use of Hermes-Amanero and Cronus, I assume that the CPLD version they installed would be a slave_for_1080 and the firmware would be 1096c or something around it, which I think would not cause channel swap.
For the latest firmware like 2003be, however, the CPLD above will cause channel swap. To avoid this, a CPLD_1080_DSDSWAPPED can be used to avoid channel swap but this CPLD is not for slave mode; i.e., can not be applied when using in combination with Cronus.
You might look into the discussion in this forum.
Regards,
Barrows - From early on - DSD does not actually specifiy what constitutes LEFT/RIGHT vs channel 1/2. Some in the industry have agreed on mappings - but not all.
We don't write any of the firmware for the Amanero - we only supply Amanero with firmware with know to work. "Correctness" is not something we can control 🙂 Just ask people who have implemented DoP - they can't even agree on which channel is Left and which is Right. 🙂
The nice thing is channel swapping is easily done in software - either at encoding time or playback time.
Glad you are enjoying the DAC/Mercury!!!
Cheers!
Russ
We don't write any of the firmware for the Amanero - we only supply Amanero with firmware with know to work. "Correctness" is not something we can control 🙂 Just ask people who have implemented DoP - they can't even agree on which channel is Left and which is Right. 🙂
The nice thing is channel swapping is easily done in software - either at encoding time or playback time.
Glad you are enjoying the DAC/Mercury!!!
Cheers!
Russ
or in a XMOS firmware ... it would be cool to have a "free patch" for XMOS sources that will work with Amanero ... XMOS provides source & tools upon a registration ... and XMOS firmware can be updated via USB (if it was appropriately flashed initially)
Russ, I guess you do not want to create TPA XMOS receiver with isolated I2S & I2C I/O, do you?
Russ, I guess you do not want to create TPA XMOS receiver with isolated I2S & I2C I/O, do you?
Last edited:
I have actually already designed one - Brian and I were just not sure if we wanted to bring it to production since Amanero already does a great job.
Well...
Not everyone writes code or is capable of fixing the channel swap problem with Amanero and DSD. Not every playback software allows for channel swapping either, especially not just for DSD and not for PCM, which would be necessary to make the Amanero work "properly" with the Buffalo DAC.
Russ, I highly encourage you to go ahead with your own complete TPA USB solution, especially considering that it appears the Amanero guys cannot get native DSD working without bugs on Linux (I think you are already very dialed in with Linux, but if you need help for Linux native DSD compatibility I work with Sonore and can get you help there). Then considering the channel swap with DSD i would consider Amanero "broken" for use with the Buffalo. i am aware that there is no definitive spec for DSD L/R on I2S lines, but ESS has defined this for their chips...
I would love to see the following USB interface from TPA:
Includes isolation and re-clocking right before the output. USB receiver side powered via USB power. USB input, I2S/DSD output with direct feed masterclock for sync use. Correct channel mapping for ESS/DSD. Pluggable clock sockets as on Cronus, for wide variety of clock choice.
As I am feeding only DSD to the DAC, I can swap the u.fl cables to fix the channel swap, but of course this will not work for most who want to play PCM and DSD.
Again, thanks for the Buff PRO/Mercury, a nice step up from 9018 and any output stage I have tried!
Not everyone writes code or is capable of fixing the channel swap problem with Amanero and DSD. Not every playback software allows for channel swapping either, especially not just for DSD and not for PCM, which would be necessary to make the Amanero work "properly" with the Buffalo DAC.
Russ, I highly encourage you to go ahead with your own complete TPA USB solution, especially considering that it appears the Amanero guys cannot get native DSD working without bugs on Linux (I think you are already very dialed in with Linux, but if you need help for Linux native DSD compatibility I work with Sonore and can get you help there). Then considering the channel swap with DSD i would consider Amanero "broken" for use with the Buffalo. i am aware that there is no definitive spec for DSD L/R on I2S lines, but ESS has defined this for their chips...
I would love to see the following USB interface from TPA:
Includes isolation and re-clocking right before the output. USB receiver side powered via USB power. USB input, I2S/DSD output with direct feed masterclock for sync use. Correct channel mapping for ESS/DSD. Pluggable clock sockets as on Cronus, for wide variety of clock choice.
As I am feeding only DSD to the DAC, I can swap the u.fl cables to fix the channel swap, but of course this will not work for most who want to play PCM and DSD.
Again, thanks for the Buff PRO/Mercury, a nice step up from 9018 and any output stage I have tried!
Last edited:
Thank you Barrows! Sure that is a motivating argument.
To some degree any module like that might have need to be reflashed as challenges arise and drivers develop.
Cheers!
Russ
To some degree any module like that might have need to be reflashed as challenges arise and drivers develop.
Cheers!
Russ
Yeah...
Understood. One thing which can be frustrating with USB interfaces is the need to have a Windows machine handy for software changes. Incorporating a way to update software via OSX and Linux would be nice. Native DSD on Linux is something I am really interested in, and XMOS appears to have this all solved, although everyone's code needs to be addressed by the Linux/ALSA folks...
Understood. One thing which can be frustrating with USB interfaces is the need to have a Windows machine handy for software changes. Incorporating a way to update software via OSX and Linux would be nice. Native DSD on Linux is something I am really interested in, and XMOS appears to have this all solved, although everyone's code needs to be addressed by the Linux/ALSA folks...