0

Identify SPDIF/TOSLINK input sample rate via ALSA

Francois Simond

March 09, 2018 13:35

None

Follow

Hi HifiBerry community!

I'm building a software DSP which handle digital input at various sample rates.
An example of use case is recording a Chromecast Audio's output which typically varies beteeen 44.1k for streaming services, 48k for device casting, 96k and 192k for high res audio.

I'm prototyping with the Terratec AUREON XFIRE8.0 HD USB sound card which happily sends buffers to ALSA at whatever speed according to the input signal regardless of the sample rate requested to the recording API.

How would the Digi+ behave in that case:

• Will the input sample rate change trigger an error?
• Is identifying the input sample rate possible by iterating over all common sample rate until success?

• Facebook
• Twitter
• LinkedIn

22 comments

• 0
  
  HiFiBerry team March 09, 2018 15:09

  Hi,

  unfortunately afaik, there is no easy way for this. There is an unofficial patch to the Digi+ driver that dumps some registers into a file in /proc file, but you would have to create your own kernel and read this file. 
  
  I would recommend a hardware DSP instead like we do it on our Beocreate board:
  https://www.hifiberry.com/beocreate/

  Best regards
  Daniel

• 0
  
  Francois Simond March 09, 2018 16:46

  Hey Daniel!
  Thanks, I was able to find the previous discussion and and the patch mentioned.
  https://github.com/antorsae/linux/commit/de332819b2226931478c2ec80b89c7425049a72e

  What do you think about providing the sample rate via procfs or sysfs now?
  I understand than previously digital wasn't an official feature, but it is now.
  I'd guess that although it's something missing in ALSA API, a file exploring the input rate in a file, with a method for the user space app to be aware of changes would do just fine.

  I'll need a few more months a development but do you think it could make it into the Pi's default kernel?
  Otherwise If I write this patch myself, will you be bake to push it into the standard kernel distribution?

  Last question: at the moment what happens if you record form ALSA at 48k while the SPDIF clock is 44.1k: do the sample simply arrive slower or is the signal garbled?
  On a Wolfson Audio Card, it's garbled as the clock set by ALSA overrides the SPDIF input one.

  Concerning the Beocreate, it looks really awesome and I'll probably get one at some point to play with Sigma Studio but I'd like to have more flexibility in signal processing and I/O.

• 0
  
  HiFiBerry team March 09, 2018 16:59

  Hi,

  we do not plan to integrate this patch. However, as anybody can write patches and create pull requests, feel free to do so. However, it will definitely need some cleanup until it gets accepted by the kernel maintainers.

  Using the wrong sample rate can result in garbled data, but also in a hanging system (if you try to sample faster than the source provides data).

  BTW: I wouldn't create a DSP toolkit that works on different sample rates. It will become quite complex as most things will depend on the sample rate. With simple things like IIR filters, you might be able to adapt these to multiple sample rates, but when you start with FIR filters, there is no easy way to convert them.
  Using modern resampling technologies will makes things much more easier without any negative impact on sound quality. The ASRCs that we're using in the Beocreate board already have a signal-to-noise ration >130dB (can't remember the exact number, but you'll find it in the datasheet of the DSP). That's a lot more than the dynamic range of any real-world audio system. If you feel you really need 192kHz, just use this as the DSP sample rate and upsample everything to 192kHz.

  Best regards,
  Daniel

• 0
  
  Francois Simond March 09, 2018 17:52

  Yes this patch exporting the registers is not providing a nice API, I understand your rejection: it can be done better.
  Okay so I'll order 1 DIGI+ I/O and look into how to write this :)

  Thanks for the kind suggestions on the DSP architecture!
  Yes indeed just like hardware solutions, my soft DSP will use an asynchronous resampler on all inputs (it'll support multiple analog/digital inputs with automatic switching). The processing  happens at a fixed sample rate, determined by the output clock just like you describe.

  It's a side project to train on signal processing and Rust language which is well suited for this. Currently I'm porting zita-resampler and the ASRC will be inspired by Zita-ajbridge.
  Later I hope to port r8brain-src because it's so good, but its codebase is a lot more complex than zita-resampler.
  The UI will be web, making REW filter use simple.

  If I succeed it'll be for similar use cases as the Beocreate, although not as low latency but cheaper and all open source, and still using your boards ;)

  Edited by Francois Simond March 09, 2018 17:55
• 0
  
  Francois Simond March 16, 2018 12:47

  I just received the DIGI+ I/O :)
  
  A quick test confirms what you described Daniel, capturing at the wrong sample rate results in getting garbage or an I/O error.
  
  I'll look into sample rate detection next!

