Buffalo IIISE DSD playback issue - nasty POP sound

[vortecjr]

I'm using a Buffalo IIISE fed via i2s. The file is an original DSD download and not some SACD rip. The source is a USB to i2s converter with i2s and DSD multiplexed. When I start playback I get a nasty POP sound. I asked a friend who knows a lot about the Sabre32 chips and he provided the following.

"The buffalo has an 8ch DAC that is configured to be 2ch on the outputs via the pcb board. The problem is that the input routing needs to be different for DSD than PCM. When going to DSD, you have to feed the signal into at least 3 of the inputs which you don't have available on the buffalo unless you lift legs and solder wires. As it is now, 4chs worth of DACs are floating with no input. The noises you hear is a side effect of the working DACs being tied to the other dead DACs. Beyond this correction needed, the software into the DAC needs to be told to source the DACs for channels 5-8 to be different than default."

Russ, can you provide additional insight?

[Russ White]

Have you tried reading the integration guide? The inputs of the B3SE are correctly mapped for both PCM and DSD. I listen to DSD music frequently.

[vortecjr]

Originally Posted by Russ White

Have you tried reading the integration guide? The inputs of the B3SE are correctly mapped for both PCM and DSD. I listen to DSD music frequently.

I assume your using USB converter. Are you using as your player?

[Russ White]

I am usually taking DSD directly from a SACD player via a Teleporter module.

[vortecjr]

Originally Posted by Russ White

I am usually taking DSD directly from a SACD player via a Teleporter module.

First, let me say that I can listen DSD and it sounds great. The issue is only the POP at the start and stop of playback.

Second, my Buffalo IIISE is set to receive i2s and DSD multiplexed over the same signal path and wired per the user manual. The dip switch is set to DSD and the Sabre chip is auto detecting PCM and DSD. The source is a computer driving a USB to i2s/DSD interface.

I have been conducting some tests today and here is what I found:
P = player, USB = USB to i2s/DSD interface board, DAC1 = Buffalo IIISE, DAC2 = not a Buffalo DAC, but that same chip.

Test #1 - P1 -> USB1 -> DAC1 = POP at start/stop - None of the components fix the POP.

Test #2 - P2 -> USB1 -> DAC1 = No POP at start/stop - The player has some kind of software fix. It works, but it's not a global solution being a player specific fix.

Test #3 (my friends test) - P1 or P2 -> USB2 -> DAC1 = Low level tap sound at start/stop - The USB interface has some kind of fix in it's processor. It works, but it's not a global solution being an interface specific fix.

BTW I know for a fact that USB2 is doing some kind of soft start because I know the designer.

Test #4 - P1 -> USB3 -> DAC2 = same results as Test #1 and #2 until the hardware fix I mentioned in my first post was used. Then No POP at start/stop. This is a proper fix because it's a global fix at the hardware level.

Is the mapping from my first post possible on the Buffalo IIISE or Buffalo III?

[TBM]

Hi

Perhaps a tip?
I have not made a sw DSD player, but I have made a sw wav player.
Wav players have to skip the first 44 bytes of header info to come to real audio data. Playing wav file from byte 0 and thus playing header data as audio data gives you a big pop. I did try it at low volumes, scratched my head a bit, before I understood why and fixed it...
This could be something different though. Just thought to mention it. Good luck.

Cheers

[Russ White]

This has nothing to do with the DAC itself.

The problem is upstream - you need to address it there.

The B3 and B3SE both correctly route stereo DSD if setup in remapping mode (which the B3SE always is)

People have been using the Buffalo this way since the first one.

[Russ White]

One thing that is important for a DSD source - is that if it is using the DSD over PCM encoding the player must not send the initial PCM samples, or the DAC will correctly detect the PCM and try to play it. It needs to intelligently put the samples in a FIFO and only play them if they are not DSD encoded. Many do this too late. It is an implementation flaw.

[vortecjr]

Originally Posted by TBM

Hi

Perhaps a tip?
I have not made a sw DSD player, but I have made a sw wav player.
Wav players have to skip the first 44 bytes of header info to come to real audio data. Playing wav file from byte 0 and thus playing header data as audio data gives you a big pop. I did try it at low volumes, scratched my head a bit, before I understood why and fixed it...
This could be something different though. Just thought to mention it. Good luck.

Cheers

What your describing happens when a player sends the complete files to the device. I can tell you that P1 above is not doing that. P1 knows the difference between PCM and DSD. DSD is parsed out and encoded with DoP so it's not sending PCM. I know this because I helped implement the feature.

[vortecjr]

Originally Posted by Russ White

One thing that is important for a DSD source - is that if it is using the DSD over PCM encoding the player must not send the initial PCM samples, or the DAC will correctly detect the PCM and try to play it. It needs to intelligently put the samples in a FIFO and only play them if they are not DSD encoded. Many do this too late. It is an implementation flaw.

Russ, look at the test data above and consider this. The USB converter in test #1 and #2 is receiving DoP in both cases. It only works on test #2 without a POP because the player is doing a software fix. When your USB converter comes out it will also be subject to the POP if you let the solution come from the various players. I'm asking you to consider the fix in test #4 so it won't matter what player and or converter is used and no POP will ever happen. BTW the information resulting in the successful implementation of the fix (refer to post #1) in hardware came from ESS after they were asked several time about the issue.

How do you switch between PCM and DSD on your device?