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]

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]

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]

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]

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?

 

[Russ White]

I am not exactly clear what the fix in #4 is...

The on the B3 and B3SE firmware remapping of inputs directs the DSD signals to the correct DACs. All 8 channels get fed a correct signal for DSD or PCM. It makes no difference.

What it sounds like you are doing is hard-wiring the DAC only for DSD input.

BTW with the experimental USB firmware I am working on I get no "pop" at all with DSD input into B3SE.

If the problem were with the playback of DSD itself you would see it from any DSD source.

The problematic bit is the fact that the DoP protocol is used, but because it is not detected for several samples the DAC (quite correctly) detects PCM (with a very loud signal).

 

[Russ White]

In the current implementation I switch by running all samples through a FIFO of sufficient length to detect the change before actually sending any output. This necessarily introduces a delay. In my case 32 samples.

One can fix this in the player software by making the DoP preamble look like PCM silence.

 

[Russ White]

BTW - If you use the Buf3 you can wire the inputs any way you like. You just need to remember that if you want to be able to play both PCM and DSD without rerouting you have to wire it the same as B3SE in any case.

 

[Russ White]

Also to give you an even clearer picture. In my modded Denon SACD player I simply use an OTTO-II to switch between PCM and DSD, both are routed via the teleporter to the B3SE. There are several people doing the same thing. So the issue is not in switching between PCM and DSD, it is in doing it badly. There are no issues with this approach. Changing from listening to a CD to an SACD is seamless.

I am actually not a huge fan of DoP and I may actually decide to skip it for now. I don't like the added delay and processing that doing it right entails.

 

[vortecjr]

I am not exactly clear what the fix in #4 is...

The on the B3 and B3SE firmware remapping of inputs directs the DSD signals to the correct DACs. All 8 channels get fed a correct signal for DSD or PCM. It makes no difference.

What it sounds like you are doing is hard-wiring the DAC only for DSD input.

BTW with the experimental USB firmware I am working on I get no "pop" at all with DSD input into B3SE.

If the problem were with the playback of DSD itself you would see it from any DSD source.

The problematic bit is the fact that the DoP protocol is used, but because it is not detected for several samples the DAC (quite correctly) detects PCM (with a very loud signal).

Russ, I really appreciate your help in this matter. I have it set up for SPDIF and i2s/DSD and mostly use i2s. The player may have a lot to do with the POP and that is the reason I'm looking for a global fix. As mentioned I have one player that works fine and one that does not with the same USB interface. BTW I'm using DoP into the USB interface in both cases. Unless your experimental USB firmware also has a fix the player that does not work for me will not work for you without POPs.

 

[vortecjr]

In the current implementation I switch by running all samples through a FIFO of sufficient length to detect the change before actually sending any output. This necessarily introduces a delay. In my case 32 samples.

One can fix this in the player software by making the DoP preamble look like PCM silence.

Understood.

 

[Russ White]

The DAC is behaving as it should... You are proposing hobbling the DAC for PCM for the sake of DSD. If you want to do that you can use Buffalo III. It's inputs are wide open.

I have not had any issue with any player that I have tried with my firmware so far, and I have no reason to suspect I would unless that player in faulty, in which case why would I want to use it?

I seriously doubt anyone else is doing it exactly the way I am. I wrote my own implementation.

Which player is giving you trouble?

 

[vortecjr]

Also to give you an even clearer picture. In my modded Denon SACD player I simply use an OTTO-II to switch between PCM and DSD, both are routed via the teleporter to the B3SE. There are several people doing the same thing. So the issue is not in switching between PCM and DSD, it is in doing it badly. There are no issues with this approach. Changing from listening to a CD to an SACD is seamless.

I am actually not a huge fan of DoP and I may actually decide to skip it for now. I don't like the added delay and processing that doing it right entails.

I don't have the OTTO-II. However, I tried this test with good results: I set up SPDIF into the DAC with one computer and started playback. I then setup DSD into the DAC with another computer and started playback. I switched between the two while they were playing and it works very well. No POPs to report. If you drop DoP then two of the three operating systems will not support DSD into the Buffalo with your interface. I would encourage you to support DoP and I would not fault you for any delay that makes things right!

 

[Russ White]

After thinking it through I probably will support it.

 

[Russ White]

I don't have the OTTO-II. However, I tried this test with good results: I set up SPDIF into the DAC with one computer and started playback. I then setup DSD into the DAC with another computer and started playback. I switched between the two while they were playing and it works very well. No POPs to report. If you drop DoP then two of the three operating systems will not support DSD into the Buffalo with your interface. I would encourage you to support DoP and I would not fault you for any delay that makes things right!

This test tells you everything you need to know.

The problem is not the transition at the DAC, the problem is the transition upstream.