The arduino code of the Audio Codec Shield uses a timer to generate an interruption every time a sample is needed. I tried to use TimerOne.h but it does not seem to work with periods smaller than 1000 micro seconds. I tried to attach an interruption with the function:

Timer1.attachInterrupt( timerIsr, 1000);

The other problem is that even if the timer with 1 microsecond resolution works, I need a period closer to the 1/samplingRate.

The timer period that I need is 1/44100 that is ~22.675 us. In the original arduino sketch (find attached a simplified version) is done by setting the timer to produce an interrupt with a rate very close to that number (22.675 us). At every interrupt the arduino transfer the audio data to the codec via SPI. One of the problems of not sending the data on time to the codec is that the sound can have 'clicks'.

The attached file contains the main program and part of the AudioCodec.h file (that is #included by the main file).

Looks like there are only constants and subroutines that don't directly call Timer1 methods in the sketch you've attached, so I can't advise specifically :-) but I can describe you the general system, which hopefully will help you to achieve what you're looking for.

Out of the code in arduino-1.5.3\hardware\arduino\x86\cores\arduino\interrupt.c and arduino-1.5.3\hardware\arduino\x86\libraries\TimerOne\TimerOne.cpp the smallest value you can pass to timer initialize() method is 1000 useconds. The value you subsequently pass to attachInterrupt() must be the same or an even multiple of that - meaning that your subroutine will be called every 1000 useconds (if you specify 1000) or less frequently (if you specify any bigger multiple of that).

So that means the highest call frequency you can get using timer is 1/1000 usec = 1KHz and you need about 44KHz to get to your desired sampling rate.

To me personally it sounds a little strange, because that's sort of limited, I just didn't expect that. I haven't tested the above hands-on, that's my conclusion based on the code inspection. I don't have my board right now at hand to try it out, but I'll try to test it over the weekend.

You can try it too. The Galileo libraries have certain tracing built-in and after sketch is compiled and is running, it writes some useful information to two files on the board: /tmp/log.txt (general information, stdout is redirected there) and /tmp/log_er.txt (errors, stderr is redirected there). The default trace level is verbose enough to see timer initialization errors and information about values used if the initialization ran successfully. So you could use those in your debugging process too.

I have checked the code you pointed out and 1ms is completely useless for this application. I guess that the only alternative to use audio is by writing an ALSA driver for linux. That will require more work than what I'm willing to spend on this project, so I'll have to skip using the Galileo board until there's an easier way of doing this.

Another approach you could use to achieve a smaller processing timestep is to do a loop+use micros() function to determine when to send the data. That is of course uglier than timer-based approach, but may still produce the effect you want, try it out :-)

There's no mraa call for that as it would really be surplus there - when you're using mraa, you are working on the OS level, so you can use all the OS facilities for timekeeping (depending on the language you use). That's what basically the Arduino layer does on Edison and Galileo - just reaches out to OS.

AlexT - thanks for the reply. I will be testing an OS call this week to see if it is fast enough. I opened a new discussion at micros() call with MRAA, and will focus on that discussion to keep from doubling up responses in this one (Charlie posted a response on that thread). -TJS