questions about mobilesynth
Jan Tuitman
I'm planning to write an sequencer plus instrument for the iphone, and
i came across mobilesynth, which looks great! I have some questions
about its workings, as I am not very proficient with C and apple
frameworks.
Question 1 - global workings?
I believe the AudioOutput class sets up an audio unit and then is
called by the operating system to provide music data . The AudioOutput
class forwards this call to its delegate, which is the view
controller. this calls the synth controller class, and fills a float
array that way. The float array is then converted to a SInt32 array
and returned to the OS.
* I did not find any coding for stopping the play, so am I correct
assuming that this runs continuously, and if the sound is finished the
synth just returns zeroes all the time?
* If i would be need a different instrument I could just create a
class that has a getFloatSamples method and call it in the delegate?
Question 2 - performance?
I wondered how many calculations can you do in an instrument, because
the data is buffered and played in real time. Have you had any
experiences what happens if the instrument is too slow (does the OS
then 'skip frames'... or... ?) and can you say something about the
amount of calculations that are possible before this happens?
regards,
Jan Tuitman.
Allen Porter
On Wed, Mar 10, 2010 at 1:43 AM, Jan Tuitman <jan.t...@gmail.com> wrote:
> Hello,
>
> I'm planning to write an sequencer plus instrument for the iphone, and
> i came across mobilesynth, which looks great! I have some questions
> about its workings, as I am not very proficient with C and apple
> frameworks.
>
> Question 1 - global workings?
>
> I believe the AudioOutput class sets up an audio unit and then is
> called by the operating system to provide music data . The AudioOutput
> class forwards this call to its delegate, which is the view
> controller. this calls the synth controller class, and fills a float
> array that way. The float array is then converted to a SInt32 array
> and returned to the OS.
> * I did not find any coding for stopping the play, so am I correct
> assuming that this runs continuously, and if the sound is finished the
> synth just returns zeroes all the time?
Yes, you are correct. The interesting bit is in generateSamples in
mobilesynthViewController. This check performs a short circuit if
nothing is being played and just fills the buffer with silence so that
it doesn't have to waste time multiplying a bunch of zeros together
inside of the synth library:
if (controller_->released()) {
// Silence
memset(data, 0, outputBuffer->mDataByteSize);
return noErr;
}
> * If i would be need a different instrument I could just create a
> class that has a getFloatSamples method and call it in the delegate?
I am not entire sure what you are asking, but I imagine that you'd
want to only ever have one place that fills a buffer -- and you'd
combine all instruments floating point values before filling it.
Scott seems to have a pretty good approach for doing this, as
discussed in another recent thread.
> Question 2 - performance?
> I wondered how many calculations can you do in an instrument, because
> the data is buffered and played in real time. Have you had any
> experiences what happens if the instrument is too slow (does the OS
> then 'skip frames'... or... ?) and can you say something about the
> amount of calculations that are possible before this happens?
I have run into problems trying to do too many calculations where the
processor can't fill the buffer fast enough. With the current code,
what happens is that there will be a short skip, and the audio lags
behind. It waits for the callback from the hardware layer asking for
more frames, but keeps its own sample counter instead of relying on
the hardwares clock (which would probably be a better strategy, if it
were desirable to fail more gracefully).
It seems to keep up with the 44k sample rate, but its a little close
to the edge of not being able to. The most expensive part is
currently the low pass filter (especially when combined with
modulation of the cutoff frequency), which went through a couple of
implementations until performance was OK. Its also doesn't help that
mobilesynth uses floating point math. It could get a lot better
performance if it used fixed point, but writing that in code seemed a
lot less intuitive to me and I had a seep enough of a learning curve
to worry about that.
> regards,
> Jan Tuitman.
>
> --
> You received this message because you are subscribed to the Google Groups "mobilesynth" group.
> To post to this group, send email to mobil...@googlegroups.com.
> To unsubscribe from this group, send email to mobilesynth...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/mobilesynth?hl=en.
>
>
--
-allen