DSD512 on Buffalo IIIse

twluke · 2016-08-03 7:46 pm

BrianDonegan said:
You can download the pre-compiled HEX files without having to build manually:

https://github.com/russwyte/Buffalo-3-3SE-on-board-firmware/releases/tag/1.0.0-beta

Hi Brian and Russ, I'm sorry to have failed to tell that my problem could not have been solved even with the hex files above. There appears to be still a problem remaining in my AVR flashing process as Russ pointed out..

Thank you for taking your time.

Russ White · 2016-08-04 3:25 pm

You may need to flash HVSP mode instead of ISP mode. Worth a shot.

BrianDonegan · 2016-08-08 8:49 pm

twluke said:
switching to SPDIF using a dual pole single throw switch did not work.

This function on the B3se is not performed by the firmware. The analog switches are connected directly to the IP_S pin header.

Also, the response of volume control connected to ADC became slow and rather delayed

I think what you are experiencing is related to averaging of the ADC values to keep down noise. Since you are able to compile yourself, you can try reducing the number of samples in the average by tweaking the value of the AVG_LEN constant in the buffalo.h file.

Code:

#define AVG_LEN 20 // The number of times to sample ADC

twluke · 2016-08-11 12:49 pm

BrianDonegan said:
I think what you are experiencing is related to averaging of the ADC values to keep down noise. Since you are able to compile yourself, you can try reducing the number of samples in the average by tweaking the value of the AVG_LEN constant in the buffalo.h file.

Code:

#define AVG_LEN 20 // The number of times to sample ADC

Hi Brian, thank you for your kind advice. First of all, I'd like to make it clear that the firmware I'm going to update is not for B3SE but for B3 because I've broken the IC socket of the firmware chip for the former.

Anyway, before trying your advice, I decided to dismiss Arduino as AVR ISP and bought a small programmer (Pocket AVR Programmer from Sparkfun). This worked well under Ubuntu and I could make a chip of working firmware either from precompiled hex file by Russ or from the one I compiled. The new firmware is quite stable in playing music, PCM or DSD, with the DPLL to the lowest.

Below iis the log of AVR flash. Final hfuse and efuse appear swapped. Is this okay?

Code:

root@ubuntu:/usr/src/Buffalo-3-3SE-on-board-firmware/Release-B3# avrdude -P usb:002:004 -b 19200 -c usbtiny -p attiny85 -U lfuse:w:0xd2:m -U hfuse:w:0xcd:m -U efuse:w:0xff:m -U flash:w:./on-board-b3.hex

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0x1e930b
avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "0xd2"
avrdude: writing lfuse (1 bytes):

Writing | ################################################## | 100% 0.00s

avrdude: 1 bytes of lfuse written
avrdude: verifying lfuse memory against 0xd2:
avrdude: load data lfuse data from input file 0xd2:
avrdude: input file 0xd2 contains 1 bytes
avrdude: reading on-chip lfuse data:

Reading | ################################################## | 100% 0.00s

avrdude: verifying ...
avrdude: 1 bytes of lfuse verified
avrdude: reading input file "0xcd"
avrdude: writing hfuse (1 bytes):

Writing | ################################################## | 100% 0.00s

avrdude: 1 bytes of hfuse written
avrdude: verifying hfuse memory against 0xcd:
avrdude: load data hfuse data from input file 0xcd:
avrdude: input file 0xcd contains 1 bytes
avrdude: reading on-chip hfuse data:

Reading | ################################################## | 100% 0.00s

avrdude: verifying ...
avrdude: 1 bytes of hfuse verified
avrdude: reading input file "0xff"
avrdude: writing efuse (1 bytes):

Writing | ################################################## | 100% 0.00s

avrdude: 1 bytes of efuse written
avrdude: verifying efuse memory against 0xff:
avrdude: load data efuse data from input file 0xff:
avrdude: input file 0xff contains 1 bytes
avrdude: reading on-chip efuse data:

Reading | ################################################## | 100% 0.00s

avrdude: verifying ...
avrdude: 1 bytes of efuse verified
avrdude: reading input file "./on-board-b3.hex"
avrdude: input file ./on-board-b3.hex auto detected as Intel Hex
avrdude: writing flash (2402 bytes):

