Pedro,
Even if you get your code working to select 8192 sample buffers, there is no guarantee that all audio hardware is capable of supporting that size. Your application would only work with limited hardware.
Nuno is correct. You need an additional buffer internal to your code. This is actually quite common, especially for audio code which uses frequency domain processing such as the FFT.
If you are developing an AudioUnit, this internal buffering will result in latency which should be reflected in the latency parameter. In hosts like Logic, the internal buffering latency will be compensated by adjusting the timing of tracks containing such additional buffering.
If you are developing an audio host, any latency compensation is up to you.
Brian Willoughby Sound Consulting
On Sep 4, 2012, at 07:01, Nuno Fonseca wrote: Probably this is not the answer that you are looking, but… can't you use a 1024 sample buffer callback, store them on a 8192 temp buffer, and process the full 8192 samples on every 8th callback? And if you are also outputting things, you simply do the opposite: store the values on a temp 8192 temp buffer, and get 1024 samples in each callback.
On Sep 4, 2012, at 1:36 PM, Pedro Torres Assunção wrote: I am struggling with a small part of my application. I need to get at least 8192 audio samples.
I came across several code samples and the one that we got better results is present on these .h ( http://bit.ly/OUfDVf ) and .m ( http://bit.ly/Q2qlqJ) files, links at the end. In the .m file there are 4 comments indicated with PTA an those are the only comments made by me. If we set our function to work with only 1024 samples it works which proves that we are correctly getting the 1024 samples but that is just too short for our needs.
Our currently test requires at least 8192 samples but we just can't figure out how.
Is there any one who can help us?
|