0

I'm developing a means of bringing several sensor signals, modulated together into one signal, into the iPhone through the audio input. I need to do several things:

  1. Demodulate these signals from the input signal through a trivial filter chain, and then output each down its own signal path for further processing--must be realtime.
  2. Playback a sonified version of each signal--preferably realtime.
  3. Stream each signal out over a network connection--preferably realtime.
  4. Store each signal in a PCM file--need not be realtime.

I need help conceptualising the signal chain in this process. I've begun to sketch the design using Audio Units. First of all, have I gone too low-level by choosing Audio Units? Would this be implementable with Audio Queue Services? Nevertheless, I've got to the point where I've the modulated signal coming in (have not demodulated it yet), am sonifying it in real time, and am passing the sonified signal back out the output. Now, in order to split this signal into two separate sections of the signal chain, I would imagine doing something like routing the output of my Remote I/O unit into two separate input buses on a Multichannel Mixer Unit, and sonifying/writing-to-disk/writing-to-network in the Multichannel Mixer Unit's callbacks.

However, is this too much processing for a realtime thread? Am I really going to be able to accomplish this, or will I need to pull some of the functionality offline? Second, is it possible to route the I/O Unit's input element's output to separate input elements of a Multichannel Mixer Unit? If not, would I be able to specify a multichannel stream description, and split the origin

GarlicFries
  • 8,095
  • 5
  • 36
  • 53

1 Answers1

0

Multi-channel audio demodulation is certainly possible on an iOS device. It's been done using DSP IIR filter banks, FFT filtering, and etc. The ARM NEON vector unit has more DSP crunching power than many specialized DSP chips of just a few years back.

I suggest using the Audio Unit or Audio Queue services just for data acquisition. Then just queue up the PCM samples and feed them to your DSP processing blocks.

Whether you can stream the data over a network depends on the number of channels, data rate per channel, data compression ratios, variance in network bandwidth, and etc.

hotpaw2
  • 70,107
  • 14
  • 90
  • 153
  • Am I hearing that I don't need to step down to Audio Units at all? Well hey, at least I enjoyed learning it! Seriously though, if I'm just using one of those tools for acquisition, should I process offline as quickly as possible and then push to speakers/file/network when I'm ready, or am I misunderstanding your suggestion? – GarlicFries Jan 24 '11 at 20:18
  • Or, if I can do all of this realtime, is my idea of specifying a five or six channel stream and splitting the original mono signal out into those streams a possibility? – GarlicFries Jan 24 '11 at 20:20
  • You only need Audio Units for the lowest latency. Otherwise, just queue enough data up and process it in a background thread. – hotpaw2 Jan 24 '11 at 20:23
  • 6 channels is a piece of cake. I have iPhone guitar tuners that process as many or more channels and visualize them all in (near) real time. – hotpaw2 Jan 24 '11 at 20:25
  • So, when you said to "queue up the PCM samples and feed them to your DSP processing blocks"/"...in a background thread", do you mean to leave Core Audio behind for that work, and then reintroduce the processed data into the Audio Unit chain (or other framework) on the main thread for sonification? – GarlicFries Jan 25 '11 at 10:48
  • I'd like to accept this answer, but my questions haven't really been completely addressed yet... – GarlicFries Feb 19 '11 at 19:05
  • What you've suggested works, but only allows genuinely real-time processing. Shame only one of my bullet points was (sort of) addressed, and then the thread just sort fell off a cliff... Thanks for the beginnings of a solution though--pointed me in the right direction. – GarlicFries Apr 22 '11 at 10:17
  • You might want to split up your other points in completely separate and better defined questions. – hotpaw2 Apr 22 '11 at 17:31