• 0
  
  Francois Simond March 19, 2018 14:47

  I found issues with this patch
  https://github.com/antorsae/linux/commit/de332819b2226931478c2ec80b89c7425049a72e

  - capture above 48000 Hz have clicks in them
  - capture at 192000 Hz fails.

  Instead I'm gonna try to implement only one feature, which is to report the RX sample rate in /proc/asound/sndrpihifiberry/rx_rate.

  The usage would be, within my software dsp:

  - read rx_rate before starting capture
  - start capture providing the right sample rate in hw_params
  - if the EX sample rate changes, the capture stops with an I/O error (current behavior observed)
  - read rx_rate again, etc

   

  Daniel, does that make sense?

  Edited by Francois Simond March 19, 2018 14:49
• 1
  
  HiFiBerry team March 19, 2018 16:20

  Hi,

  In general it makes sense.

  When the I/O error happens, sometimes sampling doesn't work anymore. We haven't tested this for quite a long tie, therefore I can't say if this behaviour has changed.

  Best regards,
  Daniel

• 0
  
  Francois Simond March 20, 2018 02:28

  I got it working as described :)

  One limitation is that it can't detect 88200 / 17600 / 192000 rates; not sure why: any idea?
  I'll continue with the prototype and stress-test it.

  Daniel, it looks like when tracking the received sample rate and stopping the capture when it changes - before the I/O error is triggered after 10s - things appear to continue working well.

  One extra bonus feature gained: by polling the rx_rate file, it's possible to start recording just when a signal is received.
  In my current patch the rate reported goes from 0 to 48000 (or another rate) when something's played then back to 0 when it stops.

  So that should work out well!

  Edited by Francois Simond March 20, 2018 02:28
• 0
  
  Manuel Weichselbaumer March 22, 2018 06:02

  Hi Francois,

  I am working on something very similar to your project, so nice to meet you. :)

  I wrote a software based DSP solution which consists of the following parts:

  - a daemon running on Raspberry Pi with the DIGI+ I/O board

  - a Desktop/Mobile App to remote control the DSP

  Since i ran into the same issue as you (detecting sample rates of the SPDIF signal at the Digi I/O board) this could be the starting point to share some work. Please have a look at my project:

  https://github.com/mincequi/cornrow

   

  Best regards,

  Manuel

  Edited by Manuel Weichselbaumer March 22, 2018 06:02
• 0
  
  Francois Simond March 22, 2018 12:31

  Hello Manuel, nice to meet you too!
  It seems both our last comments are hidden (pending approval) - mine has been after I edited it to fix typo/formatting.

  Yes our goals are similar, and our projects will certainly be more usable with working input sample rate detection.
  Without this feature I wouldn't use or recommend this board (instead, a USB card which captures without corruption at all input sample rates regardless of ALSA's hw_params)

  In my last message that'll hopefully appear again later I wrote that I got the detection working 2 days ago.

  Here's a first version of the patch to share with you :)
  https://github.com/supercurio/raspberrypi-linux/commit/484b9eab8d02eaccd1475920c173fe4c126aa1e6

