Still having problems with ac3 in DVD Player
Still having problems with ac3 in DVD Player
- Subject: Still having problems with ac3 in DVD Player
- From: Fabian Renn <email@hidden>
- Date: Wed, 10 Aug 2005 19:08:15 +0200
Hello Jeff, Mark and list-members,
i've finally gotten 1536 samples per buffer to work smoothly with all
applications like iTunes, Garage Band etc. HALLab IO Telemetry is
telling me that the audio doesn't overload anymore. ;-). But... the
DVD Player doesn't want to work: worse: now it crashes :-( ( in the
clipOutputSamples routine ( !! COPY BELOW !! ), even though i check
if the sum of numSampleFrames + firstSampleframe is too big ) ! Mark
Cooksen already gave me a helpful submission in "Re: SPDIF audio in
DVD Player" ( copy below ), telling me that the DVD Player is giving
me 16 bit SInt samples and not 32 bit float samples, like one would
suspect. But looking into the sources of 'AppleAC97Audio-5' i saw
that the clipOutputSamples doesn't treat ac3 differently than PCM
audio data. What am I doing wrong? Is there a tech note out there
about how the DVD Player handles AC3 audio?
Greetings
Fabian
IOReturn AudioEngine::clipOutputSamples(const void *mixBuf, void
*sampleBuf, UInt32 firstSampleFrame, UInt32 numSampleFrames, const
IOAudioStreamFormat *streamFormat, IOAudioStream *audioStream) {
// SEE! I even check if the frame numbers are too large, like
Mark Cooksen suggested ;-)
if ( ( firstSampleFrame + numSampleFrames ) > ( unsigned int )
current_buffer_size ) return kIOReturnSuccess;
if ( streamFormat->fBitDepth == 16 ) {
if ( streamFormat->fSampleFormat ==
kIOAudioStreamSampleFormat1937AC3 ) {
// just copy the bytes
SInt16 * srcBuf;
SInt16 * dstBuf;
srcBuf = &( ( ( SInt16 * ) mixBuf )[firstSampleFrame *
streamFormat->fNumChannels] );
dstBuf = &( ( ( SInt16 * ) sampleBuf )[firstSampleFrame
* streamFormat->fNumChannels] );
int samples = streamFormat->fNumChannels * numSampleFrames;
while ( samples ) {
* dstBuf = OSSwapConstInt16( * srcBuf ); // <- POINT
OF CRASH
dstBuf++;
srcBuf++;
samples--;
}
return kIOReturnSuccess;
} else {
float * floatMixBuf = &( ( ( float * ) mixBuf )
[firstSampleFrame * streamFormat->fNumChannels] );
SInt16 * dstBuf = &( ( ( SInt16 * ) sampleBuf )
[firstSampleFrame * streamFormat->fNumChannels] );
// implemented in apple's PCMBlitterLib.c
Float32ToSwapInt16( floatMixBuf, dstBuf, streamFormat-
>fNumChannels * numSampleFrames );
return kIOReturnSuccess;
}
} else {
float * floatMixBuf = &( ( ( float * ) mixBuf )
[firstSampleFrame * streamFormat->fNumChannels] );
SInt32 * dstBuf = &( ( ( SInt32 * ) sampleBuf )
[firstSampleFrame * streamFormat->fNumChannels] );
// implemented in apple's PCMBlitterLib.c
Float32ToSwapInt32( floatMixBuf, dstBuf, streamFormat-
>fNumChannels * numSampleFrames );
return kIOReturnSuccess;
}
}
Copy of Mark Cookson's Mail:
Your clipOutputSamples routine gets passed the raw 16-bit stereo
data, you
don't need to do any conversion to it. Your buffer should be
taking 1536
samples per buffer for AC-3.
I've noticed that, occasionally, I'll get a call to
clipOutputSamples that
has a bogus number of samples, well in excess of 1536. In those
cases, I
just immediately return from clipOutputSamples and there is no
detectable
loss of audio (which is quite strange as well).
The telemetry is saying that the HAL is complaining about your time
stamps and is overloading (thus dropping data on the floor). In this
specific case, it is saying that your time stamp is early. Early
means that the time stamp says it is for a time that is very large
amount of time before the time the HAL's clock predicted for the next
time stamp.
The HAL only looks for early time stamps for devices that declare
that they are relatively constant rate via the
kIOAudioEngineClockIsStableKey key in the IO registry. In the absence
of that key, the HAL assumes that the device is relatively constant
rate if it has the USB transport type. Note that you set this key's
value with the method IOAudioEngine::setClockIsStable().
On Aug 8, 2005, at 8:10 AM, Fabian Renn wrote:
Hi again,
The problem with usb audio, is that the HAL can only get an update
about the buffer locations every 1 ms and the time stamp resolution
is at most 1 ms ( because a usb frame takes 1 ms to process ). I'm
already trying to smooth this out as much as possible: first of
all, i try to smooth out my outgoing frames as much as possible, so
that there are not too many variations of how many bytes are
transfered with each isoc frame; i take a time stamp of the
frTimeStamp value for every frame that will cause a wrap.
...
Greetings
Fabian
_______________________________________________
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