Demodulate pre-recorded samples or share AVAudioRecorder instances about quietmodemkit HOT 5 OPEN

As I look at this again, I think you really just want a QuietReceiver. You're right that these things are private so you'll need to fork slightly, but it looks like the changes should be minimal. I'm not sure what you mean specifically by recompiling from source but you would need to run a slightly different version of the library.

I think the process is

• Expose QuietReceiver and whatever else until compiler stops complaining.
• Instantiate a QuietReceiver using the same config as the QMFrameReceiver and whatever sample rate you're capturing at (44100, 48000, etc). This number has to be the sample rate that your capturer runs at.
• Feed your instance samples using consumeAudioFromSamples. It just wants an array of floats and the length of the array.
• Call receive on the instance. This is nonblocking - if there's no decoded frame then you just get a nil back. You can feed a block of samples, then just keep receiving until nothing else comes out.

Feeding the decoder requires a bit of care. It wants floating-point, mono PCM. It has to match this exactly to work.

It looks like the tap block gives you something that will just spit out floating point samples (floatChannelData) so you should be set there. The length parameter you give to QuietReceiver should be the number of samples, not the length in bytes of the buffer e.g. it should be length of buffer/4. I think this is the same value as frameLength.

The one thing you have to be careful of is that if you're capturing in stereo, then the buffer you give to quiet needs to be mono (you'll probably have to copy to a new buffer to make this work). Just throw away one of the channels, don't mix/add them together since that will cause destructive interference.

Let me know if you have more questions, but I think that's the high level idea.

from quietmodemkit.

Hi @theronic

I'm actually reworking this library now to make it cleaner for Swift. I'm planning on making it a "1.0" release. I'll add it to my list to add this functionality.

For now, if you want to fork it for your own purposes, you basically want to expose the call to quiet_decoder_consume somehow. The loopback audio system is a test setup that mimics the real sound system, but it might be a good place to use for inspiration. I think it operates on QuietAudioConsumer protocol objects, which might be useful for what you want (this just wraps the call to quiet_decoder_consume).

You can feed this consume function blocks of whatever size is convenient for you. Just make sure that the samples are in floating point PCM format. The size parameter is the number of samples, not the size of the buffer e.g. num_samples, not num_samples * 4. You will also need to tweak the quiet_decoder_create constructor if your recording isn't in 44100 Hz sample rate.

Let me know if you have more questions. I will probably push out the new version in a few weeks, possibly about a month.

Cheers

from quietmodemkit.

I see that quiet_decoder_consume is called from consumeAudioFromSamples, which in turn is called from

Could you show an example of how I would manually pass in the samples from my installTap call so that I don't have two processes consuming audio resources?

These implementations seem to be private. Will I need to recompile from source?

from quietmodemkit.

On second reading, it looks like floatChannelData only returns non-nil if you're capturing in float. If you're capturing in something else, you'll need to convert to float, but it's pretty easy. For 16-bit fixed just divide all the samples by SHRT_MAX. For 32-bit fixed, divide by INT_MAX.

from quietmodemkit.

Hi @brian-armstrong !
Is there any news on your new Swift-friendly library?
Thanks a lot.

from quietmodemkit.