Re: ExtAudioFileWriteAsync problem
Re: ExtAudioFileWriteAsync problem
- Subject: Re: ExtAudioFileWriteAsync problem
- From: "tahome izwah" <email@hidden>
- Date: Tue, 1 Aug 2006 08:45:27 +0200
Please s.b.
2006/7/31, Doug Wyatt <email@hidden>:
On Jul 25, 2006, at 03:06 , tahome izwah wrote:
> Hi all,
>
> I am currently debugging an application of mine based on the latest
> RecordAudioToFile code example. Instead of reading from the default
> Audio Unit to record from the audio-in I am creating the data myself
> in a short loop like this:
>
> long x = 0.;
> for (long i = 0; i < 25; i++)
> {
> for (long c = 0; c < framesPerWrite; c++)
> data[0][c]=data[1][c]=sin(1000.*2.*M_PI*x++/44100.);
>
> err = audioFileWriter->Write(data, framesPerWrite);
> if(err != noErr) break;
>
> printf("writing %d\n", i);
> }
>
> The two-dimensional data[][] array gets converted to an
> AudioBufferList in my call to Write() and then ExtAudioFileWriteAsync
> is called to do the actual write to disk, but strange things are
> happening. Sometimes the resulting file is 1.2 MB in size (which is
> the size it should be), sometimes it's only 180k and sometimes it is
> an empty file of 4k. Note that this is the size after
> ExtAudioFileDispose so I do not believe it to be a cache problem.
>
> I was able to verify that the problem does not occur when I perform
> synchronous writes through ExtAudioFileWrite so I guess it might be a
> timing thing... is it possible that successive calls to
> ExtAudioFileWriteAsync can cause it to miss data?
You *will* fill the ring buffer if you call it more quickly than data
can be written to disk, which is almost certainly happening if
25*framesPerWrite (in your example) is larger than the ring buffer
(default size is 64K bytes).
Yes, framesPerWrite is 8192.
ExtAudioFileWriteAsync should always return an error if the ring
buffer fills or if another error happened on the worker thread since
the last call the ExtAudioFileWriteAsync.
No it does not, which is why I was uncertain about what was causing me
the headache.
To isolate whether this is a timing or other issue, I would suggest
inserting a call to sleep(1) between each iteration through your
loop. That should be far more time than is necessary to keeep the
ring buffer from overflowing (assuming framesToWrite doesn't
correspond to more bytes than can fit in the ring buffer).
Like I said, in the RecordAudioToFile example it works fine, so I
guess this must indeed be the problem. I was primarily wondering why
there is no error returned when the queue is full and whether or not
the queue was fixed in size. I still don't see an error here but at
least I know that the problem isn't on my side.
Thanks again,
--th
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden