Forum Rule: Always post complete source code & details to reproduce any issue!
Page 1 of 6 1 2 3 ... LastLast
Results 1 to 25 of 147

Thread: Audio Recording / Logging to SD card --> microSoundRecorder

Hybrid View

  1. #1
    Senior Member DD4WH's Avatar
    Join Date
    Oct 2015
    Location
    Central Europe
    Posts
    488

    Audio Recording / Logging to SD card --> microSoundRecorder

    You can find many threads dealing with this topic in the PJRC forum. I have gone through many of them and tried a lot of the given code, but unfortunately I could not find easy-to-use code which reliably records audio onto an SD card without glitches and/or missing samples. Not only me, but obviously many forum users are looking for a reliable way to record audio to an SD card.

    THEREFORE IN THIS THREAD I WOULD LIKE TO SUMMARIZE MY EXPERIENCES WITH AUDIO RECORDING TO SD CARD, GIVE LINKS TO DIFFERENT CODE EXAMPLES BY OTHER FORUM USERS AND FINALLY GIVE A LINK TO A VERY NICE SOLUTION PROGRAMMED BY WALTER, WMXZ, WHICH WORKS VERY WELL AND HAS BEEN EXTENSIVELY TESTED IN THE FIELD FOR UNATTENDED AUDIO RECORDINGS OF BIRDS AND OTHER ANIMALS.

    At first sight, recording audio to the SD card is very easy to achieve (Teensy plus audio board) with the example given in the Audio lib using the mic input of the Teensy audio board or the line input.

    https://github.com/PaulStoffregen/Audio/blob/master/examples/Recorder/Recorder.ino


    Other Teensy friends have programmed their own recording sketches using other inputs or other goals. These sketches differ largely in their reliability and the ease of use by unexperienced users.

    However, it is often pointed out that the recordings have glitches or missing samples:

    https://forum.pjrc.com/threads/47259-Save-file-to-SD-in-a-different-thread-(or-use-interrupts-for-sampling-)?highlight=audio+recording

    https://forum.pjrc.com/threads/46873...ing-Quad-Audio
    https://forum.pjrc.com/threads/43834...-5-3-6-SDIO-SD
    https://forum.pjrc.com/threads/47075...udio+recording
    https://forum.pjrc.com/threads/46150...udio+recording
    https://forum.pjrc.com/threads/42562...l=1#post160848
    https://forum.pjrc.com/threads/52127...rom-recordings

    Also for me, when I tested several of these sketches, I realized that it is very hard to achieve reliable recordings without glitches and lost samples for several reasons:


    • SD cards sometimes need a considerable amount of time to react to the Teensy write command. This can take up to half a second or even more. This means that the audio library has to buffer all the samples coming into the audio queue and subsequently write them to the SD card while simultaneously buffering all the recent audio samples coming in
    • The audio lib has a restriction of a maximum number of audio blocks it can buffer. This maximum number is often too low to cover the latency of an SD card, which leads to buffer overrun and lost samples


    The consequence is that I looked for a more reliable way and discovered that Walter, WMXZ had already programmed such a sketch (for the Teensy 3.6 only, because a very large RAM is needed for the audio buffer). When I contacted Walter with a further wish list of features, he was so kind to add a lot of other useful features and I carried out a lot of testing on the bench and in the field.

    https://forum.pjrc.com/threads/46136-Yet-another-SimpleAudioLogger


    The sketch can be found here:

    https://github.com/WMXZ-EU/microSoundRecorder

    It has many useful features built-in:


    • Time scheduled recordings
    • Audio-triggered recordings
    • Application to program recording settings without having to reprogram the Teensy
    • Automatic time & date stamps
    • WAV-file header
    • Hibernation function to save power
    • Function to regularly wake up in order to wake up a USB power bank that could be used to power the Teensy


    In several field test sessions we tested the reliability and the usability for an unexperienced user like me. It works very well and has the potential of expansion for different input sources. At the moment it has been tested in the following configurations:


    • Teensy 3.6. & two ICS43434 digital microphones (STEREO)
    • Teensy 3.6. & one ICS43434 digital microphone (MONO)


    Other configurations (untested) include:

    • Built-in ADC MONO
    • Built-in ADC STEREO
    • Audio board I2S Stereo input
    • Audio board I2S Quad input


    See the WIKI on github for further information and documentation.

    https://github.com/WMXZ-EU/microSoundRecorder/wiki

    Thanks a lot to Walter WMXZ for the excellent solution and thanks to Paul for all the work with the Teensy audio library!

    Have fun with the Teensy!

    Frank DD4WH

  2. #2
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,679
    One could try to add a SPI-RAM as buffer for the SD-Card to the audio-shield. It has the same pinout as FLASH, so the existing pads will work.

  3. #3
    Senior Member
    Join Date
    Jul 2014
    Posts
    2,365
    Quote Originally Posted by Frank B View Post
    One could try to add a SPI-RAM as buffer for the SD-Card to the audio-shield. It has the same pinout as FLASH, so the existing pads will work.
    I have thought about it and have done it on another project (using T3.2), but this limits the overall bit rate to half the SPI-RAM clock rate (write to RAM and read from RAM).
    The T3.6 allows already for about 200 kB buffer, so for the 23LC1024 to be useful one needs data rates > 2 MB/s while covering 0.1 s uSD delays. As the 23LC1024 access is limited to 20 MHz, this supports up to 10 MBit/s or 1.25 MB/s data rate (write and read)
    In the absence of quad SPI (SQI) on Teensy, this results to an interesting design. I may think about it, as I have an application where 200 kB buffer is not large enough (high speed multichannel acquisition totalling a datarate of 30 MBit/s), but I still have some 23LC1024 available, so I even may try it.

  4. #4
    Senior Member Blackaddr's Avatar
    Join Date
    Mar 2017
    Location
    Canada
    Posts
    242
    Quote Originally Posted by Frank B View Post
    One could try to add a SPI-RAM as buffer for the SD-Card to the audio-shield. It has the same pinout as FLASH, so the existing pads will work.
    This is the approach I had been planning for an upcoming project on my TGA Pro board. I've already modified crteensy's DmaSpi library to support DMA transfers to/from the SPI RAM. As you guys already suggested, use the SPI RAM as a big FIFO buffer for writing to the SD card.

    As a very rough calculation, Each channel of audio is 44100 * 16 bits = 705.6 KHz. I figured the 20 MHz SPI rate should provide enough total throughput for several channels of read and write.

    Of course I haven't tried any of this yet!

  5. #5
    HI all - great information, thank you. This is exactly what I need to do too. Would it be possible to port this to run on the Tympan board on a Teensy3.6? https://tympan.org

  6. #6
    Senior Member
    Join Date
    Jul 2014
    Posts
    2,365
    Quote Originally Posted by garthpaine View Post
    HI all - great information, thank you. This is exactly what I need to do too. Would it be possible to port this to run on the Tympan board on a Teensy3.6? https://tympan.org
    It should be possible.
    It requires only to consider the Codec Chip is using.

  7. #7

    AudioControlTLV320AIC3206

    Thanks for the response - I thought I posted this the other day, but can not see it now. The codes says
    #include <Tympan_Library.h> //AudioControlTLV320AIC3206 lives here
    I have tested this code and it seems to sometimes work and sometimes just produce silent files so I assume it works with this audio chip but that the pins may not be correct for audio I/O

    Thanks, Garth

  8. #8
    hi @WMXZ - I just wanted to follow up and see if you might be able to assist me with this translation of your wonderful code to the Tympan? I think it would be a great addition but realize that it is beyond my skills as your code is complex to my eyes. Cheers, Garth

  9. #9
    Senior Member
    Join Date
    Jul 2014
    Posts
    2,365
    Quote Originally Posted by garthpaine View Post
    hi @WMXZ - I just wanted to follow up and see if you might be able to assist me with this translation of your wonderful code to the Tympan? I think it would be a great addition but realize that it is beyond my skills as your code is complex to my eyes. Cheers, Garth
    OK, I will look into it.
    However, I'm at the moment in the field with little time in the upcoming 5 to 6 weeks.

  10. #10
    Senior Member
    Join Date
    Jul 2014
    Posts
    2,365
    Quote Originally Posted by garthpaine View Post
    hi @WMXZ - I just wanted to follow up and see if you might be able to assist me with this translation of your wonderful code to the Tympan? I think it would be a great addition but realize that it is beyond my skills as your code is complex to my eyes. Cheers, Garth
    Checking Tympan's SW on github, I found a uSD logger. So, question is why do you want to port the SW, this thread is about, to Tympan? What is the application that Chip's software does not handle. Chip uses also an earlier version of Bill Greimans uSD library. I also ask as the TLB320AIC3206 has a lot of features a simple I2S Mic does not provide.

  11. #11
    HI @WMXZ - I find the quality of the sound recorded through the Tympan board to be of superior quality which is of interest to me. Also the logger code they (unless I missed something) have allows you to start recording turning the potentiometer on the board, but does not allow timed on/off, timestamped events and does not record in .wav (uses RAW) or allow long file names - meaning the files can not be time/date/location stamped. In addition there is no init file to allow machine/file naming and time/date setup etc to be done without compiling for each deployed machine. All of these features and more are implemented within your code - hence my interest - cheers, Garth

  12. #12
    Senior Member
    Join Date
    Jul 2014
    Posts
    2,365
    Quote Originally Posted by garthpaine View Post
    HI @WMXZ - I find the quality of the sound recorded through the Tympan board to be of superior quality which is of interest to me. Also the logger code they (unless I missed something) have allows you to start recording turning the potentiometer on the board, but does not allow timed on/off, timestamped events and does not record in .wav (uses RAW) or allow long file names - meaning the files can not be time/date/location stamped. In addition there is no init file to allow machine/file naming and time/date setup etc to be done without compiling for each deployed machine. All of these features and more are implemented within your code - hence my interest - cheers, Garth
    fair enough.
    Caveat, I have no Tympan at hand and even if I order one I will not be able to test before end of July.

  13. #13
    Senior Member
    Join Date
    Jul 2014
    Posts
    2,365
    Quote Originally Posted by WMXZ View Post
    fair enough.
    Caveat, I have no Tympan at hand and even if I order one I will not be able to test before end of July.
    OK, I pushed a version that compiles also for Tympan.
    I removed all user changeable definitions from myApp.cpp to config.h

    To configure the SW fir Tympan edit config.h and define ACQ to be _I2S_TYMPAN
    (should be easy)

    I put the input gain to 10.5, you can change that too.

    The code assumes that the codec is configured for 16 bit (96 dB)

    As said, I cannot test it, so if you have a Tympan Version C you can try it

  14. #14
    Senior Member DD4WH's Avatar
    Join Date
    Oct 2015
    Location
    Central Europe
    Posts
    488
    Hi!

    use it this way (comment out!), if you do not use environmental sensors:

    //#define USE_ENVIRONMENTAL_SENSORS

    How is your ACQ defined?

  15. #15
    Senior Member
    Join Date
    Jul 2014
    Posts
    2,365
    Quote Originally Posted by DD4WH View Post
    Hi!

    use it this way (comment out!), if you do not use environmental sensors:

    //#define USE_ENVIRONMENTAL_SENSORS

    How is your ACQ defined?
    Frank, I changed the definition of USE_ENVIRONMENT_SENSORS to carry a value
    I will look into these errors.

  16. #16
    Senior Member
    Join Date
    Jul 2014
    Posts
    2,365
    Make sure you really set
    Code:
    #define ACQ     _I2S_TYMPAN

  17. #17
    HI WMXZ - yes I must admit I am a bit confused as to why this is not compiling for me - it clearly does for you :-)
    I have made triple sure that _I2S_TYMPAN is defined as interface 7 in the config and that it is set as the as per #define ACQ _I2S_TYMPAN
    then I have made sure in myApp that we have an if statement #if(ACQ == _I2S_TYMPAN)

    They all look the same - in fact I copied and pasted them. I did wonder if the delay needs to be defined in the #if statement and tried

    #include "m_delay.h";
    mDelay<1,(MDEL+2)> delay1(0); // have ten buffers more in queue only to be safe

    but this then causes other issues....

    I have Arduino environment setup for

    Teensy 3.6, Audio, 180MHz, Faster, /dev/cu.SOC

    this compiles other Tympan code ok

  18. #18
    Senior Member
    Join Date
    Jul 2014
    Posts
    2,365
    Quote Originally Posted by garthpaine View Post
    HI WMXZ - yes I must admit I am a bit confused as to why this is not compiling for me - it clearly does for you :-)
    I have made triple sure that _I2S_TYMPAN is defined as interface 7 in the config and that it is set as the as per #define ACQ _I2S_TYMPAN
    then I have made sure in myApp that we have an if statement #if(ACQ == _I2S_TYMPAN)

    They all look the same - in fact I copied and pasted them. I did wonder if the delay needs to be defined in the #if statement and tried

    #include "m_delay.h";
    mDelay<1,(MDEL+2)> delay1(0); // have ten buffers more in queue only to be safe

    but this then causes other issues....

    I have Arduino environment setup for

    Teensy 3.6, Audio, 180MHz, Faster, /dev/cu.SOC

    this compiles other Tympan code ok
    Please note that there are other changes in the code, best is to re-download the whole code from GitHub.
    Try to compile it as is
    then compile with ACQ set to _I2S_TYMPAN in config.h (Line 45)
    Also compile with Serial, there is no USB_Audio (as with TYMPAN)

    My configuration on A1.8.5, TD1.42b3 Win10 is Teensy 3.6, Serial, 180 MHz, Faster

    If you wanted to know what I have changed, go to GitHub, open the file, click on History (open right over the code), then you click on text to the left and you see all changes I did during this particular commit

  19. #19
    Ok cool thanks so much - I am in an airport without the Tympan, but did compile it fine with the ACQ set to _I2S_TYMPAN in config.h
    I will be back with a Tympan in a week or so and will try compiling it to the board - thats an exciting prospect - I greatly appreciate your assistance - thank you
    Cheers, Garth

  20. #20
    Member
    Join Date
    Mar 2017
    Location
    Utah
    Posts
    55
    Is there any chance of adding the TDM protocol for using the ICS-52000 mics from invensense? What would the limit be for the amount of data that can be recorded? If I have 5 mics sampling at 48000Hz would the memory run out? I want to try microphone beamforming.

  21. #21
    Senior Member
    Join Date
    Jul 2014
    Posts
    2,365
    Quote Originally Posted by dreggory View Post
    Is there any chance of adding the TDM protocol for using the ICS-52000 mics from invensense? What would the limit be for the amount of data that can be recorded? If I have 5 mics sampling at 48000Hz would the memory run out? I want to try microphone beamforming.
    I can add TDM, no problem.

  22. #22
    Junior Member
    Join Date
    Sep 2018
    Posts
    2
    Hi all,

    I'm currently working on a project (with @garthpaine) using Teensy 3.6 to build a gunshot detection & location system for an anti-poaching initiative in Costa Rica. I have seen a few other threads regarding systems with similar goals, however because this is in the beginning stage I am using the singular MEMS mic setup for initial "shot detection only" tests. Along with this I am also using the microSoundRecorder code as a starting point, so I felt it more fitting to post here. (Thanks so much @WMXZ for sharing this code as it has helped me learn backwards in regards to what code is causing what outcomes)

    My goals for testing are as follows...

    1. Monitor amplitude peak vector, subtracting mean background amplitude from a reference frame captured say every 10 minutes (we will do this as it is rainforest and the ambient amplitude will vary greatly during 24 hrs).

    2. Upon threshold of ambient amplitude being passed, run 1024 FFT.

    3. Use FFT to calculate spectral centroid vector over a period of a ~10 frame buffer (sample rate dependent, hoping 96k will be a possibility.) we are looking for the amplitude and spectral centroid vectors to have rapid change in opposite directions

    4. Calculate the angle or length of the amplitude or loudness vector and the spectral centroid vector

    5. If the amplitude vector is sufficiently steep (long) and the spectral centroid vector is also very steep in the opposite direction
    ie. If they are greater than a set threshold (ie. Acceleration)

    6. Write a text file to the SD card containing an array of the amplitude & SC values in the buffer.

    7. Write that buffered bit of audio on the SD card as well so verification of the shot can be made through playback after. This will allow me to take a single system in the field and feed it some test shots from varying distances and locations.

    8. Send message to central server using IoT low powered radio indicating listening device number and shot detected triangulation will be done on a PC which will then send an SMS to security staff


    - My question is: Given the audio stream is present can you suggest how I can insert the amplitude change function, FFT function and associated vector functions in this code?
    - I am also very open to any input on how you think the workflow could be improved?

    I think the microSoundRecorder is a good base as it already does all the MEM handling and SD file writing, and can be scheduled. I see there is also a thresholding function which could be called perhaps when the vectors are above threshold of rate of change.

    Being fairly new to C I am struggling with where exactly to begin this process in the code itself, and any/all input would be very much appreciated. Thank you all so much!

    Kyle

  23. #23
    Senior Member
    Join Date
    Jul 2014
    Posts
    2,365
    Quote Originally Posted by kylehoefer View Post

    I'm currently working on a project (with @garthpaine) using Teensy 3.6 to build a gunshot detection & location system for an anti-poaching initiative in Costa Rica.
    Kyle,
    I really like your application.

    I should be possible to extend the existing recorder SW to do the processing you wanted to do, or even more.

    The items under 2 - 4, while I think I understand what you are meaning, needs more reading from my side. Do have some papers in mind that describe the processing?

    Concerning programming (or understanding the code), you always can contact me at walter (at) wmxz.eu. I would be delighted to help your project.

  24. #24
    Junior Member
    Join Date
    Sep 2018
    Posts
    2
    Quote Originally Posted by WMXZ View Post
    Kyle,

    The items under 2 - 4, while I think I understand what you are meaning, needs more reading from my side. Do have some papers in mind that describe the processing?
    Walter,
    Thanks so much for your response and being so generous!

    In regards to items 2 - 4 on that list, it is sort of what Garth and I discussed as the "new" detection methods we have not seen used extensively in other gun detection projects.

    With that being said there weren't too many papers I found relating specifically to that technique, however a few I think were the most useful are...

    "Evaluation of Gunshot Detection Algorithms" Alfonso Chacón-Rodríguez

    "IMPROVING EFFICIENCY AND RELIABILITY OF GUNSHOT DETECTION SYSTEMS" Talal Ahmed

    This is a project I found calculating time-of-arrival differences using Teensy, although it doesn't go too much in depth with the spectral detection processing itself
    MicLoc - Rural Hacker

    Lastly and the most important, a very similar system. Section 2.4 of this article goes in to great detail, I'm just reading it now myself!
    AudioMoth: Evaluation of a smart open acoustic device for monitoring biodiversity and the environment

    __________________________________________________ ___

    We have run a few tests in Sonic Visualizer using gunshot recordings I have collected in the field, (unfortunately just here in the desert, not rainforest yet), and I can show you these to help describe exactly what is happening as well. Let me know if this is helpful at all

    Below is a graph containing the audio of a very distant, hardly audible gunshot recorded at 96k.

    We have two sets of processing defined here, the first is the orange line representing "Loudness." This is extracting the loudness of the signal from its spectrum at a window size of 1024, a window increment of 1024, and using a Hann window shape. We can see a jump in loudness from 0.0 - 0.1 sec, as this is where the shot is.

    The second is the purple line, representing the Spectral Centroid of the signal. The parameters are the same - 1024 window size and window increment, and Hann window shape. We see a jump in the opposite direction here as the center of mass of the spectrum drops due to the subsonic gunshot. The drop from Bin 1 to Bin 2 in this graph is about a 1300Hz difference, dropping from ~3000Hz to ~1700Hz once the shot reaches the mic.


    Click image for larger version. 

Name:	SoftestShotAnalysis.jpg 
Views:	35 
Size:	72.9 KB 
ID:	14814

    Although the graph shows after the gunshot that these values can be a little unpredictable, it was evident through our tests that (3) it is the correlation between the rapid amplitude rise and spectral centroid drop at the same time from which we can determine what is a shot vs any another loud sound. The point made in (4, 5) is to calculate the angle of those values from bin to bin in the graph to distinguish an acceleration in both parameters.

    I'll leave it at that for now, but I just wanted to explain what we have this far!

    Once again thanks for your time,
    Kyle
    Last edited by kylehoefer; 09-25-2018 at 07:11 AM. Reason: Added Source

  25. #25
    Member
    Join Date
    Mar 2017
    Location
    Utah
    Posts
    55
    WMXZ, you are a gentleman and a scholar.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •