Thanks for your reply Eric.
Based on your imputs, I have some observation -
MDF Audio decoder creates MDF audio device and calls Init() on audio
device to replace the default audio device in audio session. It seems
MDF audio decoder does not open audio device, its audio session, after
picking up a format, opens the audio device.
Based on the above observation, I have implemented CheckFormat function
without checking if the device is Open -
//
// IHXAudioDevice::CheckFormat
// - This method check the capability of audio device
// for a given audio format
//
HX_RESULT CHXMDFAudioDevice::CheckFormat(const HXAudioFormat*
pAudioFormat) {
HXLOGL2(HXLOG_MDFA,"mdfdev:ChkFormat <>");
HX_RESULT res = HXR_FAIL;
if (pAudioFormat)
{
if (m_pAudioFormat->m_uChannels == pAudioFormat->uChannels &&
m_pAudioFormat->m_uBitsPerSample ==
pAudioFormat->uBitsPerSample &&
m_pAudioFormat->m_ulSamplesPerSec ==
pAudioFormat->ulSamplesPerSec)
{
res = HXR_OK;
}
}
return res;
}
This implementation checks if the asked audio format is same as the
audio device's format when the device was created by the decoder.
Please let me know if I am missing something here.
Thanks,
- Asheesh
>-----Original Message-----
>From: ext Eric Hyche [mailto:[EMAIL PROTECTED]
>Sent: Friday, October 31, 2008 3:13 PM
>To: Srivastava Asheesh (EXT-Infovision-MSW/Dallas);
>[email protected]; [EMAIL PROTECTED]
>Cc: Milko Boic
>Subject: RE: [Audio-dev] Discrepancy in channel count
>
>Asheesh,
>
>Here is the sequence of events as I understand them:
>
>1) Media playback engine initializes all renderers, meaning
> that OnHeader() gets called for all renderers. So
> during this call for the MDF audio renderer, it opens
> the MDF audio decoder, which in turn opens the MDF audio
> device. In this case, it's opening the MDF audio device
> as mono.
>2) Once the media playback engine initializes all renderers,
> then it sets up the audio player. The audio player looks
> through all its audio streams and picks the "best" audio
> format to use. Also, in this case, it forces the format
> to be stereo.
>3) Once it has picked its format, then the audio player
> sets up the audio session. During the audio session
> ::Setup, it will call IHXAudioDevice::CheckFormat()
> with different formats. As soon as it finds an audio
> format for which IHXAudioDevice::CheckFormat() returns
> success, then that's the format it will use to
> open the audio device.
>4) Now that the audio session has picked a format, then
> it will open the audio device with that format.
>
>So what I would expect to happen is that when the audio
>session is calling the MDF audio device with CheckFormat() in
>step 3 above, then the MDF audio device would realize that
>it's already been opened as mono, so it would return failure
>for any formats except the format that it was opened by the
>MDF audio decoder.
>
>However, what I see when looking at
>CHXMDFAudioDevice::CheckFormat() is this:
>
>HX_RESULT CHXMDFAudioDevice::CheckFormat(const HXAudioFormat*
>pAudioFormat) {
> HXLOGL4(HXLOG_MDFA,"mdfdev:ChkFormat <>");
> HX_RESULT res = HXR_OK;
>
> return res;
>}
>
>so it's returning success to the very first CheckFormat() call.
>
>So CHXMDFAudioDevice::CheckFormat() needs to be implemented
>correctly in order to fix this problem.
>
>Eric
>
>=======================================
>Eric Hyche ([EMAIL PROTECTED])
>Principal Engineer
>RealNetworks, Inc.
>
>
>>-----Original Message-----
>>From: [EMAIL PROTECTED]
>>[mailto:[EMAIL PROTECTED]
>>Sent: Thursday, October 30, 2008 5:15 PM
>>To: [EMAIL PROTECTED]; [email protected];
>>[EMAIL PROTECTED]
>>Subject: RE: [Audio-dev] Discrepancy in channel count
>>
>>Hi Eric,
>>
>>Thanks for your response. Please find my response inlined - FYI, I am
>>working on HEAD.
>>
>>- MDF audio renderer is playing a mono stream, so it opens its DSP
>> decoder at mono, which results in the MDF audio device getting
>> opened at mono. Is this correct?
>>
>>That's correct, Following is the flow -
>>
>>HXMDFAudioAac::UpdateConfigForAac()
>>HXMDFAudioAac::UpdateConfig()
>>HX_RESULT HXMDFAudioAac::OpenConfig(UINT32 cfgType, const
>void* config,
>>UINT32 nBytes)
>>HX_RESULT CHXMDFAudioDecoder::OpenDecoder( THIS_ UINT32 cfgType, const
>>void* config, UINT32 nBytes)
>>HX_RESULT CMP4AudioFormat::Init(IHXValues* pHeader)
>>
>>And then OpenDecoder creates the audio device.
>>
>>Even if the play-back clip has channel info as 2 (stero), MDF audio
>>renderer reads it as mono and pass it on to decoder and then to audio
>>device as you said.
>>
>>In Arm side (datatype\mp4\audio\mdf\platform\symbian\audioconfigs.cpp)
>>HX_RESULT HXAudioConfiguratorAAC::StoreDecoderInfo() manipulates
>>channels count and makes it as stero (2).
>>
>>
>>- Then, the CHXAudioSession opens the MDF audio device as stereo.
>> How is the MDF audio device handling this? Is it ignoring the
>> format that the CHXAudioSession opens it with?
>>
>>Yes, CHXAudioSession opens the MDF audio device as stereo -
>>
>>Following is the flow -
>>
>>HX_RESULT CHXAudioPlayer::Setup( ULONG32 ulGranularity)
>>
>>HX_RESULT HXPlayer::SetupAudioPlayer(UINT32 &ulSchedulerFlags)
>>
>>
>>And then during HX_RESULT CHXAudioSession::Setup(HXBOOL bHasStreams),
>>GetDeviceFormat() is called, where it overides the channel count from
>>the audio player and based on the overidden audio format, playback
>>buffer is created and then OpenDevice() is called.
>>
>>Since in CHXAudioPlayer::Setup, channel count is modifed to 2, audio
>>device is unable to handle it and resulting into inserting
>filler frame
>>here and there.
>>
>>In HEAD as channel count is modified from mono to streo in
>audio player
>>(from session) making m_uBytesPerFrame, m_uSamplesPerFrame,
>>m_uMsPerFrame etc incosistent with channels.
>>
>>and then in CHXMDFAudioDevice::Write(), in following condition
>>
>> // Check for enough data to write
>> while ( m_nBytesPCMToPlay >= m_pAudioFormat->m_uBytesPerFrame )
>> {
>> :
>> :
>> :
>> }
>>
>>1. m_nBytesPCMToPlay is calulated based on data size and data size
>>depends on channel count which becomes double.
>>
>>2. m_pAudioFormat->m_uBytesPerFrame remains same as if there is only
>>one channel.
>>
>>3. More silence frames get added resulting in breaks.
>>
>>
>>In Cayenne, audio player doesn't modify channel count so
>>m_uBytesPerFrame etc remain same.
>>
>>
>>Regards,
>>- Asheesh
>>
>>>-----Original Message-----
>>>From: ext Eric Hyche [mailto:[EMAIL PROTECTED]
>>>Sent: Thursday, October 30, 2008 9:59 AM
>>>To: Srivastava Asheesh (EXT-Infovision-MSW/Dallas);
>>>[email protected]; [EMAIL PROTECTED]
>>>Subject: RE: [Audio-dev] Discrepancy in channel count
>>>
>>>From looking at the RA renderer code that this comment refers to, it
>>>looks like that the workaround is no longer needed.
>>>
>>>From the comment, it appears that the RA renderer used to only call
>>>IHXAudioStream::Init() on the first substream when a SureStream
>>>(multi-rate) stream was played. Then, as it received packets
>for other
>>>substreams, then it created and Init'd those IHXAudioStreams.
>>>
>>>However, the current RA renderer creates and Init's an
>IHXAudioStream
>>>for each substream. So it would appear that this workaround is no
>>>longer needed.
>>>
>>>However, this does raise this question: it doesn't appear
>that the MDF
>>>audio device is handling the case when the CHXAudioSession opens it
>>>with a format it did not expect. I would assume what happens in the
>>>case you are describing it this:
>>>
>>>- MDF audio renderer is playing a mono stream, so it opens its DSP
>>> decoder at mono, which results in the MDF audio device getting
>>> opened at mono. Is this correct?
>>>- Then, the CHXAudioSession opens the MDF audio device as stereo.
>>> How is the MDF audio device handling this? Is it ignoring the
>>> format that the CHXAudioSession opens it with?
>>>
>>>Eric
>>>
>>>=======================================
>>>Eric Hyche ([EMAIL PROTECTED])
>>>Principal Engineer
>>>RealNetworks, Inc.
>>>
>>>
>>>>-----Original Message-----
>>>>From: [EMAIL PROTECTED]
>>>>[mailto:[EMAIL PROTECTED] On Behalf Of
>>>>[EMAIL PROTECTED]
>>>>Sent: Wednesday, October 29, 2008 5:34 PM
>>>>To: [email protected]; [EMAIL PROTECTED]
>>>>Subject: [Audio-dev] Discrepancy in channel count
>>>>
>>>> Hi
>>>>
>>>> Below mentioned code works fine with ARM/Software
>>>decoder but not with
>>>>DSP decoder
>>>>
>>>> File: \client\audiosvc\hxaudply.cpp
>>>> Function: HX_RESULT CHXAudioPlayer::Setup( ULONG32
>>>ulGranularity)
>>>>
>>>> // keep min. channel at stereo
>>>> // this is a workaround for b#205546, the root
>>>cause of this is that we only
>>>> // choose the audio format of the 1st audio
>>>stream when the playback is started
>>>> // without audio, then audio clip is started at
>>>later time. For sure stream audio,
>>>> // the first audio stream is often the lowest
>>>quality, thus the audio device is
>>>> // configured to play the lowest quality audio.
>>>> //
>>>> // proper fix requires the audio device is
>>>setup only after all audio streams
>>>> // assoicated with the same clip have been registered
>>>> m_PlayerFmt.uChannels = (maxChannels
>>>< 2) ? 2 : maxChannels;
>>>>
>>>> Prob with DSP - If we calculate channel count as above
>>>[which makes
>>>>channel count as 2], then call to HX_RESULT
>>>>CHXAudioSession::CreatePlaybackBuffer() doubles the size of
>>>the session
>>>>buffer [m_pSessionBuf] as its based on channel count. Then call to
>>>>HX_RESULT CHXMDFAudioDevice::Write(const
>>>>HXAudioData* pHXAudioData) keeps adding filler (silence) frames in
>>>>between resulting into silence and breaks in audio play-back.
>>>>
>>>> If we don't apply above work-around, and revert back to
>>>normal. i.e.:
>>>> m_PlayerFmt.uChannels = maxChannels;
>>>> then audio play-back works fine.
>>>>
>>>> So, how do we take care of above mentioned workaround for DSP?
>>>>
>>>> Regards
>>>> Asheesh
>>>>
>>>
>>>
>>>
>
>
_______________________________________________
Audio-dev mailing list
[email protected]
http://lists.helixcommunity.org/mailman/listinfo/audio-dev