Re: Still having problems with ac3 in DVD Player
Re: Still having problems with ac3 in DVD Player
- Subject: Re: Still having problems with ac3 in DVD Player
- From: alex <email@hidden>
- Date: Wed, 10 Aug 2005 13:27:30 -0400
Here are some obvious questions: is mixBuf valid? Also, you do not check that srcBuf is non-null. (I'm not saying performance critical code needs a million null checks, however when code is crashing it helps to check that case thoroughly).
Also, if you remove the swap operation (and directly assign dst to src (as a test)) does the problem go away?
a
At 7:08 PM +0200 8/10/05, Fabian Renn wrote:
>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
_______________________________________________
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