• Disclaimer: This Vendor's Forum is a paid-for commercial area. Unlike the rest of diyAudio, the Vendor has complete control of what may or may not be posted in this forum. If you wish to discuss technical matters outside the bounds of what is permitted by the Vendor, please use the non-commercial areas of diyAudio to do so.

DSD512 on Buffalo IIIse

Status
Not open for further replies.
Jump to Latest
#41
#43
twluke said:
switching to SPDIF using a dual pole single throw switch did not work.
Click to expand...

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
Click to expand...

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
 
#44
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
Click to expand...

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,
 
#45
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.
 
#46
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.
Click to expand...

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.
Click to expand...
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.
Click to expand...
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,
 
Last edited:
#50
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
 
#52
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
Click to expand...

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,
 
Last edited:
#53
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.
Click to expand...

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,
 
#57
Russ White said:
@twluke

What firmware are you using?
Click to expand...

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?
Click to expand...
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,
 

Attachments

  • photo.jpg
    photo.jpg
    432.4 KB · Views: 268
Status
Not open for further replies.
Top Bottom