Writing | ################################################## | 100% 4.12s

avrdude: 2402 bytes of flash written
avrdude: verifying flash memory against ./on-board-b3.hex:
avrdude: load data flash data from input file ./on-board-b3.hex:
avrdude: input file ./on-board-b3.hex auto detected as Intel Hex
avrdude: input file ./on-board-b3.hex contains 2402 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 4.44s

avrdude: verifying ...
avrdude: 2402 bytes of flash verified

avrdude: safemode: Fuses OK (H:FF, E:CD, L:D2)

avrdude done.  Thank you.

As for playing DSD512 with BBB/Hermes/Cronus as NAA, however, this firmware update had little effect and tidal occurrence of bursting noise, though not strong, remained persistent.

Prior to the results above, I assembled a new kit of B3SE delivered from you a week ago and found that the new firmware for B3SE with BBB/Hermes/Cronus, though well working in ordinary setting, had also little effect on the removal of the noise in DSD512 with async mode.

In sync mode with a uFL cable routed from MCK on the Cronus, the tidal noise appeared to vanish, though alternated by continuous signal drop of very short interval. If controlled by I2C script by miero, the situation may change but I did not try it.

In summary, it's my impression that playing DSD512 by HQ player is quite stable as long as BBB/Botic with original pin mapping is used as NAA but becomes somewhat difficult with Cronus reclocking, whether B3(SE) in sync or async.

Regards,

Russ White · 2016-08-11 1:17 pm

What clocks and dividing scheme are you using? I have no issues playing DSD512 with 50Mhz or 100Mhz range clocks via BBB/Hermes/Cronus in either sync or async. I have also gotten several responses from others doing the same.

Please keep in mind you don't want the DPLL to be low or none - you want it to be high or max when running in sync mode. This is because the DPLL just need to freewheel with the input.

twluke · 2016-08-11 3:35 pm

Russ White said:
What clocks and dividing scheme are you using? I have no issues playing DSD512 with 50Mhz or 100Mhz range clocks via BBB/Hermes/Cronus in either sync or async. I have also gotten several responses from others doing the same.

45/49 with JE2 when async-ed. No divider when sync-ed with the same clocks, though set to 22/24 on snd_soc_botic.clk_44k1/48k.

have no issues playing DSD512 with 50Mhz or 100Mhz range clocks via BBB/Hermes/Cronus in either sync or async. I have also gotten several responses from others doing the same.

Do you mean BBB/Hermes/Cronus as NAA for DSD512 upsampled by HQ player or origijnal DSD512 sources? I suppose the latter could not be directly played by BBB/Botic/Hermes/Cronus.

In case of sync mode, I think that the divider on the Cronus will not work because the MCK directly reflects the actual clock rate, leading to software control by kernel option to use as NAA. Also, I remember that miero once wrote that the clock rate more than 90Mhz is difficult to control by kernel option. So the selection of the clock rates may be limited to around 45/49 when sync-ed.

Please keep in mind you don't want the DPLL to be low or none - you want it to be high or max when running in sync mode. This is because the DPLL just need to freewheel with the input.

Thank you for kind suggestions. I've tried them before but could not get good results. Of course this is the issue only pertinent to using as NAA.

Regards,

Russ White · 2016-08-11 3:44 pm

1) Not sure what NAA means

2) I have never used HQ player. I am talking about studio sourced DSD512

3) 90mhz clocks work just fine - you just divide by 4 instead of two for the clock going to the BBB (so it always gets ~25Mhz).

Russ White · 2016-08-11 3:47 pm

Keep in mind - the divider on the Cronus only divides the clock going to the BBB - not to the FFs and the DAC.

twluke · 2016-08-11 4:08 pm

Russ White said:
1) Not sure what NAA means

2) I have never used HQ player. I am talking about studio sourced DSD512

Quite relieved. You can be better off without this NAA (network audio adapter named by the author of HQP).

Regards,

caad · 2016-08-20 9:36 pm

DSD512 on ES9018

Hi..

The Usb Interface from Amanero plays DSD512. The running clock for DSD 512 Clock is 22/24MHz . Note that the Clocks on amanero is 22/24MHz

