Related
I've just updated my firmware with the new CM7 RC4 release and Darlinger's OC Kernel (Released 3/31). According to the release log, they should support hardward decoding.
However, when I open MP4 files with RockPlayer, it still reports that this format is not supported with the system player.
Am I doing something wrong, or it still doesn't support hardware decoding?
Do these files play on other ROMs?
So far as I know, they would play with the rooted stock ROM. I'm not sure about Froyo or Honeycomb, though.
poofyhairguy said:
Do these files play on other ROMs?
Click to expand...
Click to collapse
Do a search for "nook color handbrake preset". You'll find a thread on all about how to encode mp4 videos to work on the nook. There are some options when encoding the video that when enabled will break playback on the nook color. Mainly the video resolution.
Thanks. But I don't really think that's an encoding issue. The file played perfectly with the stock rom and system video player.
woot1524 said:
Do a search for "nook color handbrake preset". You'll find a thread on all about how to encode mp4 videos to work on the nook. There are some options when encoding the video that when enabled will break playback on the nook color. Mainly the video resolution.
Click to expand...
Click to collapse
woot1524 said:
Do a search for "nook color handbrake preset". You'll find a thread on all about how to encode mp4 videos to work on the nook. There are some options when encoding the video that when enabled will break playback on the nook color. Mainly the video resolution.
Click to expand...
Click to collapse
If Nook Color' sample video cannot play by CM7 RC4 so hardware decoding is still disabled.
Here is the sample video from official Nook Color intro I extracted from latest firmware (1.10) :
http://www.mediafire.com/file/s5ka0xkdnsf4ajo/welcome_video.mp4
If default video player cannot play so hardware decoder still not enabled for CM7 RC4 and all variants...
Managing to play the video by means of diffrent 3rd party applications ( all video player that decode software and hardware based) make no sense...
Hmm I don't know what the deal is then... HW decoding is working brilliantly for me on CM7 RC-4 with latest OC kernel. I have a couple 720p mp4 movies that I re-encoded via the handbreak preset, and they played just fine.
woot1524 said:
Hmm I don't know what the deal is then... HW decoding is working brilliantly for me on CM7 RC-4 with latest OC kernel. I have a couple 720p mp4 movies that I re-encoded via the handbreak preset, and they played just fine.
Click to expand...
Click to collapse
Stock ROM from NC can play http://www.mediafire.com/file/s5ka0xkdnsf4ajo/welcome_video.mp4 videos but CM7 RC4 still cannot plays and they claim hardware video decoder enabled!...
Offical welcome_video.mp4 is the proof of CM7 RC4 is STILL software based...
Overclocking may help only software decoding? But I want to use hardware decoder and latest version not old one used 1.1.15.2766 .. NC's offical latest video decoder is 1.1.15.3172 for our NC ( PowerVR SGX 530)
NOBODY uses latest hardware because hardware decoding is still unusable... Acceptence of this current reality and then focusing on OVERCLOCKING CPU makes no sense when you have a hardware decoder's power ...
nemir said:
Stock ROM from NC can play http://www.mediafire.com/file/s5ka0xkdnsf4ajo/welcome_video.mp4 videos but CM7 RC4 still cannot plays and they claim hardware video decoder enabled!...
Offical welcome_video.mp4 is the proof of CM7 RC4 is STILL software based...
Overclocking may help only software decoding? But I want to use hardware decoder and latest version not old one used 1.1.15.2766 .. NC's offical latest video decoder is 1.1.15.3172 for our NC ( PowerVR SGX 530)
NOBODY uses latest hardware because hardware decoding is still unusable... Acceptence of this current reality and then focusing on OVERCLOCKING CPU makes no sense when you have a hardware decoder's power ...
Click to expand...
Click to collapse
Exactly! I was trying to make sense of this mess from January in my blog fineoils.blogspot.com. With a Nookie Froyo, Nookkolor started to lose everything that was there of hardware decoding AND hardware rendering. I was laghed at by CM7 NC dev dalingrin on my suggestion that lots of HW assistance in video playback is based on SGX, especially the HW overlay. CM7 team is of opinion that mp4/H.264 decoding can be made in DSP (IVA2 in our case) audio buffers for which were that "magic video fix" at the CM7 nightly 17 level. What we have is more or less smooth YouTube 2.1.16 (less smooth than EVO's 2.0.x "HQ" YouTube for Eclair) and stuttering/losing frames Flash 10.1...10.2 ("inline YouTube), plus stuttering local file playback with more than 480p or so. I have no indication that any HW-conscious FFmpeg codecs was ever used. NEON/Stagefright framework is missing/broken for unknown reason. Only Opera Mobile is capable of using 2D hardware assisted UI scrolling/layout, any other app/Webkit/launcher/wallpaper has no idea they all can use 2D/3D hardware acceleration, as, yes, drivers are broken/falling back to SW too easily. Sure, VOME engine by VisualOn might be just promised to AOSP 2.3.3 but never made it there, however I don't understand why latest Omapzoom commits on SGX driver and a special OMAP3 Adobe Flash Plugin couldn't be used.
Sorry for the long rant, but it seems that 90 % of CM7 dev efforts are concentrated on producing an "average" ROM for 40 or so supported devices. Our Nookcolor has unexpectedly better graphics hardware than all of them -- except Droid X.
Can't you try monitoring the CPU usage on stock and cm7 (top or similar), play a video and see if the CPU is way higher on cm7? I still see stutters on cm myself, and it would be sweet to see the video tweaked. We will also have new stuff to play with soon from B&N's froyo release. I'm guessing we will have a much easier time comparing apples to apples and diagnosing these issues if stock was 2.2 . There are a ton of factors in play (no pun intended), and we can all help by testing. It seemed like the last big jump in cm was prompted by the dude that found the video worked better with his bluetooth headset. That's the kind of thing that would take one person FOREVER to find, but amongst hundreds or thousands of testers becomes apparent. Test, and post results, and try not to be too emotionally attached to the issues. If it makes sense people will notice.... problems only arise when people start guessing, ranting, etc... (xda kids stuff) The nook is awesome and is only getting better
i would disagree - this has more to do with what codecs/containers are being supported rather than hardware acceleration
nook color at 2.1 did play that video but it could not play other formats becuase it did not support the codecs
same with flash - nook color 2.1 played that mp4 file but take same mp4 file and wrap it in a flash container and it cannot play it
nemir said:
If Nook Color' sample video cannot play by CM7 RC4 so hardware decoding is still disabled.
Here is the sample video from official Nook Color intro I extracted from latest firmware (1.10) :
http://www.mediafire.com/file/s5ka0xkdnsf4ajo/welcome_video.mp4
If default video player cannot play so hardware decoder still not enabled for CM7 RC4 and all variants...
Managing to play the video by means of diffrent 3rd party applications ( all video player that decode software and hardware based) make no sense...
Click to expand...
Click to collapse
cyberslug23 said:
Can't you try monitoring the CPU usage on stock and cm7 (top or similar), play a video and see if the CPU is way higher on cm7? I still see stutters on cm myself, and it would be sweet to see the video tweaked. We will also have new stuff to play with soon from B&N's froyo release. I'm guessing we will have a much easier time comparing apples to apples and diagnosing these issues if stock was 2.2 . There are a ton of factors in play (no pun intended), and we can all help by testing. It seemed like the last big jump in cm was prompted by the dude that found the video worked better with his bluetooth headset. That's the kind of thing that would take one person FOREVER to find, but amongst hundreds or thousands of testers becomes apparent. Test, and post results, and try not to be too emotionally attached to the issues. If it makes sense people will notice.... problems only arise when people start guessing, ranting, etc... (xda kids stuff) The nook is awesome and is only getting better
Click to expand...
Click to collapse
Sure, customizations and many other improvements over "standard" CM7 ROM are welcome at any time, it's just an apparent lack of basic GPU/DSP functioning, as nemir stated, what might cause a somewhat critical attitudes. I repeat, the work of dalingrin is awesome, but there are still many questions/problems remain unresolved:
-- the "original" size of an audio "buffer" (if I get it right) was either zero, or small, or adaptive, plus small anyway. Wasn't it an indication that hardware decoding when functional didn't need any?
-- the addition of 32(?) of whatever units to that buffer brought a smoother video playback on YouTube, but can be also an indication that video playback can now easily fall back to software decoding;
-- switching the audio pipeline to push it via BT encoding might be originally either working better, or didn't need to be HW assisted at all. In any case, lipsyncing was missing, just like when the software decoding beyond bandwidth specs was involved
As for how many dudes it take to find a solution out of thousands of NC's inventive users, I'd rather try to find a real TI OMAP3/Zoom2 engineer or two who are NC owners and obviously ROFLing now seeing all these attempts at XDA Devs. In other words, they not only know the solution, it's offered in the open at their gits. It's our kernel level that cannot take it. CM7.x will be formidable when based on 2.6.36...38.
aludal said:
Exactly! I was trying to make sense of this mess from January in my blog fineoils.blogspot.com. With a Nookie Froyo, Nookkolor started to lose everything that was there of hardware decoding AND hardware rendering. I was laghed at by CM7 NC dev dalingrin on my suggestion that lots of HW assistance in video playback is based on SGX, especially the HW overlay. CM7 team is of opinion that mp4/H.264 decoding can be made in DSP (IVA2 in our case) audio buffers for which were that "magic video fix" at the CM7 nightly 17 level. What we have is more or less smooth YouTube 2.1.16 (less smooth than EVO's 2.0.x "HQ" YouTube for Eclair) and stuttering/losing frames Flash 10.1...10.2 ("inline YouTube), plus stuttering local file playback with more than 480p or so. I have no indication that any HW-conscious FFmpeg codecs was ever used. NEON/Stagefright framework is missing/broken for unknown reason. Only Opera Mobile is capable of using 2D hardware assisted UI scrolling/layout, any other app/Webkit/launcher/wallpaper has no idea they all can use 2D/3D hardware acceleration, as, yes, drivers are broken/falling back to SW too easily. Sure, VOME engine by VisualOn might be just promised to AOSP 2.3.3 but never made it there, however I don't understand why latest Omapzoom commits on SGX driver and a special OMAP3 Adobe Flash Plugin couldn't be used.
Sorry for the long rant, but it seems that 90 % of CM7 dev efforts are concentrated on producing an "average" ROM for 40 or so supported devices. Our Nookcolor has unexpectedly better graphics hardware than all of them -- except Droid X.
Click to expand...
Click to collapse
Yeah you are right...
We must accept the lack of full potential power of NC's 2D / 3D GPU for both custom ROMs (CM and other variants) and OFFICAL STOCK ROM...
I have Archos 5 Internet Tablet which has only 256 MB RAM and same CPU ( 800 Mhz ) and Archos 5 Internet Tablet can play 720p .mkv .avi .mp4 .wmv files without any problem...
Moreover, Nook Color has higher RAM and can be overclocked to 1 Ghz ...
Like Archos 101 Nook Color has same GPU ...
I would prefer 800 Mhz ( maybe 1 Ghz overclocked) normal CPU with fully usable GPU ...
Processor • ARM Cortex A8 at 1 GHz with DSP
• Graphic accelerator: 3D OpenGL ES 2.0
Video Playback1 • MPEG-42 HD (up to 720p, 30 [email protected])
• MPEG-42 ([email protected] AVI, up to DVD resolution, 30 [email protected])
• H.264 HD ([email protected] up to 720p, 30 [email protected])
• WMV9/VC1 (AP up to 720p 30 [email protected])
• M-JPEG (Motion JPEG Video) in VGA resolution
With optional plug-in (downloadable on www.archos.com):
• Cinema: MPEG-2 (up to DVD resolution MP/D1, 30 [email protected] Mbps)
With the above codecs, the device can play video files with the following extensions: AVI, MP4, MKV, MOV, WMV, MPG, PS, TS, VOB, FLV, RM, RMVB, ASF, 3GP
Audio Playback1 • MP3 CBR & VBR
• WMA, WMA-Pro 5.1
• WAV (PCM/ADPCM)
• AAC, AAC+ 5.13
• OGG Vorbis
• FLAC
Click to expand...
Click to collapse
http://www.archos.com/products/ta/archos_101it/specs.html?country=us&lang=en
Here is the table of CPU and GPU list
http://en.wikipedia.org/wiki/Texas_Instruments_OMAP
For Nook Color:
OMAP3621 800 MHz ARMv7 ARM Cortex-A8 PowerVR SGX530
Another information about NC
http://www.engadget.com/2010/10/28/nook-color-processor-revealed-arm-cortex-a8-based-ti-omap3621/
So Archos 101 (1024x600) can be ported to NC to utilise ...
CM7 is generic and does not utilise the power of NC's GPU ... CM7 is beneficial for bluetooth and latest android 2.3.3 ... But Arhos firmware has a better full utilised GPU driver...
Frankly, the lack of GPU can NOT be accepted. Focusing on "CPU overclock" does not make sense if you have potential of better GPU driver...
Cool story.
CM7 does have hardware accelerated video.
Also it is the DSP chipset which controls what formats/resolutions are acceptable, not the GPU. Ours is incapable of playing 720p video in hardware acceleration. Not to mention it's a 854x480 hardware accelerator, so 1280x720 video would be wasted anyway.
You guys are loud.
That welcome video won't play because the stock software was able to tell it to play sideways. We can't do thatyet . We CAN hardware accel videos such as this:
http://www.mediafire.com/?d42dmvva9vbigm2
You know, in 16:9 instead of 9:16?
aludal said:
Exactly! I was trying to make sense of this mess from January in my blog fineoils.blogspot.com. With a Nookie Froyo, Nookkolor started to lose everything that was there of hardware decoding AND hardware rendering. I was laghed at by CM7 NC dev dalingrin on my suggestion that lots of HW assistance in video playback is based on SGX, especially the HW overlay. CM7 team is of opinion that mp4/H.264 decoding can be made in DSP (IVA2 in our case) audio buffers for which were that "magic video fix" at the CM7 nightly 17 level. What we have is more or less smooth YouTube 2.1.16 (less smooth than EVO's 2.0.x "HQ" YouTube for Eclair) and stuttering/losing frames Flash 10.1...10.2 ("inline YouTube), plus stuttering local file playback with more than 480p or so. I have no indication that any HW-conscious FFmpeg codecs was ever used. NEON/Stagefright framework is missing/broken for unknown reason. Only Opera Mobile is capable of using 2D hardware assisted UI scrolling/layout, any other app/Webkit/launcher/wallpaper has no idea they all can use 2D/3D hardware acceleration, as, yes, drivers are broken/falling back to SW too easily. Sure, VOME engine by VisualOn might be just promised to AOSP 2.3.3 but never made it there, however I don't understand why latest Omapzoom commits on SGX driver and a special OMAP3 Adobe Flash Plugin couldn't be used.
Sorry for the long rant, but it seems that 90 % of CM7 dev efforts are concentrated on producing an "average" ROM for 40 or so supported devices. Our Nookcolor has unexpectedly better graphics hardware than all of them -- except Droid X.
Click to expand...
Click to collapse
What would it take to get a working patch to enable 2D/3D HW acc? I mean, if the folks working on CM7 won't take the approach you mention.
nemir said:
Here is the table of CPU and GPU list
http://en.wikipedia.org/wiki/Texas_Instruments_OMAP
Click to expand...
Click to collapse
That link tells you right there why we can't play 720p but the Archoses can:
OMAP3621 vs OMAP3630
They have a better DSP processor.
CM7 is generic and does not utilise the power of NC's GPU ... CM7 is beneficial for bluetooth and latest android 2.3.3 ... But Arhos firmware has a better full utilised GPU driver...
Frankly, the lack of GPU can NOT be accepted. Focusing on "CPU overclock" does not make sense if you have potential of better GPU driver...
Click to expand...
Click to collapse
The GPU and the DSP of the Nook Color work fine in CM7. We are able to play games just as well as rooted stock does, and videos I have encoded that maxed the rooted stock (as it had as high of a bit-rate as I could get without frameskipping) still play fine using Vital player on CM7.
As chisleu stated its not perfect, but its certainly working because the Nook Color's CPU can't even come close to playing my files.
Overclocking NC to 1 or 1.1 Ghz should give same performance as Archos's...
By the way, Motorola DEFY has 3610 GPU but it can plays 720p files by means of changing lib files ...
http://forum.xda-developers.com/showthread.php?t=935017
We can try this method to our NC to play 720p movies ...
As I said before latest stock NC has more recent builds in lib folder. CW RC4 uses old lib files...
Anyone can compare and see the difference between latest stock ROM and latest CW R4... CW R4 does not update latest official files from lib (its sub folders and files too)
hey nemir how bout taking us to solution space
nemir said:
Overclocking NC to 1 or 1.1 Ghz should give same performance as Archos's...
By the way, Motorola DEFY has 3610 GPU but it can plays 720p files by means of changing lib files ...
http://forum.xda-developers.com/showthread.php?t=935017
We can try this method to our NC to play 720p movies ...
As I said before latest stock NC has more recent builds in lib folder. CW RC4 uses old lib files...
Anyone can compare and see the difference between latest stock ROM and latest CW R4... CW R4 does not update latest official files from lib (its sub folders and files too)
Click to expand...
Click to collapse
nemir said:
Overclocking NC to 1 or 1.1 Ghz should give same performance as Archos's...
By the way, Motorola DEFY has 3610 GPU but it can plays 720p files by means of changing lib files ...
http://forum.xda-developers.com/showthread.php?t=935017
We can try this method to our NC to play 720p movies ...
As I said before latest stock NC has more recent builds in lib folder. CW RC4 uses old lib files...
Anyone can compare and see the difference between latest stock ROM and latest CW R4... CW R4 does not update latest official files from lib (its sub folders and files too)
Click to expand...
Click to collapse
Maybe you could try to copy over those lib files and see if it works? If it does then maybe cm7 devswill port it.
From 1.1 Nook Color with 1.1 ghz overclock
poofyhairguy said:
That link tells you right there why we can't play 720p but the Archoses can:
OMAP3621 vs OMAP3630
They have a better DSP processor.
Click to expand...
Click to collapse
That link mentions (quite vaguely) where variants of the same silicon (IVA2) are different:
Not highlighted in the list below is that each OMAP 3 SoC has an "Image, Video, Audio" (IVA2) accelerator. These units do not all have the same capabilities. Most devices support 12 megapixel camera images, though some support 5 or 3 megapixels. Some support HD imaging.
Click to expand...
Click to collapse
It is worth mentioning that encoding a (mp4) video is several times harder computational task than decoding it (as in playback). Sure I'm glad and happy for all owners of OMAP3 based smartphones with cameras which can record 720p, or 480p, or 360p or any medium to high bitrate video with their devices -- thanks to DSP HW acceleration of encoding process.
Now, (mp4) video decoding routine is much simpler process, and most important, it doesn't exactly use the same circuitry (the proof is in the possibility of live view while video is recorded on a given OMAP3-based device.) Sure, it doesn't conclusively prove anything, and TI engineers were not exactly helpful in detailing the 3621 IVA2 specs. But in my blog I was writing back in January/February on how smooth Evo's YouTube HQ could play clips searched out by "1080p" "Full HD" "IMAX" and the like keywords. Today, it struggles (loses frames), or refuses to play them.
The adequacy of hardware decoding of at least 480p/720p mp4 on NC was proven back then. Sure, that was Eclair back then, and AOSP 2.3 has NEON framework/hardware Stagefright pipeline broken/unimplemented since -- probably in expectation of Renderscript of Android 3.0 (or 2.4), I don't know
Out of my years (2004 or so) of struggle with mpeg2/mpeg4 decoding of 1080i satellite streams I was of conviction that in HD video rendering the major computational task is a scaling, deinterlacing overlay: once you don't have it in your hardware (shaders of GPU: SGX530 in our case), you have a stuttering, A/V desynced video -- or no video at all. Sure, it was outdated DirectX games back then, but anyway.
------------------
fineoils.blogspot.com
Hey guys, y'know the gta 3 special edition or whatever it's called off the market, has anyone tried it on the hd2? Before I download it.. is it slow, or does it run okay?
Regards,
Sent from my NexusHD2 using xda premium
Hi gta 3 runs good if you follow those settings:
my configuration:
last dorimanx rom high end with zram and swap enabled
kernel dorimanx 6.4
[email protected] 1612 Mhz
gta3 1.3
video settings:
draw distance 31%
resolution 35%
visual effects low
dynamic shadows off
frame limiter off
you have to delete those files from the audio folder to make the game smoother (those are the radio station,slow down the cpu)
HEAD.nfx
CLASS.nfx
KJAH.nfx
RISE.nfx
LIPS.nfx
GAME.nfx
MSX.nfx
FLASH.nfx
CHAT.nfx
I play this game sometimes with no problems,if you have slowdowns try to set a low resolution anddraw distance...Consider the fact that dorimanx rom+ his last kernel is extremely tweaked with cpu @ 1,6Ghz.Before I changed the rom to dorimanx one,I was on thyphoon cyanogenmod and I could get only 5/8 fps
Thanks Axel85 for the info. Now I hope I can enjoy Gta3 on my phone.
Installed it yesterday and it's very very slow, even after removing the radio files.
How do I change the video settings? There's no option ingame within the settings.
Regards
Sent from my HTC HD2 using xda premium
you can find video settings onlysince version 1.3 of the game
Sorry to hijack. The Play Market wont let me install this on my HD2. Isn't there something I need to edit to get the Market to think my device is compatible?
***WARNING!!! THIS MOD IS FOR PEOPLE WHO LOVE HAVING ULTIMATE AUDIO PLAYBACK SYSTEM ONLY (LOW LATENCY, LINEAR BIT-STREAM, AUDIO PERFORMANCE AT ITS BEST). IT'S NOT AIMED FOR LONG BATTERY LIFE OR FAST/SMOOTH PHONE AND MAY NOT WORK RIGHT ON YOUR PHONE. I'M NOT PROMISING ANYTHING ABOUT SOUND QUALITY IMPROVEMENTS AND DON'T WANT TO DEBATE ABOUT IT***
After spending months in github looking in Voodoo Sound code and gotta admit I have no idea how it could get any better. Finally, i found something interesting to improve sonic quality that can make us audiophiles smile for higher fidelity. Time to say goodbye to Android life with just Voodoo + cool music player alone.
Six months ago...after ICS firstly released, Google patched audiostream buffer in Nexus S' audio library increasing buffer size and latency after fixing latency delay in 4.0.2 and so on. For normal people's perspectives, it should be a good move as we get stable audio stream, more battery friendly and no more delay issue.
However, some purist computer audiophiles may not agree and have strong motto about 'low latency'. Some Windows players like JPLAY and XXHighEnd went far enough to feed single byte buffer feeding audio card. Not that lower is always better as I prefer minimum hardware buffer size over something extraordinary.
Back to the topic, so I messed around with Nexus S' audio library wondering why no one ever tried that before. As this is first attempt, I'll try to make things as extreme as possible according to what it's capable off.
As there're a lot of misconceptions about latency and jitter stuff so I'm not gonna explain how any those stuff will do about audio performance. Better let your ears decide it as it wouldn't hurt to try. Let's see what this brings to you now.
Features:
Features come in build packages below. Make sure to read all of them as you need to carefully pick out the best for your need. I added my own platform optimizations script in version 2.0 and improved audio library according to new platform performance. I also added Galaxy S (I9000) device support and will try to make more devices like Galaxy Tab and Galaxy Nexus in future. Also keep in mind that there's no best sounding build without sacrificing system's stability.
Builds:
platform: This is innovation of the year for all Android.....no for all Linux-based audio systems and technically work on any Android devices too. Specialized platform for lowest possible I/O latency and CPU utilization having audio thread optimized to its finest having real-time I/O with priority at highest level, Voodoo Sound and Color configuration for purist un-altered sound, kernel resource scheduling optimized to highend DAW level, CPU+I/O+kernel optimized for low latency, audio effects being disabled completely and plus_music patched audio library. It'll have to remove all existing scripts in init.d as most of them can screw this ones up. It'll give you best environment to run even more extreme patches in 2.0 at more battery-friendly setup.
plus_general: Designed for battery-friendly build at 10ms latency playback. You can use this on any ROM, kernels, tweaks you like. General build uses original ICS frame buffer size before modifications and trimmed down buffer size to be the same size as ICS frame for direct frame buffer transfer. I recommend getting plus_general if you don't want to get sloppy second like other builds.
plus_music: Also designed for battery-friendly like general but use even smaller frame buffer size to only 128 at 8 frames for 5ms latency playback at stock environment. It's designed for only music playback alone so you may get some playback problems aside from music playback. To make this stable, I increased number of frames in buffer pool from 4 to 8 according to ALSA's ideal specifications. It works fine on most governors but 100MHz or deep idle may cause some problems. This still works fine on most apps except you try having music played in background on intensive apps.
plus_google: This is alternative design for ideal 5ms latency playback based on plus_general design. Frame buffer size being reduce from original ICS frame buffer size (448) to 256 at 4 frames. The reason I picked ALSA's specifications for music is most ALSA drivers configured for low-latency use that but doesn't mean it's generally better than this ones. I personally prefer lower frames rather than lower frame size at same pool size.
extreme_direct: Designed for those who want to go extreme with lowest possible hw/sw buffer design having buffer pool exactly the same size as output buffer. It's plus_music having number of frames in buffer pool trimmed down from 8 to only 2. Yes.....2 for smallest possible frame buffer pool. You need to install optimized platform environment to keep this stable or run it on high performance setup.
extreme_linear: Designed for those who want to go extreme with smallest possible frame buffer size design. It has only 32 frame buffer size (1/32 of normal buffer size) and have 8 frames in buffer pool. I doubt you can run this at stable level without optimized platform. It has highest battery consumption of all but doesn't mean it works the best. Direct design provides fuller dynamics with more depth while this ones gives you richer ambient with smooth sound.
extreme_insane: Designed for those who want to go extreme with everything smallest possible. It has 32 frame buffer size (1/32 of normal buffer size) and only 2 frames in buffer pool making buffer pool 1/4 of other extreme patches. I said insane because it's beyond what this phone is capable of technically. Even in specialized platform on performance govenor may not music played till the end without single spike. You can only try making it stable with steve.garon's filesync off kernel after patching specialized platform. The reason I didn't include his kernel in because it causes occasional reboots and currupt data partition due to disabled filesync running insane task.
Downloads
nexus_s_fidelity_platform
nexus_s_fidelity_plus_general
nexus_s_fidelity_plus_music
nexus_s_fidelity_plus_google
nexus_s_fidelity_extreme_direct
nexus_s_fidelity_extreme_linear
nexus_s_fidelity_extreme_insane
nexus_s_fidelity_restore
Changelog
[03/05/12] Version 2.0
-Added audio thread priority optimizations to highest level
-Added audio I/O priority optimizations to highest real-time level
-Added CPU optimizations for low latency playback
-Added Galaxy S (I9000) device support
-Added kernel resource scheduling optimizations
-Added I/O optimizations for low latency playback
-Changed Voodoo Sound headphone gain to 0db (2db has too high hiss on low impedance phone)
-Fixed clear old scripts in init.d that didn't work last time
-Removed libaudioeffect_jni.so as it increase more load and latency
-Removed DSPManager as it can't be disabled and keep showing error during music playback
-Removed wildestpixel tweaks
-Tweaked audio library improvements
|-plus_music uses library from version 1.0 for Alsa's ideal specifications
|-plus_google added as alternative ideal 5ms design based on Google's Android code
|-extreme_direct now has 1/2 frame buffer size comparing to 1.1 version
|-extreme_linear now has 1/8 frames comparing to 1.1 version
|-extreme_insane added with everything smallest from other extreme patches
|-restore now also remove installed optimizations and restore libaudioeffect_jni.so
[28/04/12] Version 1.1
-Added plus_general for all-around use at 10ms latency playback
-Added plus_music for music focused use at 5ms latency playback
-Added extreme_direct and extreme_linear for non-compromise builds
-Added restore for people who want to use current AOSP build
[27/04/12] Version 1.0
-Initial release with kernel/tweaks for 8x1/8 frame buffer optimized for 5ms latency playback
If you experiences any playback problems, try changing minimum frequency or use suited governors, I/O, CPU settings in NSTools. I'm quite satisfied with battery-life in version 2.0 and never have issue after finalizing version 2.0.
Sound improvement? Do you have a git or something for us to explore?
Sent from my Nexus S using Tapatalk 2
It should give cleaner sound and richer harmonics without oversampling and frequency locked loop as you get 4-8 times less latency jitter. I asked my sister to try it and she said it sounded more relaxed and easier to listen.
IMO, oversampling is bad as it caused aliasing and distortion of band. Frequency locked loop is more like trade-off as you'll get clearer sound at sacrifice of good transient response.
Windows X said:
It should give cleaner sound and richer harmonics without oversampling and frequency locked loop as you get 4-8 times less latency jitter. I asked my sister to try it and she said it sounded more relaxed and easier to listen.
IMO, oversampling is bad as it caused aliasing and distortion of band. Frequency locked loop is more like trade-off as you'll get clearer sound at sacrifice of good transient response.
Click to expand...
Click to collapse
If i wanna compile, do you have sources to this?
Sent from my Nexus S using Tapatalk 2
This should give you a clue
https://github.com/AOKP/device_samsung_crespo/commit/a1fee1161f403d8fba66a7d76d246a1c785a6d3c
FYI: This is libaudio at its extremist. It's supposed to work alright with 100% performance mode without battery saving trick. Thanks to lazy/sio combination brought by wildestpixel that saved my day.
Whoa!
Nice stuff! Waiting for source code or a patch to be released to take a look on it
Great work
RcrdBrt said:
Whoa!
Nice stuff! Waiting for source code or a patch to be released to take a look on it
Great work
Click to expand...
Click to collapse
Thank you. To be honest, this is my first coding in Linux and I didn't know it took me 8hrs to prepare env/source. All for changing few bytes of one file lol. Above post should give you some clues and I'm still in experimenting this one so let me test/check more to make sure its stable code for most ROMs/kernels. I may probably try few more on other phones like Galaxy S and Desire HD (does it have ICS source?)
Omg! My ears blewed lol. Played some Skrillex and Deadmau5 songs. It was absolutely awesome. It was better than voodoo. Oh my! :')
Glad voodoo is still here.
Sent from my Nexus S using Tapatalk 2
DaXmax said:
Omg! My ears blewed lol. Played some Skrillex and Deadmau5 songs. It was absolutely awesome. It was better than voodoo. Oh my! :')
Glad voodoo is still here.
Sent from my Nexus S using Tapatalk 2
Click to expand...
Click to collapse
Glad to hear that. lazy isn't the best governor for sound quality wise though. Some powerful governors give fuller and more coherent sound. Let me know if you find something more to do with.
There is no such thing as 'latency jitter', they are two separate things . Latency is the delay caused by digital sound processing as the CPU cycles take time. A buffer is used to keep this delay constant.
Sampling jitter is caused by inconsistent clocks either at the input A/D stage, or the output D/A stage. Since we can't do anything about either of these stages without modifying the hardware, there isn't much we can do to improve the sound quality, apart from use better headphones and get the EQ right.
A smaller buffer is not going to affect sound quality, it will just mean the sound hits your ears a few milliseconds earlier.
Windows X said:
Glad to hear that. lazy isn't the best governor for sound quality wise though. Some powerful governors give fuller and more coherent sound. Let me know if you find something more to do with.
Click to expand...
Click to collapse
Err, what governors has something to do with sound?
Sent from my Nexus S using Tapatalk 2
bedalus said:
There is no such thing as 'latency jitter', they are two separate things . Latency is the delay caused by digital sound processing as the CPU cycles take time. A buffer is used to keep this delay constant.
Sampling jitter is caused by inconsistent clocks either at the input A/D stage, or the output D/A stage. Since we can't do anything about either of these stages without modifying the hardware, there isn't much we can do to improve the sound quality, apart from use better headphones and get the EQ right.
A smaller buffer is not going to affect sound quality, it will just mean the sound hits your ears a few milliseconds earlier.
Click to expand...
Click to collapse
Refined setups will readily reveal sound quality changes with changing latency. Its best to use lowest stable latency. A good programmer would argue that latency is a non-issue for playback. "Just set it to highest level as we get less context switches which is more efficient...". This is not correct for best sound quality.
At a software, firmware and hardware level, PCI prefers small payloads.
"Latency jitter" as in variations in latency was thought to be the cause for why latency affects sound quality. This idea has been scrapped.
From a Jitter viewpoint, when a soundcard's buffer is populated (whilst the other buffer is converted to SPDIF or whatever), there's a burst of electrical activity. The idea is to keep this burst as short as possible thereby reducing interference to the soundcard's XO, i.e. reduce Jpp. We achieve this by setting latency to the lowest possible level. Of course, using such a low latency would mean more frequent buffer loads. This is the ASIO frequency (or ASIO Hz). At 32 samples latency for 96k output, ASIO Hz is 3kHz. This is now periodic in nature and is digitally induced. We now have Periodic Jitter - the worst kind which exists for all digital playback systems. ASIO gives us control over this.
Higher ASIO Hz is preferred and you definitely want to avoid anything less than 1kHz. Why? A soundcard's PLL or PLLs down the chain will be able to further reduce this periodic jitter as the frequency is likely to be above the PLL's cut-off.
From: http://www.cicsmemoryplayer.com/index.php?n=CPlay.ASIOLatency
I wouldn't say cics saying no means no though. But I found his paper from music server research looks promising to give it a shot myself and I found it was true from my own tests also.
DaXmax said:
Err, what governors has something to do with sound?
Sent from my Nexus S using Tapatalk 2
Click to expand...
Click to collapse
http://www.cicsmemoryplayer.com
From cics' research, it seems many things we believe it won't affect audio/video performance are misconceptions. Well, for mobile it didn't cause significant result like PC though so you can overlook it but it's worth a try to change stuff with NSTools and such. I used to disagree stuff like his experiments just like most people. Then I took music in the ears.
Is there way to apply this mod by just editing smali?
Sent from my Nexus S using XDA
ioplkj13 said:
Is there way to apply this mod by just editing smali?
Sent from my Nexus S using XDA
Click to expand...
Click to collapse
No because this isn't java compiled from framework. It's pure C++ code modification not Java to native code.
Windows X said:
As there're a lot of misconceptions about latency and jitter stuff so I'm not gonna explain how those stuff will improve audio performance. Better let your ears decide it as it wouldn't hurt to try. Let's see what this brings to you now.
Click to expand...
Click to collapse
Looks promising.....if it actually works. I'll try it out later by flashing it over a Voodoo-less kernel like Franco's r4. Will let you know how it goes. Thanks for your work. Cheers!
apatal said:
Looks promising.....if it actually works. I'll try it out later by flashing it over a Voodoo-less kernel like Franco's r4. Will let you know how it goes. Thanks for your work. Cheers!
Click to expand...
Click to collapse
This works better with voodoo and I have Air Kernel 4.0 (Voodoo enabled) included. Flashing another kernel or additional tweaks may not work as expected. However, it still works better even without voodoo. I'm just little worried about performance/stability optimizations on other kernels/tweaks.
Windows X said:
This works better with voodoo and I have Air Kernel 4.0 (Voodoo enabled) included. Flashing another kernel or additional tweaks may not work as expected. However, it still works better even without voodoo. I'm just little worried about performance/stability optimizations on other kernels/tweaks.
Click to expand...
Click to collapse
But I thought this already have the Voodoo sound module included? Doesn't that mean it should work fine for non-Voodoo kernels?
I do understand your point though, about not being able to guarantee optimum performance once we use the mod differently than was what it was originally intended for.
Cheers!
apatal said:
But I thought this already have the Voodoo sound module included? Doesn't that mean it should work fine for non-Voodoo kernels?
I do understand your point though, about not being able to guarantee optimum performance once we use the mod differently than was what it was originally intended for.
Cheers!
Click to expand...
Click to collapse
By the mean by that is, kernel is built with the mod. Its not a patch...
Sent from my Nexus S using Tapatalk 2
FYI, I'm no sound expert or have any experience in sound processing at all.
From what I read in the first post, there is no change to the kernel. He just modified the audio library (/system/lib/hw/audio.primary.herring.so) to have less buffer size and latency.
I tend to believe that governor choice can affect the sound processing e.g. using different sampling rate to switch between frequencies.... but if you use Performance governor then this factor could be eliminated, I guess
BTW, I flashed the zip and tried listening to some FLAC files. Couldn't tell that I noticed any improvement. Only the sound is louder than when listening with default T132 setup -- but that could be just because headphone_amplifier_level in Voodoo was changed.
Anyway, thanks for sharing your experiment... This may lead to something very powerful in the future
I've had the galaxy note for a while now, tried many roms and so on. But I just cannot get the speed out of my note like my sister's stock GB S II. Her phone is SO fast and snappy it's mindblowing. My note feels super slugish compared to her phone and she hasn't even done any mods! What can I do to speed my phone up? I've tried touchwiz and non touchwiz roms they just all seem to lag. I have never tried any gingerbread roms though. Is there a CM7 rom for the note?
If you refer sluggish as in the screen transitions, that is probably because the GPU has to push out a whole lot more pixels (640000 to be precise), both phones use the same GPU, this also applies to desktop computers, laptops and whatever uses a graphics card. for example you can play lets say Diablo 3 at FULL settings in 720P, now if you change the resolution to 1080P and keep FULL settings you will see the game stuttering and frame skipping and what not.
My advise would be try changing the screen density, but I doubt that'll help since the Mali GPU still has to push out more pixels than on the GS2
BrokenPixel said:
If you refer sluggish as in the screen transitions, that is probably because the GPU has to push out a whole lot more pixels (640000 to be precise), both phones use the same GPU, this also applies to desktop computers, laptops and whatever uses a graphics card. for example you can play lets say Diablo 3 at FULL settings in 720P, now if you change the resolution to 1080P and keep FULL settings you will see the game stuttering and frame skipping and what not.
My advise would be try changing the screen density, but I doubt that'll help since the Mali GPU still has to push out more pixels than on the GS2
Click to expand...
Click to collapse
Yea I figured it was a GPU issue. Anyway to overclock the GPU?
Also, anyway to switch to 24 bit or 16bit colors?
I have dedicated my S5 to use as a midi synth player, together with a midi keyboard connected to the phone via an OTG adapter, outputting either through the built in audio out or perhaps a separate sound interface.
I have a newer phone (Xiaomi Redmi Note 7) but I'm going to try with the S5 as well, as a I read that of all the Android manufacturers Samsung has the best rep with audio latency.
I've also heard that a big leap was made with Android 9 and 10 on latency, some recent ROMs for the S5 based on android 9 and 10 are rather basic in terms of the features they support. So, I'm looking for recommendations for stock or custom ROM which support low audio latency use.
Thanks for your suggestions.
Hi,
I haven't tried using my s5 for midi, but in general, I would think the latency would depend as much on your kernel, CPU governor & especially I/O scheduler as the firmware.
Obviously, if you have a super-bloated rom there would be more background tasks by default to clog up the processor.
I would go for one of the debloated ones that support custom kernels and have a look around for the right kernel & I/O scheduler.
Another option would be to see if turning on the developer option to kill background processes affects the latency when in the midi app.
Looking forward to hear your results.
C:
Cheers
Highly recommend using the Tuned kernel if you're not using it. It works on various ROMs like LOS:
https://forum.xda-developers.com/ga...d-los-kernel-s5-performance-battery-t3893954/
You can configure the kernel with the Boeffla app. Just for fun I increased the max CPU speed to ~2.9 GHz and enabled the Tuned performance governor. The phone became hilariously responsive. I tried it out for a few days but it didn't really benefit me. It might benefit you though! Performance settings make it much harder for the phone to idle. In fact if you've ever had music stuttering it's from the phone playing a music codec the hardware can't accelerate while the CPU cores are in an idle state or turned off.
Having some success with this. By setting the CPU min frequency to be maxed out continuously at 2.457Ghz using and setting the Android task scheduler profile to 'deadline' using Kernel Adiutor, and assigning maximum priority to the task in question using 3C Toolbox, I was able to get one app (microphone pro) to go from 48000Hz + 480 frames per buffer, to 48000Hz + 240 frames per buffer. Not quite stable yet, but shows that tweaks are having an effect. Feels like a total latency (from key press to ear) of around 40 ms.
In the end the trouble I am having is finding applications that have latency configuration options with enough granularity to test out whether any system tweaks are making a useful difference. For example Caustic (synth app for android) only has five possible latency settings, the lowest being called 'lowest' (funnily enough), which was actually already stable before I got the tweaks going. Not like audio apps in Windows and Linux where you can choose different latency settings (sample rate, buffer size, etc.) with high granularity. Perhaps there are some apps out there that have this though, although I know Android does have a minimum system latency (20 ms I think I read) which apps can't go beyond currently. 20 ms whilst playing something on keyboard is a bit distracting for some, though probably would be possible to get used to it (latency when playing keyboard becomes unnoticable to me around <7ms personally, and I could probably learn to ignore greater values).
CPU tweaking apps tried so far actually only allow setting the minimum frequency of the CPU, so you can have it maxed out all the time, which is making a difference, but the ideal would be being able to experiment with proper overclocking. OS is LineageOS 16 (comes with it's own custom kernel). Modem and bootloader not sure but they are either those that come with LineageOS or the Marshmallow latest ones installed prior to LineageOS install (not sure if LineageOS installs any or leaves the modem and bootloader previously installed).
Boatshow said:
Highly recommend using the Tuned kernel if you're not using it. It works on various ROMs like LOS:
https://forum.xda-developers.com/ga...d-los-kernel-s5-performance-battery-t3893954/
Click to expand...
Click to collapse
System wouldn't boot when I tried that Kernel. Not sure if I did something wrong. I went back to the LineageOS built in kernel and unfortunately it doesn't support Boeffla.