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: Neil Clayton <email@hidden>
- Date: Wed, 23 Jan 2008 17:15:12 +1300
- Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
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:
@apple.com
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