DSD64 (SACD) = 2.8MHz
DSD128 =5.6MHz
DSD256=11.2MHz
and
DSD512=22.4MHz

Im using the Amanero and the ES9018 and have no issues running DSD512 on windows. On Linus/Apple only up to DSD128 is possible.

Br
Caad

Russ White · 2016-08-20 11:12 pm

Try a different player - I have no issues playing DoP encoded DSD512 on Linux(via mpd) or Mac(via several sources)

twluke · 2016-08-21 2:00 am

caad said:
Hi..
The Usb Interface from Amanero plays DSD512. The running clock for DSD 512 Clock is 22/24MHz . Note that the Clocks on amanero is 22/24MHz

Hi Caad, thank you for this info. Right now I've confirmed that the bare Amanero Combo384 (version 1.0.57) board does work well without noise in playing upsampled DSD512 sources from HQ player in native mode on my B3SE.

Regards,

twluke · 2016-10-23 11:05 am

Hi Russ, sorry for bringing back to this older comment of yours:

Russ White said:
What clocks and dividing scheme are you using? I have no issues playing DSD512 with 50Mhz or 100Mhz range clocks via BBB/Hermes/Cronus in either sync or async. I have also gotten several responses from others doing the same.

Recently I have found a DSD512 source (a dsf file, not upsampled) and confirmed that my B3SE can play it without problems (using Hermes-BBB/Cronus-45/49). This was a good news to me, quite convincing me of your comment above and also the capability of ES9018 playing a real DSD512 source.

However, here is an issue. This DSD512 play occasionally suffers from a noise similar to pink or white noise, which decays away after seconds or a minute. This usually occurs when getting started with the source after B3SE on and appears to be caused by the DAC trying to adjust the sample rate to the clock. BTW my setting is async with DPLL to the lowest and SPDIF off via I2C.

Please follow this link to download a zip file including a set of recorded speaker sounds of this DSD512 source, flac-formatted, with and without noise by my room microphone. I will be happy if I can know the actual source or background of this noise and perhaps solution.

Regards,

nautibuoy · 2016-10-23 2:27 pm

twluke, I get 'page not found' with your link to your zip file of 'the noise'?

Ray

Russ White · 2016-10-23 3:38 pm

@twluke

What firmware are you using?

Another thing to check would be the wiring from the Cronus to B3SE and power supply. Any chance I could see a picture of that wiring?

twluke · 2016-10-23 3:58 pm

nautibuoy said:
twluke, I get 'page not found' with your link to your zip file of 'the noise'?

Ray

Oh, sorry for this inconvenience. The proper URL is:

lydia.concorde.gr.jp/luke/dsd512.zip

Regards,

twluke · 2016-10-23 4:31 pm

Russ White said:
@twluke

What firmware are you using?

I have a latest firmware but it is not used for now because I prefer I2C control using miero's script.

Another thing to check would be the wiring from the Cronus to B3SE and power supply. Any chance I could see a picture of that wiring?

A photo was attached to this post. The Cronus is first connected to Otto II and then to B3SE. I don't think this can be an issue. But I've been thinking that the power supply to the B3SE, BBB and Cronus (together with Otto II and Teleporter) may cause a problem because the cables were routed from the separate PS box as a "single" cable as a whole using DIN connectors.

Regards,

twluke · 2016-10-23 4:56 pm

twluke said:
But I've been thinking that the power supply to the B3SE, BBB and Cronus (together with Otto II and Teleporter) may cause a problem because the cables were routed from the separate PS box as a "single" cable as a whole using DIN connectors.

Here is the photo of PS box.

MWL168 · 2016-11-06 2:44 am

Russ White said:
Try a different player - I have no issues playing DoP encoded DSD512 on Linux(via mpd) or Mac(via several sources)

Hi Russ:

What media player(s) did you use to play DoP encoded DSD512 files on Mac? Can I assume that the B II has this same capability?

What about the Amanero/Cronus? Do I need specific Amanero firmware?

Thanks!

DSD512 on Buffalo IIIse

Member

Member

Member

Member

Member

Member

Member

Member

Member

Member

Member

Member

Member

Member

Member

Member

Member

Attachments

Member

Attachments

Member