• 0
  
  Yanava March 27, 2018 20:16

  Hello Guys, I'm currently working on something quite similar for my company. We've developed a board around the WM8804 and are using the Kernel drivers. 

  Our goal is to get the input signal from various commercial devices, so sample rate might change along the capture. Detecting changes on the sample rate is imperative for our work to succeed. 

  One problem we're facing here is that when the sample rate changes and you get the I/O error, reopening the device does not yield correct bytes at the output. To test this I'm using two RPi3 equipped with HiFi Berry Digi IO. Output of one is connected to the input of the other.

  I execute speaker-test with a sine wave of 440Hz and a sample rate of 44100, while using arecord with the same rate on the other end. Everything works as expected. If you need resampling, you can use alsa's plug funcionality. 

  If at any point I interrupt speaker-test on one RPi, the data on the other stops increasing (expected). If I restart speaker-test with the same parameters, the data recorded increases again.

  If, however I change the sample rate of speaker test to 48000, the capturing device will have an error. Stopping arecord and restarting with the correct parameters (48000 sample rate) does not restablish the flow of bytes. I got to restart the device in order for this to work.

  Any ideas on how applying this patch and reading the sample rate might work when the sample rate might change during capture? This could happen in a lot of home devices. We have a media player here that uses whatever rate the .mp4 / .ts file has to the output stream, so it is a real life application to consider as well. 

  In any case, I'm willing to collaborate (even coding, whenever necessary) to make this work for my application (and perhaps for yours). Not a kernel dev, but I know my way around C code. 

• 0
  
  Francois Simond March 27, 2018 20:41

  Hello Yanava!

  Very common use-case indeed.
  
  Try to adapt the patch for your need, it should be fairly easy!
  
  In my tests it allows to handle the case you describe, but you need a userspace application polling rx_rate regularly.
  The trick I found is to stop recording before reaching the failure.

  I tried to describe how to use rx_rate in the commit message that way, is there more that could be clarified?

   

• 0
  
  Francois Simond March 27, 2018 21:42

  I'm afraid this forum is not suitable for discussion, every message I post get delayed significantly for manual approval, it's a bummer.

• 0
  
  HiFiBerry team March 28, 2018 04:57

  @Francois: Sometimes the spam classification is wrong. However as we had a lot of problems with spam in the past we can't just disable the spam filter. The filter is trained automatically, so it should get better.

  Best regards,
  Daniel

• 0
  
  Manuel Weichselbaumer April 05, 2018 19:12

  Francois, i tried your kernel patch and i have to say: works like a charm!

  The only thing, i believe is not too nice is, that we have to poll for changes.

  Do you see any chance, to signal rate changes via HW interrupts to user land? I am not a kernel hacker, so i do not have any clue, how the current hifiberry-digi+ and/or wm8804 driver(s) are implemented. Do they actually handle interrupts? Can these be provided to user land via UIO (userspace i/o)?

• 0
  
  Yanava April 05, 2018 19:50

  Hello Manuel.

  Good to know that the patched worked for you as well. I have done some modifications to it to dump just the RX frequency. However, I found out that, with all due respect to the HiFiBerry folks, this driver has quite incomplete implementation of the WM8804 datasheet recommentions. 

  First, the hw_params function never sets up the PLL, so I don't know how it is handling mode changes from 32/44.1/48/96 to 192kHz. Actually the hw_params routine barely addresses RX (it simply turns it on), so I have no idea why capture even works. The patch provided by Francois addresses this, but unfortunately it has the limitations pointed by him (capture at higher rates fails). 

  There are also some undefined behaviors in this driver, for instance: if you're not recording anything, does passthrough from RX to TX even work? Because the RX hardware is turned off when you're not recording. Should it in this use case? 

  The patch provided by Francois also does not take into account if RX is on, so it will report 44.1kHz even if you're not recording. anything. From a program flow, this might be problematic, as you may want to detect the frequency going in prior to you starting to record.

  Also, the datasheet is pretty strict on how to conduct sample rate changes and none of this is ever followed by the platform driver. 

  Due to all of this, I'm evaluating the driver altogether and thinking of patching it heavily to be a little bit better for my application. If the changes are good enough, I might submit a pull request (don't want to put up with kernel dev requirements) or share the driver somehow. We can take this discussion elsewhere and work together on defining appropriate behavior. 

  As for your question, there is a slight problem: I have worked with audio and DSP throughout all my carreer, but I'm not an ALSA expert. I don't have a good practical idea to do that from the driver. The hw_params function, which sets the device up for recording/playback seems to be called upon stream open in your application software, so if the sample rate changes, you would have to close your recording platform and open it again with appropriate sample rate values. 

  If anyone knows a way to do this from the driver, including the original devs, I'm offering a few hours to work on this and provide a solution. I'm just not an ALSA dev, but I know a bunch about audio and C code. 

   

   

