This is the bug/patch tracker for Rockbox. Click here for more information.
Quick links: Bugs · Patches · Rockbox frontpage
FS#6908 - Sansa: avoid audio glitches, vinyl like effect
Attached to Project:
Rockbox
Opened by Toni (ahellmann) - Sunday, 25 March 2007, 18:44 GMT+2
Last edited by Michael Sevakis (MikeS) - Wednesday, 30 May 2007, 16:49 GMT+2
Opened by Toni (ahellmann) - Sunday, 25 March 2007, 18:44 GMT+2
Last edited by Michael Sevakis (MikeS) - Wednesday, 30 May 2007, 16:49 GMT+2
|
DetailsWorkaround to avoid audio glitches (very short audio dropouts) in conjunction with heavy screen update tasks like:
- wps with peakmeter - fast scrolling lists This patch also allows flawless frequency scaling (if enabled in the binary). It maybe also avoid the bug reported in http://www.rockbox.org/tracker/task/6900. Please test. 
audio-anti-vinyl.patch
(1.6 KiB)
lcd-e200.c | 18 ++++++------------ 1 file changed, 6 insertions(+), 12 deletions(-) |
This task depends upon
Closed by Michael Sevakis (MikeS)
Wednesday, 30 May 2007, 16:49 GMT+2
Reason for closing: Fixed
Additional comments about closing: Ah forget it...I actually looked at the patches and they don't actually add any code for that or enable it. :P No complaints about the change...closed.
Wednesday, 30 May 2007, 16:49 GMT+2
Reason for closing: Fixed
Additional comments about closing: Ah forget it...I actually looked at the patches and they don't actually add any code for that or enable it. :P No complaints about the change...closed.
FS#6900) so far.edit: ignore that... you must do a full recompile after enabling cpu frequency :p
works well...
The audio IIS FIFO contains 16 audio samples. After processing 6? samples
the low watermark has been reached and a fiq is initiated to get more data.
This fiq may stall if a cache flush is in work. So the FIFO can run completely empty.
The cpu can only add a left or right audio sample at the time. If the stall happened
when feeding a left sample, but the FIFO expects a right sample as the first sample
after emptying, the channels get reverted.
So disabling the cache_flush() during audio playback solves this problem.
And cache flush is not necessary, because so much data have to be processed, that the
lcd data have been flushed nearly instantly by the audio memory processing.
your first comment: Right, the removing of cache_flush() during playback can cause these 'missing pixels'.
You cannot have both glitchless audio and perfect lcd updates with this patch.
your second comment:
Have a look at http://www.rockbox.org/tracker/task/6911. I have noticed this only without #6911 and loud music.
During normal playback I could not see/here any audio / screen artifacts.
good work
Techically spoken: Ensure flawless feeding of the audio fifo with audio samples.
Someone with the AMS specs might have a look at the volume level issue.
http://www.rockbox.org/tracker/task/6911
The correct order of patching (until it breaks again, if not svned):
1. apply patch http://www.rockbox.org/tracker/task/7036
2. apply this update
Because these two patches include pcm-pp.c and lcd-e200.c the order of patching is important.
After thinking about the importance of both patches, the better solution would have been to update this patch first then the other.
But I am tired of this kind of double/triple work. So everybody is welcome to maintain these patches.
maybe some other developer(barry?) could check the patch and maybe commit it. Or make an reasonable statement, why not to include this patch yet.
I have some questions about this patch:
1. Why is it no longer necessary to stop and start the DMA? Won't this re-introduce the fade-to-blue bug?
2. Don't you get artifacts on the screen if the cache is not being flushed?
Overall, I'm hesitant to commit something that makes the LCD driver depend on the playback state (though other developers might feel differently.) Have you tried disabling all interrupts while the cache is being flushed? If that is as effective, then it would be a much better approach until the framebuffer is moved to uncached RAM.
Dan
Also, last time I tried the patch, I was still getting graphical glitches during playback.
What I tried:
1. set frequency to fixed 54MHz (near to the minimum speed required for mp3 audio processing)
2. disable interrupts (not fiq) during cache flush
3. stop cop during cache flush
And the result is...: not good!
What I found:
The fiq interrupt is generated, when there are 10 (or less) audio samples left in the fifo. So each fiq call adds 6 new samples.
This theoretically leads to a max time of t=226.75usec to fill the fifo again without any audio glitch.
The cache flush time is dependent on the cpu frequency.
The cache flush does significantly delay the fiq execution (I read a minimum of 7 samples in the fifo @54MHz).
The cache flush time is not constant, but usually takes t=50-70usec @54MHz (memory stalls?).
I had a worst case of t=288usec with frequency scaling enabled. This for sure can lead into problems.
So in my latest tests I could not find the fifo running empty, but still got the clicks and channel swappings.
My conclusion:
A fiq delay of less than 4 audio samples already can get the fifo out of sync.
I will investigate more.
Did you also get the screen garbage, vertical (and horizontal) splitted screen?
And always cached, even it was supposed to be not cached (with n x 64MB offset).
I have only seen very small graphical glitches during playback. The immense data
transfer during playback 'flushes' the graphical data very soon from cache.
Also I have to correct my findings by this:
- the fifo keeps only 8 audio samples (not 16)
- when the fiq interrupt kicks in, only 2 audio samples are left in the fifo.
- channel swapping and clicks only appear, if the fifo runs completely empty
Another workaround idea is, to sync the flush_icache with the fiq. This allows to finish the flush_icache within 9 audio samples instead of 3 to 9 as in current software. It works quite well here, but gives additional complexity.
- reintroduce dma enabling in lcd_update functions
- remove the conditional flush_icache for the bootloader
The #7036 patch has to be applied first, then this patch can be applied.