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
