0

Poor frequency response on DAC+ DSP card

Paul Skirrow

November 26, 2024 16:38

None

Follow

We're testing the DAC+ DSP card using our own C code using the Alsa driver on a Raspberry Pi 5 opening the device as:

      plughw:CARD=sndrpihifiberry,DEV=0

We are using our own C code to generate sine waves at different frequencies and we get extremely good results from the HiFi Berry DAC+ ADC Pro card which gives a very flat frequency response. 

However, when we test the TOSLink output on the DAC+ DSP card connected to the TOSLink input we get a poor frequency which varies by +/-7dB as shown in the frequency response plot below. 

It appears that there may be a default filter that is processing the output from our code before outputting via TOSLink. We also find the analogue output on the card gives the same result. 

If this is the case, is there a way to disable this filter please?

Do we need to use DSP Toolkit? 

Is it correct to use the plughw: interface or is that imposing a filter please?

I hope you can help as we have been delighted with the performance of the DAC+ ADC Pro card and was hoping to see similar results from the digital card. 

Hope you can help,

 

• Facebook
• Twitter
• LinkedIn

11 comments

• 1
  
  HiFiBerry team November 27, 2024 08:07

  plughw is generally a bad choice as it will do some "magic" internally converting sample rates and formats.use the hw device.
  
  What DSP program do you use?

• 0
  
  Paul Skirrow November 27, 2024 13:38

  OK, thanks. Will try that again, but it produced lots of debug output from the driver last time we tried. Will investigate more thoroughly. 
  
  We're using a Raspberry Pi 5 with default OS, Alsa driver and our own code which is implementing our own algorithms for digital filtering. 
  
  Do you mean what code are we running on the built-in DSP? We haven't changed that. How can we control it and what are the options?

  Edited by Paul Skirrow November 27, 2024 13:39