• 0
  
  Yanava April 06, 2018 23:28

  I figured out why capture works correctly and why you should not rely entirely on the patch. In theory, there should be no distinction between TX and RX, you should set PLL values regardless, whenever you receive a command to open the device to do something. 

  However, there must be a bug somewhere. Using the original driver, if I manually set the interface sample rate to let's say 44100 on asound.conf, so I can take advantage of resampling done by ALSA (plug interface), the indicated sample frequency that should reflect the recovered value comes populated by 44100, even though the actual incoming frequency is 48000 or eve 32000. I haven't been able to determine why this is the case, but if anyone wants to verify, these are the steps:

  1. Don't apply the patch, but rather just copy the functions that dump the register and creates the callback
  2. Leave the hw_params function untouched
  3. Compile and install
  4. Have an input stream on 48000 or 32000
  5. Use the following asound.conf below
  6. Set up arecord on the RPi to use -r 48000 (so you will resample from 44100)
  7. Connect the input stream
  8. Open the registers file created on the appropriate directory

  asound.conf

  pcm.!default {
  type hw card 0
  }
  ctl.!default {
  type hw card 0
  }

  pcm.spdif_resample {
  type plug
  slave {
  pcm default
  rate 44100
  }
  }

• 0
  
  Francois Simond April 07, 2018 19:32

  Hey Manuel, happy to learn it works for you as well :)

  And yes I agree, polling in order to monitor for lock/unlock and sample rate changes is not optimal.
  Ideally, this would be possible via ALSA API, which is not the case only via the PCM recording commands.

  But leveraging the Mixer API, DAPM, or even JACK controls / ASoC jack detection should be a better design I'm sure.
  Probably, exposing unlock/lock status as a switch, then the sample rate as a slider might be the cleanest option.
  Then the program should listen to mixer value changes.

  The WM8804 datasheet indeed lists UPD_UNLOCK, UPD_NON_AUDIO, UPD_REC_FREQ as available interrupts.
  I've never written code for that before, but you're right it's probably proper way to do that.

  Something to look into for sure.

  Edited by Francois Simond April 07, 2018 19:33
• 0
  
  Francois Simond April 07, 2018 19:43

  Hello Yanava, thanks for testing and providing feedback on the the patch also.

  About your first message:
  I designed the patch to gain the ability to detect the sample rate before a program starts capture (it would be useless otherwise).
  When you read the rx_rate file, it configures the receiver for sample rate detection only, as specified in the Datasheet - unless the receiver is already locked on an input. In that case, it reports the current sample rate, which is known.

  Same as you, I don't get why things work with your ALSA resampler example :P

• 0
  
  Manuel Weichselbaumer April 09, 2018 16:31

  Hey Francois,

  yes, something like this sounds reasonable. However, polling is acceptable as well and i will continue using this approach. Once someone finds the time, we could have the interrupt based solution.

  Just had a look at your github page and saw your project plans for multiDSP. Quite ambitious, really ambitious :)

  Let me just share my project status: i am almost there!

  I have a daemon up and running which can be controlled via my android/ios app:

  

   

  Suggestions welcome :)

• 0
  
  HiFiBerry team April 10, 2018 06:36

  Hi Manuel,

  this looks very cool. Tuomas from B&O is working on something similar for the Beocreate. It will also be released as open source once it is finished.

  Best regards,
  Daniel

• 0
  
  Aris Theocharides April 13, 2018 05:08

  The ability to accurately and reliably identify the receiving rate on the DIGI+ I/O will make Digital Room Correction via Brutefir a viable option with rate switching.

   

  Thank you!