I now ran into the very same problem on my ADP phone as well after
applying settings for more strict JNI checking: by default, JNI
checking is active on the emulator but not on the phone, so that is
why I did not readily see it on the phone until activating JNI
checking there for unrelated reasons. I have now filed a bug report at
http://code.google.com/p/android/issues/detail?id=3234
Regards
On Jul 6, 4:07 am, Morné Pistorius <mpistor...@gmail.com> wrote:
> Ah, thanks for the hint. I assumed the same thing would happen on the
> device, but never checked it outside the emulator...
>
> Regards,
> Morne
>
> On Jul 3, 5:54 pm, blindfold <seeingwithso...@gmail.com> wrote:
>
> > I should add that I only see theGREFcount increasing with the
> > emulator, not when I run my app on the ADP (connected via USB). On the
> > ADP I did even after over 300AudioTrackcreations not get the message
> > thatGREFcount went above 101 or whatever. I use SDK 1.5 r2 and my
> > ADP has Cupcake. Curiously, I also found thatGREFgrows fast when
> > using some native code from the NDK 1.5 r1 on the SDK 1.5 r2 emulator,
> > and not when running the same native code on the ADP. Is the
> > emulatormemorymanagement somehow different from Cupcake on ADP?
>
> > Regards
>
> > On Jul 3, 12:25 pm, blindfold <seeingwithso...@gmail.com> wrote:
>
> > > Yes, I'm facing the exact same problem. It looks like a bug in
> > >AudioTrack. For me theGREFcount seems to increase by 2 for every
> > > creation and use ofAudioTrack, and it never goes down. I do not see
> > > this problem when instead creating and using MediaPlayer (and writing
> > > synthesized sound to flashmemory), supporting the conclusion that the
> > > problem lies withAudioTrack.
>
> > > Thanks
>
> > > On Jun 27, 5:59 pm, Morné Pistorius <mpistor...@gmail.com> wrote:
>
> > > > Hi all,
>
> > > > If I create and release multipleAudioTrackobjects, theGREFcount
> > > > continually increases which eventually causes an application crash.
> > > > This small test code snipped illustrates the problem:
>
> > > > byte[] buffer = readAudioFile( "audio.raw" );
> > > > for ( int n = 0; n < 10; ++n )
> > > > {
> > > > for ( int i = 0; i < 100; ++i )
> > > > {
> > > > Log.v("Info", "Track " + n + "," + i );
> > > > AudioTracknewTrack = newAudioTrack
> > > > ( AudioManager.STREAM_MUSIC, 16000,
> > > >
> > > > AudioFormat.CHANNEL_CONFIGURATION_MONO,
>
> > > > AudioFormat.ENCODING_PCM_16BIT,
>
> > > > buffer.length,AudioTrack.MODE_STATIC );
>
> > > > newTrack.write( buffer, 0,
> > > > buffer.length );
> > > > newTrack.flush();
> > > > newTrack.release();
> > > > }
>
> > > > Runtime.getRuntime().gc();
> > > > }
>
> > > > Even with a forced garbage collection, I end up with the same
> > > > highGREFcount at the end of the loop. In my application, I continuously
> > > > create AudioTracks from variable lenght buffers. I guess I can try
> > > > and use a fixed size pool of AudioTracks each with a buffer large
> > > > enough to fit my longest sound, and try and reuse them. Is there a
> > > > better/correct way to completely clear resources used by an
> > > >AudioTrack?
>
> > > > Any help will be greatly appreciated,
> > > > Thanks!
> > > > Morne
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