• 0
  
  HiFiBerry team November 27, 2024 14:50

  The easiest way to install a DSP program is to boot HiFiBerryOS (https://hifiberry.com/os) and install the DSP profile from the UI. Otherwise you need to install DSPToolkit:
  https://github.com/hifiberry/hifiberry-dsp
  
  The driver does not produce any debug output. If you get lots of this, it's probably your own software or some audio library or middleware that you're using.

• 0
  
  Paul Skirrow December 11, 2024 23:31

  We still have the problem with very poor frequency response when receiving 48kHz audio via the optical input on the DAC+ DSP card and it appears some processing is being applied before we read the data. 

  We are using the recommended script to enable the optical input:

  # ASRC6: Input from SPDIF
  dsptoolkit write-reg 0xF106 0x0003
  
  # ASRC6 output rate: SDATA_OUT3
  dsptoolkit write-reg 0xF146 0x0004
  
  # SOUT SOURCE20/21: ASRC6
  dsptoolkit write-reg 0xF195 0x0000
  dsptoolkit write-reg 0xF194 0x0033
  
  # SDATA_OUT3 configuration: clock slave
  dsptoolkit write-reg 0xF21C 0x6C40

  We are using the following command to open the optical input device:

  snd_pcm_open(&handle, "hw:CARD=sndrpihifiberry,DEV=0", SND_PCM_STREAM_CAPTURE, 0);

  We don't want the DSP to perform any processing - we just want the raw input without any filtering. 

  However, when we read from the card using snd_pcm_readi() we appear to be receiving filtered audio which suggests a DSP profile may be operating.

  The input is a pure sine wave of fixed amplitude and variable frequency. We know from testing with other equipment that the input stream is correct and definitely fixed amplitude. 

  How can we completely disable the DSP and read raw PCM data from the optical input?

   

   
• 0
  
  HiFiBerry team December 12, 2024 05:56

  > How can we completely disable the DSP and read raw PCM data from the optical input?
  
  This is not possible. All data has to pass through the DSP and there will be always an ASRC in the signal path to convert between the sample rate on the Pi and the sample rate of the SPDIF input.

   

• 0
  
  Paul Skirrow December 12, 2024 18:00

  Thanks for the quick reply. 
  
  We're using a 48k samples per second S/PDIF input stream (stereo PCM, 16 bits per channel) and the Raspbian Alsa driver is configured to use 48k samples per second so no sampling rate conversion is necessary:

  sample_rate = 48000;
  ret = snd_pcm_hw_params_set_rate_near(analyser_handle, hwparams, &sample_rate, 0);

  In this scenario I would expect to be able to read the raw input stream "bit-perfect" without any processing by the DSP. 

  Are you suggesting that even in this mode the DSP is still doing some processing? That would explain the issues we are seeing. 

  Is it possible to read the raw input stream without any processing or is that just not supported by the DAC+ DSP board?
  
  If it's possible using a custom profile is there any reason why HiFi Berry doesn't provide such a profile as it is surely an obvious use case? Can you provide any guidance or documentation that would enable us to do it?

   

• 1
  
  HiFiBerry team December 12, 2024 18:25

  > In this scenario I would expect to be able to read the raw input stream "bit-perfect" without any processing by the DSP. 
  
  No, this is not correct. If you run two independent clocks, they never will be in sync, even if both are "48kHz". One clock will alway run faster than the other. As SPDIF is always a clock master and the Pi also is on the DAC+DSP, there is always a sample rate conversion required (this is one of the reason, so called "re-clockers" who try to use an independent clock that's not in sync with the original clock are not a good idea)

  Even with two clocks at 10ppm difference, this would mean one full sample (not just one clock cycle) shift in these 2 clocks every 2 seconds.
  
  If you just want to read samples without any conversion, the Digi+ I/O can do this as it runs as a clock slave. However, this has some implications on the software: 
  As there are no conversion, you need to know exactly what the input sample rate is and you need to make sure that the clock is present. If you try to read data at an incorrect sample rate or no external data is present, the recording won't just hang, but the whole ALSA stack will block and you need to reboot the system. 
  
  BTW: We also offer professional services to help you not just selecting the best board for your application, but also helping you creating the software (could be a custom DSP program or support with your Linux application). If this is interesting to you, just send us an email to sales@hifiberry.com

  Edited by HiFiBerry team December 12, 2024 20:04
• 0
  
  Paul Skirrow December 13, 2024 18:51

  Thanks for the helpful reply. The issue of mis-aligned clocks makes sense and I appreciate sample rate conversion would always be necessary when running asynchronous clocks. 

  Can you clarify the clock behaviour please? I think many of your example assume a S/PDIF input that is processed to generate an S/PDIF output. We are developing an audio test system so we are generating test tones via the S/PDIF output passing them through the equipment under test and receiving via the S/PDIF input. 
  
  With the DAC+DSP card using the above script to enable S/PDIF input, I see the script includes this line:

  # SDATA_OUT3 configuration: clock slave
  dsptoolkit write-reg 0xF21C 0x6C40

  This would suggest that the S/PDIF input is working in slave clock mode, where the clock is derived from the S/PDIF input stream but your message above suggests this isn't the case?

  Can we configure the S/PDIF input to operate in slave clock mode and sync to the S/PDIF input stream?

  Would this affect the S/PDIF output clock or is that independent?

  Can you point me at any documentation that clarifies the clock behaviour please?

  We've tried running the Pi with 48kHz and 96kHz input clock with a 48kHz input stream but get the same frequency response in both cases. 

  Would you expect the ASRC to impact the frequency response in this way (is it an artefact of the sample rate conversion) or would it appear that the DSP is applying a filter that has this effect?
  
  Do you have any DSP profiles that provide a flat response please?

  We are using Raspbian (Debian 1:6.6.51-1+rpt3 (2024-10-08)) on a Raspberry Pi 5 and I understand there may be some issues with clock configuration on the Pi 5 but we don't have the full details. 

  Many thanks.

• 1
  
  HiFiBerry team December 16, 2024 07:41

  SPDIF output always runs with the DSP clock frequency. 
  An SPDIF input is always a clock master. That's how SPDIF works.
  
  To understand the clocking of the whole circuitry you need to:

  1. Understand the details of the DSP. Check the ADAU1451 data sheet for this
  2. Load and understand the DSP program. You can find this here: https://github.com/hifiberry/dspprofiles/tree/master/dac%2Bdsp
  
  There isn't a single clock domain, but at least three:
  - The Pi's I2S clock
  - The DSP's clock
  - The SPDIF clock
  
  They all are independent and require the use of sample rate conversion.
  
  I now realize that you're probably trying to play and record to/from SPDIF simultaneously. The DSP program was never designed for this use case. As SPDIF input will be routed to the output, with your setup you will create a feedback loop which will result in all kinds of crazy behaviour. 
  
  You can try to "dacdsp_nothing" profile, but even with this, there will be sample rate converters be used. Also note that a sample rate converter always has to use a lowpass filter below the clock frequency. Otherwise slight variations of the sample rate would result in aliasing artifacts as it could be higher at one point in time and lower at another time.
  
  As I wrote before, we can offer professional services, for your design as a paid service. Running SPDIF input and output without sample rate conversion would not just require another DSP software, but also a different hardware design and Linux drivers. Especially when you're building measurement equipment, these things need to be looked at very carefully. The DAC+DSP is probably not the right choice for this.

• 0
  
  Paul Skirrow December 16, 2024 17:43

  Thanks again for the speedy response - we really appreciate it. 

  I now realize that you're probably trying to play and record to/from SPDIF simultaneously. The DSP program was never designed for this use case. As SPDIF input will be routed to the output, with your setup you will create a feedback loop

  Can you clarify this comment please? Are you suggesting that we can't use SPDIF input and output simultaneously due to a limitation of the card or its software?

  Our setup looks like this:

     generator thread  -> Alsa  ->  SPDIF output  ->  Device under test  -> SPDIF input  -> Alsa  -> analyser thread

  The two threads are part of the same program but run completely independently with independent timing. We do not assume they use the same clock rate (e.g. due to clock accuracy or because they may be running at different clock rate). 

  The generator thread is typically generating a continuous test tone (sine wave) which we send via the SPIDF output, typically with 48kHz sample/s. 

  The analyser thread receives the SPDIF input and measures the signal level etc. It does not route the SPDIF input to the output. 

  The device under test could be a digital recorder (such as a computer or Minidisc recorder etc), a sample rate convertor, AV receiver or a studio path. 

  We assume that the SPDIF input and SPDIF output work as completely independent devices. Is that correct and would you expect this setup to work or is there some reason why we can't use SPDIF input and output simultaneously? We are trying to play from SPDIF and receive simultaneously but the two systems work entirely independently. 

• 0
  
  HiFiBerry team December 18, 2024 09:19

  > Can you clarify this comment please? Are you suggesting that we can't use SPDIF input and output simultaneously due to a limitation of the card or its software?
  
  The DSP profile provides by us was not design for this use case. It will automaticall route incoming SPDIF audio to the SPDIF output.This won't work for your use case.
  You can try the dacdsp_nothing profile. 

  > We assume that the SPDIF input and SPDIF output work as completely independent devices.
  
  No, this is not correct. The Pi features a single soudn interface for both input and output. That means they have to run at exactly the same sample rate and sample format.