Yes I I know but that doesn't mean rollback buffer can not be (or
shouldn't be) reset in base class. You need to write a baseclass
_CloseAudio method and do rollback buffer deletion there and call it
from Android derived class's _CloseAudio method. Or, you could find out
where it calls _CloseAudio in base class and add the rollback buffer
management logic there, outside the _CloseAudio call.
This is not just Android platform, on any platform the TLC could create
audio device directly and use it as 'custom' audio device. You'll have
this rollback buffer management issue in those cases too. You basically
found a defect in base class's management of rollback buffer, and it
should be fixed there.
fxd
Gurpreet wrote:
Hi,
On linux, audio service have freedom of closing the audio device and
creating a new one, It calls _imp_close, on audio device when change of
sample rate is detected and number of stream reaches zero, in imp_close
rollback buffer is destroyed.
For android case, audio service will be using same instance of audio
device when sample rate changes. It doesnt call _imp_close because it does
not own it, its a replaced device. We would need to change the size of
rollback buffer and set it according to new sample rate. we also need to
set the state to close so that when next time imp_open is called we can
open the device with new sample rate.
Best Regards,
Gurpreet
_CloseAudio is called from somewhere in base class, not directly by TLC.
Base class should cleanup rollback buffer before/after it calls
_CloseAudio, or if it has a base _CloseAudio, cleanup there and modify
the derived class _CloseAudio to call base class first. You normally
don't create something in base class but delete it in derived class. The
derived class doesn't use rollback buffer directly in anyway, it really
shouldn't 'manage' it.
The logic to remove old audio stream in base renderer shouldn't be
wrapped around "#ifndef HELIX_FEATURE_RESAMPLER", but a new feature
name, or better yet, a dynamic flag m_bXXXX I think. E.g, for your AAC
SBR case, you want this logic even if resampler is on, otherwise you'll
always down-sample SBR content to base sample rate, kind of defeat the
purpose of SBR. Using a m_bXXX gives you the ability to control the
behavior on renderer basis. E.g, we need this now for mp4arend, but not
for rarend.
Otherwise looks good.
fxd
Gurpreet wrote:
Hi Sheldon,
Thanks for review.
I have removed the additional logic of resseting the player, as its not
needed.
Thanks for noticing that.
Rollback buffer is already deleted in imp_close of CAudioOutUnix.
The changes in audAndroid.cpp is needed because on android we don't use
imp_open/imp_close to open/close the audio device. imp_open is just a
dummy call.
TLC opens the audio device and replaces that in audio service.
So when audio service wants to reset it, it finds that its a replaced
device, there fore ignores this.
Also in AudOutUnix, when we check format, we are suppose to open and
close a new device but instead we use the same device created by TLC,
this is because of limitation by android.
Please find updated diffs attached.
Thanks,
Gurpreet
On 3/9/2010 8:37 PM, Sheldon Fu wrote:
rollback buffer belongs to the base class, CAudioOutUnix. The
cleanup/reset belongs there too.
In hxaudply.cpp, there is already a block of code (just below your
change) to handle the special case that the last stream is removed
from the list. The change, if any, should go in there I think. The
list search fix though should be in the first block and is a good
catch.
I don't think the additional logic of resetting the audio player and
audio session when last stream is removed is correct in general. It
may work for your single audio-only playback case but for more
complicated cases (e.g. 20s video and 10s audio starts at the same
time) Audio player is supposed to continue providing fake timeline
after all its audio streams are gone (this is evidential from the
logic handling AUD_PLYR_STR_REMOVE and (0 ==
m_pStreamList->GetCount()), namely the ResumeFakeTimeLine() call). If
you reset the player and session, likely you'll lose the timeline
continuity.
fxd
Gurpreet wrote:
Synopsis:
Changes to reset and remove audio stream from audio device when
decoders dynamically switch sample rate and Resampler is disabled.
Overview:
Some decoders may want to change sample rate dynamically i.e AAC SBR
decoder doubles the sample rate after implicitly detecting sbr
payload.
If resampler is off this case is not handled and we hear no audio.
Now for this we remove the old stream from audio player and add a new
stream to the audio player.
Changes have been done to audio service to reset the player when
stream count reaches zero so that we would be able to set it with new
sample rate.
Also when removing old stream we find it using IHXAudioStream pointer
instead of earlier IHXAudioStream3 pointer this is because we set
IHXAudioStream pointer in list when adding a stream.
A minor fix is also added to audio device on android to delete the
rollback buffer so that new rollback buffer can be created with
sample rate size.
Files Modified:
client/audiosvc/hxaudply.cpp
audio/device/platform/unix/audAndroid.cpp
datatype/common/audrend/audrend.cpp
Platforms and Profiles Build Verified:
BIF branch -> atlas 361
Target(s) -> android_all
Profile -> helix-client-android-surf_8x50
SYSTEM_ID -> android-donut-arm-qsd_8x50
Branch:
Atlas361
Files Attached:
Audrend.diff
audply.diff
audAnd.diff
Best Regards,
Gurpreet
.
_______________________________________________
Audio-dev mailing list
Audio-dev@helixcommunity.org
http://lists.helixcommunity.org/mailman/listinfo/audio-dev
