Re: AAC-HE Playback bug

[ThaCrip]

I've never had the fuze+ so much as stutter on flac or mp3 files but I also have no opus files what so ever.  I can test one that stutters on your device if you like.

FLAC or MP3 work 100% on my Sansa e250 v1 as i got no problems at all as menu navigation works as expected when playing those files etc.

It's the 'AAC SBR+PS' (i.e. HE-AACv2 spec (https://upload.wikimedia.org/wikipedia/commons/3/37/AAC_profiles.svg )) that acts up which i imagine is due to lack of CPU power on the e250 v1. if i play files on the AAC-LC spec then everything on my Sansa e250 v1 works as expected.

also, that AAC SBR+PS (basically HE-AACv2) pretty much takes effect on the Winamp FhG encoder when you go below 96kbps setting as once you hit the 96kbps+ setting it shifts back to the AAC-LC profile which plays fine since it uses less CPU. with Apple AAC i can use 64kbps setting and still get AAC-LC but at lower bit rates it appears the advanced AAC profile takes over which uses special tricks to make the sound quality better but, apparently, is a bit more CPU intensive.

here is a quick download link which contains both a AAC 32kbps file (actual average bit rate of file is 37kbps) with that AAC SBR+PS for the 'codec profile' info and a 64kbps encoded Opus file (actual average bit rate is 68kbps (it's encoded with Opus v1.2.1 through Foobar2000))... http://www.datafilehost.com/d/7dc66e0b ; what i am assuming happens in why these act up is simply a lack of CPU power as, like i was saying, that 'AAC SBR+PS' file once i load it pretty much makes my e250 unusable (music plays a bit, stops during playback a bit, plays etc. but navigating any menus during that basically ain't going to happen) and i have to hold power button down to power it off and back on and then things are okay again unless i play a music file encoded like that.

as far as the Opus issue i mentioned... while those files playback fine, i assume must be at least somewhat taxing the e250's CPU because when you have a Opus file playing, it does not matter whether it's 32kbps or 128kbps, if you start navigating through menu's on your e250 player it's sluggish and not quick to respond like it normally is when playing FLAC/MP3/AAC-LC etc even though the music playback is totally fine from what i have noticed. also, if you fast forward or rewind during that Opus file playback, while it does work, there is a noticeable delay before playback resumes where as with your typical FLAC/MP3/AAC-LC playback resumes immediately as expected.

NOTE: the AAC SBR+PS file plays fine on my computer using Foobar2000.

also, that 'AAC SBR+PS' file is simply encoded in Foobar2000 (from a FLAC file, naturally) using the Winamp FhG encoder. it's a couple of files (i.e. enc_fhgaac.dll and libmp4v2.dll) i extract out of the newest Winamp installer and put into the Foobar2000 'encoders' directory which allows you to use that "AAC (Winamp FhG)" (you see in the picture i attached) encoder to encode AAC files through Foobar2000.

i have attached a couple of pictures showing you some details from Foobar2000.

Thanks for your time

p.s. i am using Foobar2000 v1.3.16 with the newest encoder pack (i.e. http://www.foobar2000.org/encoderpack ) which is from June 27th 2017 and includes the newest Opus v1.2.1 encoder and makes it easy to make Opus files etc from your FLAC files etc.

also, i have not checked battery life with those Opus files but i would not be surprised if there was a solid drop off given that whole sluggish thing assuming it's taxing the CPU like i suspect it is. and another thing... with that whole sluggish menu's on the playback of Opus files, i noticed if i load up a file and let it play for a bit (like where the e250 screen powers down but the music is still playing) and then go back into the menu navigation i noticed sometimes it smooths out for a little bit before that sluggishness returns etc. i would have to play with this a bit more to see if i can get it to react consistently on this particular thing i just mentioned.

also, basically it appears that FhG encoder is one of the best encoders to use at really low bit rates but, from what i heard IgorC say (a January 2017 post) over on hydrogenaudio forums he said, and i quote... "There is no AAC encoder better than Apple at 96 kbps and higher.  As simple as that." ; which is what i generally use (through QAAC.exe in Foobar2000 (which that file is installed to Foobar2000's 'encoders' directory from the Foobar2000 encoder pack) using the AppleApplicationSupport.msi file extracted out of the iTunes installer and installed) which gives me the usual AAC-LC profile on AAC encoded files which my e250 plays perfectly fine.

[Bilgus]

I remember you had mentioned this issue before I went ahead and split this in its own topic so we can discuss it further

The fuze+ didnt have any problems playing your AAC-HE file as long as it wasn't the first one I played

But when it was the first track I played it exibited the symptoms you noted

So I'm going to have a look into this, best I can tell is it isn't setting up the pcm buffer properly

Could you try the same on your player play the opus first and then play the AAC-HE file and see if it exibits the sdame behaviour?

[saratoga]

I've never had the fuze+ so much as stutter on flac or mp3 files but I also have no opus files what so ever.  I can test one that stutters on your device if you like.

FLAC or MP3 work 100% on my Sansa e250 v1 as i got no problems at all as menu navigation works as expected when playing those files etc.

It's the 'AAC SBR+PS' (i.e. HE-AACv2 spec (https://upload.wikimedia.org/wikipedia/commons/3/37/AAC_profiles.svg )) that acts up which i imagine is due to lack of CPU power on the e250 v1. if i play files on the AAC-LC spec then everything on my Sansa e250 v1 works as expected.

We put a ton of work in optimizing AAC, but I think HE is not possible on an 80 MHz ARM7TDMI CPU, or at least without extreme effort.  The format is very slow.

Anyway, I thought we already discussed this.  You need to configure your encoder to produce AAC-LC files.

[Bilgus]

Originally this started as just a test to see if AAC-HE files played on the fuze+ without issue
It has now turned into a bug

If its the first track played it skips but no issue if you skip to another track then back.
No issue if you play another track first and then the AAC-HE file

At 3.14 the problem exists
At HEAD the same issue exists but strangely when I locked the frequency to 64MHZ (#define CPUFREQ_MAX     IMX233_CPUFREQ_64_MHz) it played fine not sure why at this point.

I initially though it might have to do with the watermark not triggering the cpu boost but now I'm pretty sure that isn't it since locked at 64mhz it worked perfectly fine so maybe a voltage issue???

These were all tested with the music playing from an sdcard
I'll have to look into it further but suggestions are welcome..

[saratoga]

You shouldn't be able to decode AAC-HE at 64 MHz on the IMX233 (probably needs at least double that), so are you sure the clock frequency is actually being set to 64 MHz? 

[Bilgus]

Well i'll try and removing all the cpu_boost code and see if it still holds true but pretty sure setting CPUFREQ_MAX does the same

[saratoga]

Might be worth running test_codec to check that decode speed is what it should be for the expected clock frequency.

[ThaCrip]

The fuze+ didnt have any problems playing your AAC-HE file as long as it wasn't the first one I played

What about the Opus file?

does your Fuze+ act like my e250 v1 does where it plays the music fine but menus get a bit sluggish and there is a bit of delay between resuming of music playback if you rewind or fast forward a bit within that music file?

Could you try the same on your player play the opus first and then play the AAC-HE file and see if it exibits the sdame behaviour?

I just tested it with those same two files. I played the Opus first for 5-10 seconds and then skipped forward to the next track which was that AAC-HE file and... it still does what i mentioned with it playing a little (a couple of seconds or so tops), music stops a bit, resumes etc.

p.s. also, that must tax my battery when that AAC-HE file plays as the Rockbox battery measurement drops off quite a bit as the thing was roughly 85-90% and dropped back into the 30 something percent range. but once i managed to get it back to the Opus track the battery meter slowly climbed back up and is currently back to 90%. so the load on the CPU must tax the battery (it's not the original battery but one i got on Ebay about a year or two ago which i imagine the battery quality is not exactly high grade as it's HQRP brand).

Anyway, I thought we already discussed this.  You need to configure your encoder to produce AAC-LC files.

Yes, your right. that's why i pretty much settled on converting my FLAC collection to Apple AAC q63(TVBR) @ 128kbps in general along with Opus @ 64kbps for music i am not too concerned with high quality(but still solid enough quality) but helps save plenty of storage space as before the conversion of my music i was using about 14.5GB (when things were largely MP3 LAME v2(190kbps)) on that 16GB card and now it's dropped down to less than half full (i.e. less than 8GB) so i should be good for the foreseeable future now with that 16GB MicroSDHC card. i still got a few odds and ends to transfer to it yet but even after i am done with that the 16GB card will be roughly half full.

but like Bilgus said, we wondered whether those AAC-HE files (and the Opus file) would play on his Fuze+ without issue and apparently he found a bug.

These were all tested with the music playing from an sdcard

Same here. i played mine from the 16GB MicroSDHC card i mentioned in my signature.

[Bilgus]

Test Codec Results Fuze+ AAC-HE

Build	Decode Time (s)	% realtime	MHz Needed
Normal - No Boost	1122.91s	30.97%	206.65Mhz
Normal - No Boost#2	1125.74s	30.89%	207.18MHz
Normal Boost	295.55s	117.68%	386.42Mhz
454Mhz No Boost	295.57s	117.68%	386.42Mhz
454Mhz Boost	295.58s	117.67%	386.45Mhz
fdiv 19 No Boost	802.73s	43.33%	147.7Mhz
hclk 21.33 fdiv 19 No Boost	873.27s	39.83%	160.66Mhz
hclk 21.33 fdiv 19 act 0 No Boost	1415.10s	24.57%	260.48Mhz
VDDD 1450 _BO 1350	1122.98s	30.97%	206.65Mhz

BELOW lists ALL changes made to the build for the specified test

system-target.h Normal:(no changes)

Code: [Select]

#define IMX233_CPUFREQ_454_MHz  454740000
#define IMX233_CPUFREQ_320_MHz  320000000
#define IMX233_CPUFREQ_261_MHz  261820000
#define IMX233_CPUFREQ_64_MHz    64000000
#define IMX233_CPUFREQ_24_MHz    24000000

system-target.h Locked 64Mhz:

Code: [Select]

#define IMX233_CPUFREQ_64_MHz    64000000
#define IMX233_CPUFREQ_454_MHz  IMX233_CPUFREQ_64_MHz//454740000
#define IMX233_CPUFREQ_320_MHz  IMX233_CPUFREQ_64_MHz//320000000
#define IMX233_CPUFREQ_261_MHz  IMX233_CPUFREQ_64_MHz//261820000
//#define IMX233_CPUFREQ_64_MHz    64000000
#define IMX233_CPUFREQ_24_MHz    24000000

system-target.h Locked 454Mhz:

Code: [Select]

#define IMX233_CPUFREQ_454_MHz  454740000
#define IMX233_CPUFREQ_320_MHz  IMX233_CPUFREQ_454_MHz//320000000
#define IMX233_CPUFREQ_261_MHz  IMX233_CPUFREQ_454_MHz//261820000
#define IMX233_CPUFREQ_64_MHz    IMX233_CPUFREQ_454_MHz//64000000
#define IMX233_CPUFREQ_24_MHz    IMX233_CPUFREQ_454_MHz//24000000

system-imx233.h fdiv 19:

Code: [Select]

static struct cpufreq_profile_t cpu_profiles[] =
{...
    /* clk_p@64 MHz, clk_h@64 MHz, clk_emi@64 MHz, VDDD@1.050 V (or 1.275V) */
    {IMX233_CPUFREQ_64_MHz, VDDD_MIN, 975, 1, 5, (19), EMIFREQ_NORMAL, 3},

system-imx233.h VDDD + hclk 21.33:

Code: [Select]

static struct cpufreq_profile_t cpu_profiles[] =
{...
    /* clk_p@64 MHz, clk_h@21.33 MHz, clk_emi@64 MHz, VDDD@1.550 V*/
    {IMX233_CPUFREQ_64_MHz, (1550), (1450), (3), (1), (19), EMIFREQ_NORMAL, (0)},

system-imx233.h hclk 21.33 fdiv 19:

Code: [Select]

static struct cpufreq_profile_t cpu_profiles[] =
{...
    /* clk_p@64 MHz, clk_h@21.33 MHz, clk_emi@64 MHz, VDDD@1.050 V (or 1.275V) */
    {IMX233_CPUFREQ_64_MHz, VDDD_MIN, 975, (3), 5, (19), EMIFREQ_NORMAL, 3},

system-imx233.h hclk 21.33 fdiv 19 act 0:

Code: [Select]

static struct cpufreq_profile_t cpu_profiles[] =
{...
    /* clk_p@64 MHz, clk_h@21.33 MHz, clk_emi@64 MHz, VDDD@1.050 V (or 1.275V) */
    {IMX233_CPUFREQ_64_MHz, VDDD_MIN, 975, (3), 5, (19), EMIFREQ_NORMAL, (0)},

system-imx233.h VDDD 1450 _BO 1350:

Code: [Select]

static struct cpufreq_profile_t cpu_profiles[] =
{...
    /* clk_p@64 MHz, clk_h@64 MHz, clk_emi@64 MHz, VDDD@1.450 */
    {IMX233_CPUFREQ_64_MHz, (1450), (1350), 1, 5, 27, EMIFREQ_NORMAL, 3},

Code: [Select]

Normal Build No Boost:

07. Desperation- FhG 32kbps.m4a
347693 of 347834
Decode time - 1122.91s
File duration - 347.83s
30.97% realtime
206.65MHz needed for realtime

Next Time.mp3
250241 of 250261
Decode time - 188.06s
File duration - 250.26s
133.07% realtime
48.09MHz needed for realtime


Normal Build No Boost#2:

07. Desperation- FhG 32kbps.m4a
347693 of 347834
Decode time - 1125.74s
File duration - 347.83s
30.89% realtime
207.18MHz needed for realtime


Normal Build Boost:

07. Desperation- FhG 32kbps.m4a
347693 of 347834
Decode time - 295.55s
File duration - 347.83s
117.68% realtime
386.42MHz needed for realtime


Locked at 64MHz No Boost:

07. Desperation- FhG 32kbps.m4a
347693 of 347834
Decode time - 293.45s
File duration - 347.83s
118.53% realtime
53.99MHz needed for realtime


Locked at 64MHz No Boost#2:

07. Desperation- FhG 32kbps.m4a
347693 of 347834
Decode time - 293.83s
File duration - 347.83s
118.37% realtime
54.06MHz needed for realtime


Locked at 64Mhz Boost:

07. Desperation- FhG 32kbps.m4a
347693 of 347834
Decode time - 293.45s
File duration - 347.83s
118.53% realtime
53.99MHz needed for realtime


Locked at 454MHz No boost:

07. Desperation- FhG 32kbps.m4a
347693 of 347834
Decode time - 295.57s
File duration - 347.83s
117.68% realtime
386.42MHz needed for realtime

Locked at 454MHz Boost:

07. Desperation- FhG 32kbps.m4a
347693 of 347834
Decode time - 295.58s
File duration - 347.83s
117.67% realtime
386.45MHz needed for realtime

[ThaCrip]

Correct me if i am wrong, but are you saying it's possible to play that AAC-HE file on my 80mhz CPU without the major CPU issues i have? ; if so, are there any draw backs to those tweaks?

because in the test above, on some parts of it, it shows you only need 54Mhz to play it.

[saratoga]

You need 200 -400MHz to decode that file. Since the 64  MHz results don't get slower, the clock changes aren't actually working. The CPU is running at the same speed in every test except the first two.

[Bilgus]

Correct me if i am wrong, but are you saying it's possible to play that AAC-HE file on my 80mhz CPU without the major CPU issues i have? ; if so, are there any draw backs to those tweaks?

because in the test above, on some parts of it, it shows you only need 54Mhz to play it.

those tweaks are only on the imx233 which your player doesn't have and i'm not sure whats going on yet but saratoga may very well be right that the cpu speed isn't changing but I have a few more tests running atm that i'll update in my post
 either way I'm thinking its the fuze+ with the issues not the AAC decoder

[Bilgus]

I think what could very well be happening is one of the divisors overflows the clock speed and rolls the number around then the clock goes to max even though the device displays that it is at 64 Mhz but that still doesn't explain why 64Mhz with no boost works right and why if you play another song first the AAC file plays fine even with the normal (untouched) settings

Edit: No I understand now..

the table in the second half of the tests is where the cpu frequency is actually set So in the first tests it matches the one for 454MHZ and that gets set even though the device THINKS its at 60 MHZ

[Bilgus]

Ok so I ran a whole bunch of tests threw out half of them and finally we have a decent sampling

What isn't wrong, voltage, clock dividers etc.

what is wrong (still)
When the AAC file is the first thing played on the device the file skips and the buffer underruns
When the AAC file is played after a mp3 file -- WORKS FINE
When the AAC file is played starts skipping and you change tracks to a mp3 and go back --AAC FILE PLAYS fine

not sure if its the FUZE+ or the buffer code ATM More testing soon

[saratoga]

Unrelated question, but what is the RAM speed on the FUze+?  Does it change when you boost?  AMSv2 with the same processor only needs about 100 MHz.