Related
I've problem watching TV :
Video starts, works , stops, start again .. many times and at the end i get a b lack screen
logcat just before last stop :
E/QCvdec ( 151): Flush VDL_stats_q: stats_ptr 0xcfb50
E/QCOmxcore( 151): OMXCORE API : Free Handle ccc6c
E/QCOmxcore( 151): Unloading the dynamic library for OMX.qcom.video.decoder.avc
E/MediaPlayer( 535): internal/external state mismatch corrected
Note : i get this problem with all 2.1 ROM i tried , but it works with Modaco 3.2
Tkx for help
A+
Jpq
General Comments
I've created this thread to centralize video discussions, tips, issues, etc.
Please limit this only to those running CM7. Something that works or doesn't work in rooted stock or Froyo may have no correlation to CM7 at present. CM7 is using different codecs, different DSP kernel driver, different media backend, and different userspace ALSA.
To start things off I have attached a handbrake profile that has worked well for me.
I will update this post as more specifics are found.
A few things to consider: ALSA
Our ALSA implementation is picky about the buffer size. Other devices that use ALSA in the same fashion have had to reduce their buffer as well. This may be due to a limitation of what can fit in the DMA buffer on the McBSP. Because the ALSA buffer scales with the audio sample rate, I recommend using 44.1K instead of 48K when transcoding videos. This is contrary to every handbrake profile I've seen folks post on XDA for the nook.
CPU Governor
Some people have had better luck with the Conservative CPU governor rather than Ondemand or Interactive.
Bitrate
I have found it best to limit the bitrate to something under 1000kbps.
Resolution
The resolution should always be limited to 854x480. This is the maximum limit for the open source codecs. We do not have a license for 720P codecs yet. Perhaps B&N will get a license for their Froyo update.
dalingrin said:
I recommend using 44.1K instead of 48K when transcoding videos.
Click to expand...
Click to collapse
I concur....I started doing this last night, coupled with a DRC of "3" and sound is better and louder.
360Razir said:
I concur....I started doing this last night, coupled with a DRC of "3" and sound is better and louder.
Click to expand...
Click to collapse
I agree about DRC. I just updated my profile with dynamic range compression of 2.
Your preset causes an unhandled exemption for me when I load or use it in handbrake. If I try to play what it outputs, it doesn't play in the stock player.
I have to turn off Weighted P-Frames to get the nook to play in hardware (stock player.)
EDIT: Attached my preset. It has all the typical preset stuff, plus 44.1/128 audio like dal recommended, and it doesn't throw a fit when I import or select it in handbrake.
chisleu said:
Your preset causes an unhandled exemption for me when I load or use it in handbrake. If I try to play what it outputs, it doesn't play in the stock player.
I have to turn off Weighted P-Frames to get the nook to play in hardware (stock player.)
Click to expand...
Click to collapse
Weighted P-frames are off in my profile.
What version of HandBrake are you using? I have rev3736.
The other thing I have to test is my Droid X. Most of the Handbrake (HB) encoded movies I have were done for my DX last year. Like the NC, I set the movies to 854x480 for my DX and so that makes it nice to be able to test between the two devices.
My DX is now running (leaked) Gingerbread and playing the same videos between the DX and the NC, the DX is so incredibly smooth. No lag. No crackling. No slow-downs. No audio popping. Just buttery smooth. Now, I understand the screen is smaller, but again, same video resolution of the video. Not sure how the "guts" of the DX are vs. that of the NC, though?
However, what I can say, is that back in January when I first got my NC and went with AutoNooter, I was able to take my existing HB-encoded movies that I had lying around for my DX and play them perfectly on rooted stock. Since CM7, out of the 25 or so movies I have for the DX, only 7 of them play on the NC (using Act 1). The NC is picky, indeed.
The quest continues....
dalingrin said:
Weighted P-frames are off in my profile.
What version of HandBrake are you using? I have rev3736.
Click to expand...
Click to collapse
Yours and the other guy's won't load without throwing an exemption which is where my confusion came from in the other thread.
Mine says 3728... it is 0.9.5 and says 2011010300 and says it is the latest when I try to update... going to redownload...
You are on the linux version aren't you?
Here are the videos with their specs that do currently work with Act 1 on my NC:
NOTE: most of my videos that work are in .m4v format. I had removed that setting in HB, but when I did, the video didn't play. I am sure it was probably something else getting in the way, but .m4v just seems solid for me right now, so sticking with that. To each his own.
As you can see from the attachment, the size, bitrate, dimensions, and frame rate are all over the map. Each plays well in Act 1 with Zoom set to "Aspect Full".
I will post my exact HB settings when I have something I have settled on and I am taking the suggestions from this thread, so thanks for that.
chisleu said:
... it is 0.9.5 and says 2011010300 and says it is the latest when I try to update...
Click to expand...
Click to collapse
Same here....Win7/32-bit
I am attaching my settings for HB that work well for me with regards to full-length movies. Has excellent audio/video sync, with no lag.
Highlights include:
[ Original Presets were taken from Regular > High Profile and then just tweaked accordingly ]
● Picture: Anamorphic Loose
● Video Filters: Off
● Video: H.264, Same as source, 2-Pass Encoding (Turbo 1st), Avg Bitrate (kbps) 2000
● Audio: Source (default), AAC (faac), Stereo, 44.1, 160, DRC = 3.8
● Advanced: B-frames = 0, CABAC & 8x8 & Weighted P-Frames = unchecked
Again, I am using Act 1 with "Zoom" set to Aspect Full.
Please let me know what you think if you dare to try.
EDIT: Video source is a regular DVD, widescreen, ripped into Handbrake directly
The dalingrin presets work for me with the Handbrake svn3907 on Ubuntu. My resulting conversion of my Letterman test video plays fine.
@dalingrin:
Any ideas as to why disabling WiFi would stop the madness of the lagging/stuttering in the video? Was it something my system was doing in the background or one of my widgets fetching data?
Is this just the case for my NC or can this be replicated? Any tests I can run for you to see if it is something you can help with? Thoughts? Thanks.
~ Razir
360Razir said:
Any ideas as to why disabling WiFi would stop the madness of the lagging/stuttering in the video? Was it something my system was doing in the background or one of my widgets fetching data?
Click to expand...
Click to collapse
That's always been my guess. Things never quite settle as long as they have access to the network.
Is this just the case for my NC or can this be replicated? Any tests I can run for you to see if it is something you can help with? Thoughts? Thanks.
Click to expand...
Click to collapse
Nope. Same here. And, it's not just video... it makes Pandora rather unpleasant. Luckily, my primary use case for video is on a plane where network access is unlikely or expensive.
Have you tried using the Conservative governor? It helps my situation.
Some rules for this thread to consider
Let me extend this discussion and propose a few rules for this thread:
1. The source video should be made clear. If you start with poorly encoded video you're obviously going to output something similarly crappy. Provide a link to the file, or upload it yourself and provide a download link. It should be legal, i.e. if you ripped it from your blu-ray, or if you torrented it from somebody else who ripped it from a blu-ray, then it doesn't belong on this thread. My source video will be a 1080p trailer from The Eagle, downloaded (legally) from here: http://www.hd-trailers.net/movie/the-eagle/
2. The encoder and settings should be made clear. I never used Handbrake before, but this morning I downloaded Handbrake 0.9.5 and installed it on my Win7 64-bit desktop. I'm using the preset for "iPhone & iPod Touch". This defaults to H.264 encoding and m4v container. I then adjusted either resolution or average video bit rate but everything else I also left at default, since I mostly don't know what they mean anyway.
3. The player should be made clear. I used Titanium Backup to uninstall Music because of a prior FC issue, then sideloaded music.apk that I pulled from cm_encore_full-37.zip, thus I'm back in business with the stock Video player and no longer using Act 1.
4. Optional: upload your transcoded file and provide a link to it. I've made 2 clips of the eagle trailer which can be downloaded here:
Eagle trailer - 854x352 - 800K: http://dl.dropbox.com/u/22573583/Eagle_854x352_800K.m4v
Eagle trailer - 576x240 - 800K: http://dl.dropbox.com/u/22573583/Eagle_576x240_800K.m4v
The short of it is that both files play flawlessly on my NC running CM7 n37 with dalingrin OC kernel 040411, overclocked 300/1100 interactive. Here are some notable observations:
- The 480p-ish 854x352 resolution limited by our open-source license plays flawlessly for me up to a video bit rate of 1300K, at which point one or two random split-second audio stutters occur through the clip. You can download my 800K encoded video at this resolution. I've gone up to 3000K at 854x352 resolution with still very smooth playback. I've also been able to play an 800K clip resized to 1024x600, the native NC resolution, flawlessly.
- The 576x240 resolution for me is the sweet spot on the Nook. Text resolution is inferior to 854x352, but the playback is perfect and file size is more accommodating. Stutter-free at 800K (download my Handbrake encoded file if you want), and actually stutter free all the way up to 3000K. What's so incredible is that the high-speed scrub (put finger in middle of screen and slide right or left) at this resolution is buttery-smooth.
- Adjusting the CPU speed up or down and moving around governor setting didn't do anything good or back for video playback. Video playback was just as good at 800MHz as 1100MHz CPU speed.
I'm not an expert on video codecs and encoding, by any means, but I've been around HD-DSLR video and non-linear editing ever since Vince Laforet busted out with Reverie nearly 3 years ago.
I'll stand by my opinion, expressed previously on the kernel thread, that CM7 and dalingrin OC kernel in its current iteration (nightly 37 and 040411) absolutely rocks for properly encoded video.
360Razir said:
@dalingrin:
Any ideas as to why disabling WiFi would stop the madness of the lagging/stuttering in the video? Was it something my system was doing in the background or one of my widgets fetching data?
Is this just the case for my NC or can this be replicated? Any tests I can run for you to see if it is something you can help with? Thoughts? Thanks.
~ Razir
Click to expand...
Click to collapse
it doesnt stop it for me. no wifi. no bt. still stutters randomly on good files.
sinanju said:
Have you tried using the Conservative governor? It helps my situation.
Click to expand...
Click to collapse
Yes, I saw your post about that from the OC Kernel thread and so that is what I tried last night. It seemed to work at first, but then this morning it was also choppy using that governor. So, being on Interactive with WiFi off works.
My Droid X has many more widgets running and network access (both 3G and WiFi) and there is no hiccups or slowdowns whatsoever playing the same video. I know not apples-to-apples, but the quest is to get my NC to that kind of stability.
MedLine said:
Eagle trailer - 854x352 - 800K
Eagle trailer - 576x240 - 800K
The short of it is that both files play flawlessly on my NC running CM7 n37 with dalingrin OC kernel 040411, overclocked 300/1100 interactive.
Click to expand...
Click to collapse
Both of your videos are still choppy for me with WiFi enabled....meaning, something is fetching data in the background (Pulse, Palmary Weather, Plume, Engadget, or Google News, or even email polling) is messing with my video playback. Just wish the video was "shielded" from such things.
When WiFi disabled, all is good with your videos.
Which app you guys using to play videos? I'm using Rockplayer right now and getting audio sync issue. I had better luck with Mobo Player.
OK:
Using Sony's HD Experiment because it is short and high action.
http://www.demo-world.eu/trailers/redirect-high-definition.php?file=hd_other_sony_hd_experiment.rar
Encoding using the iphone and ipod touch preset.
I set 576x240 resolution and I can play completely smoothly with wifi on. File size is 4.44megs w/ RF: 25 (iirc)
I set 854x480 resolution and RF 30 it locks on whatever frame you start playing (black screen, etc.) Won't play. I set 854x480 and 800kbps avg kbps and it is also black screen. If I hit home and then go back and let it go, the video will change, but it doesn't seem like it will catch up. Definately broken.
I downloaded that 1080p trailer you linked.
start handbrake, load 1080p trailer, select "iphone and ipod touch" preset, select 854 width (auto height 368), changed to average kbps and set 800. My file size isn't exactly yours, but is very very close.
854x368 plays very well and looks fantastic, but it does have those pops/skips.
Disable wifi:
still get rare/random skips with my 854 file.
still get rare/random skips with your 854 file.
I turned "Disable Fullscreen" off on a hunch it was play a role in this:
My 854 file still skips from time to time.
My 576 file still skips from time to time, although more rarely. only once in 2 plays.
Your 854 file still skips from time to time.
Your 576 file still skips from time to time, maybe more rarely? Hard to quantify.
I encoded the eagle trailer with my 854 width, RF 25 "high quality" preset.
It is smaller than 800kbps (13.1M vs 18M)
It skips too.
tablo said:
Which app you guys using to play videos? I'm using Rockplayer right now and getting audio sync issue. I had better luck with Mobo Player.
Click to expand...
Click to collapse
We are mostly using the stock player because it forces hardware accel.
I prefer VitalPlayer to all. If you are having sync issues it is probably playing in software mode. I should say, VitalPlayer has never given me any sync issues at all while playing in software. Wish I had discovered that before DSP was working. haha
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
Alright. So I'm sure that at least some of you people out there can't watch Netflix twitch.tv etc. And what makes me unsure is that there hasn't been a thread on this so here we go.
I've been trying to fix video streaming on cm10, miui, aokp etc. But i haven't found anything that works as of yet. In hoping that someone here knows how to fix this or can collaborate with me in finding a way to fix this!
Thanks for reading, and any help would be greatly appreciated
Sparky
Sent from my HTC Desire C using xda app-developers app
It could be down to something like gralloc? That's what renders onscreen, isn't the Desire C source code hacked to make this even remotely work? Have you looked at a logcat when it tries to play bro?
if you can attach one to your next post, so I can take a look, as I'm away from my Desire C as of now.
Yah, I'll give logcat soon, you will have to figure it out though as I don't really know what to look for in a logcat...
Sent from my GT-P3100 using xda app-developers app
Was a fix found for video streaming?
It needs to be fixed. Streams not watchable on our phones.
It will be great if you guys fix the bug.
I know this is older but I'd also like to see it fixed. It seems the decoder is incompatible.
Code:
I/ESQueue ( 119): found AAC codec config (48000 Hz, 2 channels)
I/avc_utils( 119): found AVC codec config (1280 x 720, Baseline-profile level 3.1)
E/OMXNodeInstance( 119): OMX_GetExtensionIndex failed
E/ACodec ( 119): [OMX.qcom.video.decoder.avc] configureCodec returning error -1010
E/NuPlayer( 119): Received error from video decoder, aborting playback.
E/NuPlayer( 119): video track encountered an error (-2147483648)
E/MediaPlayer(22126): error (1, -2147483648)
E/MediaPlayer(22126): Error (1,-2147483648)
D/Twitch (22126): Error during playback: 1, -2147483648
I believe that's an issue with the twitch app.
Edit: Another logcat error which seems related:
Code:
W/WVMExtractor( 119): Failed to open libwvm.so