Re: Playing "silence" to an AudioQueue (with VBR format)
Re: Playing "silence" to an AudioQueue (with VBR format)
- Subject: Re: Playing "silence" to an AudioQueue (with VBR format)
- From: William Stewart <email@hidden>
- Date: Wed, 23 Jan 2008 19:00:08 -0800
But there's no requirement that you enqueue more data from a callback
- all that the cb is telling you is that the buffer it is supplying
has been consumed by the queue.
kAudioQueueErr_BufferEmpty is the error you are getting - you are
trying to enqueue a buffer that has nothing in it.
Bill
On Jan 22, 2008, at 8:15 PM, Neil Clayton wrote:
Thanks for the quick reply.
I have had an extensive play with the core audio based playthru. I
did this more or less as an experiment to see if it's suitable.
It'd be nice if it'd work; since I can access everything I need
(volume levels) for my application. I don't actually need to plug
various AU's together; so while the existing play thru examples are
useful, an easier to use (read: less maintenance down the road) API
is appealing.
I'm not quite sure I understand your statement. Given that I have
to start the queue at some point, and that I'm playing data from a
device to another device - I would have thought that some kind of
data would always be available.
The way the system works at the moment is *very* similar to
aqplay.cpp. The recording buffer is initialized, and started. As
it receives frames/data, it records these. If the playthru buffer
exists (when I say "buffer" here I really mean my objective-c
wrapper classes), it then "primes" it by sending it one
AudioBufferRef of data. Just as in aqplay.cpp, the playthru
buffer then allocates the necessary memory and enqueues the data.
In summary: My playback mechanism is lazy - buffers being allocated
and enqueued only when there is data available.
This is why I hear the first second or so.
But in between the startup as described above and the next input
buffer becoming available, the output proc of the playback queue is
called. If I have no data to give it - what do I do? If I don't
enqueue the buffer; then the queue can't get hold of it to re-
request data to be played, and thus eventually there are no buffers
available and the output audio queue simply stops because it never
requests any further data.
Here's an example:
2008-01-23 16:53:36.106 CoreAudioRecorder[33327:11a03] [Thread 1]
[RecordingQueue] - Buffer: (0x1644e000), wrote 147 bytes, 21 packets
2008-01-23 16:53:36.107 CoreAudioRecorder[33327:11a03] [Thread 1]
[AQOutputBuffer] - Allocated buffer 1
2008-01-23 16:53:36.109 CoreAudioRecorder[33327:11a03] [Thread 1]
[AQOutputBuffer] - Primed buffer 1
2008-01-23 16:53:36.666 CoreAudioRecorder[33327:11a03] [Thread 1]
[RecordingQueue] - Buffer: (0x16456000), wrote 105 bytes, 15 packets
2008-01-23 16:53:36.666 CoreAudioRecorder[33327:11a03] [Thread 1]
[AQOutputBuffer] - Allocated buffer 2
2008-01-23 16:53:36.667 CoreAudioRecorder[33327:11a03] [Thread 1]
[AQOutputBuffer] - Primed buffer 2
2008-01-23 16:53:37.778 CoreAudioRecorder[33327:11a03] [Thread 1]
[RecordingQueue] - Buffer: (0x1645e000), wrote 147 bytes, 21 packets
2008-01-23 16:53:37.778 CoreAudioRecorder[33327:11a03] [Thread 1]
[AQOutputBuffer] - Allocated buffer 3
2008-01-23 16:53:37.778 CoreAudioRecorder[33327:11a03] [Thread 1]
[AQOutputBuffer] - Primed buffer 3
2008-01-23 16:53:37.779 CoreAudioRecorder[33327:11a03] [Thread 1]
[AQOutputBuffer] - Priming completed - queue started
2008-01-23 16:53:37.808 CoreAudioRecorder[33327:11a03] [Thread 1]
[RecordingQueue] - Error while enqueing packet, -66686
2008-01-23 16:53:38.338 CoreAudioRecorder[33327:11a03] [Thread 1]
[RecordingQueue] - Buffer: (0x1644e000), wrote 105 bytes, 15 packets
2008-01-23 16:53:39.450 CoreAudioRecorder[33327:11a03] [Thread 1]
[RecordingQueue] - Buffer: (0x16456000), wrote 147 bytes, 21 packets
2008-01-23 16:53:40.010 CoreAudioRecorder[33327:11a03] [Thread 1]
[RecordingQueue] - Buffer: (0x1645e000), wrote 105 bytes, 15 packets
2008-01-23 16:53:41.121 CoreAudioRecorder[33327:11a03] [Thread 1]
[RecordingQueue] - Buffer: (0x1644e000), wrote 147 bytes, 21 packets
2008-01-23 16:53:41.682 CoreAudioRecorder[33327:11a03] [Thread 1]
[RecordingQueue] - Buffer: (0x16456000), wrote 105 bytes, 15 packets
You can see three buffers allocated and primed with audio content.
This is happening as a result of the input callback being given some
data. The result is audible (after a second or so). You can also
see the "Error while enqueing packet, -66686" - which is happening
because the output proc is being called; but no more input data has
yet been queued.
The process then continues. In the case shown above only one of
the three buffers experiences the -66686 issue. Thus two remain
usable and playthru works. Depending on the timing and number of
buffers you can have all three buffers experience this condition and
the system is dead.
If there were a way within a callback to say "I have no data for
you, please have the buffer back and call me back later" - the
problem would be solved.
--
Regards,
Neil Clayton, http://shinywhitebox.com
On 23/01/2008, at 4:12 PM, William Stewart wrote:
On Jan 22, 2008, at 6:51 PM, Neil Clayton wrote:
I've successfully got a playthru working between two AudioQueues,
in PCM.
I've two callbacks. One for an input queue and the other for an
output queue. The input callback receives data and copies it to
an internal array, which the output callback can then use to feed
the output queue.
For VBR - I've got it "kind of working" - I hear a little audio
(perhaps 1-2 seconds), before it stops.
It appears to be because the output callback (to the speakers) is
called more often than the input callback, and sometimes no data
is available because the input callback is called perhaps only
twice a second.
You should have a look through the CAPlayThrough example - it shows
you how to varispeed so you can do playthrough between different
devices (including different sample rates) - using queues the way
you are is not going to work without adjusting for the drift
between the two devices
(But as a matter of form - if you have nothing to play with a
queue, just don't scheduled anything. If the AQ Object gets to a
place where it has not data to play, it just plays silence. So,
even with PCM you don't have to enqueue silent buffers just to play
silence).
Bill
In this case (no data to present to the output queue), I attempt
to queue an empty AudioQueueBuffer, but receive
kAudioQueueErr_BufferEmpty as a result.
- (void) handleOutputBuffer:(AudioQueueRef)inAQ bufferRef:
(AudioQueueBufferRef)inBuffer {
// Suck off the next element of our queue
OSStatus err = noErr;
if([packetBuffer count] > 0) {
Intermediate *packet = nil;
@synchronized(packetBuffer) {
packet = [packetBuffer objectAtIndex:0];
[packetBuffer removeObject:packet];
}
@try {
[packet copyBufferTo:inBuffer];
err = AudioQueueEnqueueBuffer(queue, inBuffer, numPackets,
packet.packetDescriptions);
} @finally {
[packet release];
}
} else {
// Give the buffer back - we can't do anything (we have no data)
err = AudioQueueEnqueueBuffer(queue, inBuffer, 0, nil);
}
if(err) {
[self log:@"Error while enqueing, %ld", err];
}
}
What is the recommended (or any way would be nice) way to send
silence and correctly enqueue the buffer if the output format
isn't PCM?
I've tried setting the first byte of the buffer to zero, with a
size of one (this works for the PCM case) - and while this doesn't
return an error, after I do this the output proc for the queue is
no longer called (I presume I've confused it's internal state
somehow).
--
Regards,
Neil Clayton
_______________________________________________
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
_______________________________________________
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