Rockbox

  • Status Closed
  • Percent Complete
    100%
  • Task Type Patches
  • Category Drivers
  • Assigned To No-one
  • Operating System Sansa e200
  • Severity Low
  • Priority Very Low
  • Reported Version
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by ahellmann - 2007-03-25
Last edited by MikeS - 2007-05-30

FS#6908 - Sansa: avoid audio glitches, vinyl like effect

Workaround 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.

Closed by  MikeS
2007-05-30 14:49
Reason for closing:  Fixed
Additional comments about closing:   Warning: Undefined array key "typography" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 371 Warning: Undefined array key "camelcase" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 407

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.

I applied the patch and have not see the white screen of death ( FS#6900 ) so far.

s/see/seen/

Does this patch include code specifically to fix frequency scaling, or is that merely a side effect of the LCD driver fix?

Thanks so much, the audio ‘channel reversal’ problem I was having is fixed too. Here is a recording I made before I applied this patch: http://aliant.ath.cx/~andrew/sansa/u2BeautifulDay-SansaDecoding.ogg if you look at the waveform in Audacity you can see how the channels are reversed at about 2:42 and then later on go back to normal.

seems to work… but enabling cpu scaling causes a data abort… edit: ignore that… you must do a full recompile after enabling cpu frequency :p

works well…

@Llorean: Yes, it is a side effect.

@andrewg: The channel reversion has following reason (to my understanding):
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.

Scroll texts do not appear correctly. A few pixels appear to be in the wrong place on the line. I think it is something wrong with syncing of the pixels in each letter (hope people understand what I mean). I use unifont, with the UniCatcher theme.

Music also still turns itself off (like suddenly lower volume then turn if back on normal) every now and then.

@testdasi:
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.

This update avoids scrolling artifacts during music is paused.
During normal playback I could not see/here any audio / screen artifacts.

This time hopefully without bug:

rp commented on 2007-03-31 18:32

works great for me so far.

good work

Flake commented on 2007-04-02 20:30

yeah, works great except there’s no fade out/in on player starts/being off any more

Flake commented on 2007-04-02 20:34

sorry, it happens time to time, not always

Is the anti-audio-glitch patch going into current builds anytime soon?

Attached is the result of an RMAA test. The SNR isn’t great (laptop sound card) but I’ve included my laptop testing itself, it testing a Gigabeat with Rockbox, the Sansa Retail firmware, and the Sansa Rockbox firmware with this patch. You can see for yourself how the results compare: My real concern is that the volume levels don’t seem right yet, though.

   RMAA.zip (705.5 KiB)

This patch is only meant to avoid the channel swapping and the very small audio dropouts (as in sporadic vinyl like clicking).
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.

On the upside, aside from the volume issue, sound output appears identical to the retail firmware.

I have made a small patch (with help from the datasheet), the DAC gain should be about -7.5 dB which at the time of writing I didn’t know.
http://www.rockbox.org/tracker/task/6911

Oops, I forgot to say that my patch is for the volume ‘issue’.

Flake commented on 2007-04-12 02:33

glitches anyway appear for the tracks with hight bitrate (>192), one-two per minute

It is not working. I think changes on 13 Apr 20:55 to lcd-e200.c is the reason.

MikeS commented on 2007-04-14 03:36

Yes, the changes will require this patch be resynced.

Pheew, I resynced this patch:
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.

MikeS commented on 2007-04-18 02:26

Ehrm…didn’t mean to induce frustration by fixing the cache invalidation issues. :

Ooh no, I am all for your improvements. It is only a pity, that this patch doesn’t find it’s way into svn (to solve the issue until a better solution is available).

rp commented on 2007-04-18 12:48

2 or 3 weeks ago i wrote dan_a a mail about committing this patch, but i think he still has some health problems.
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.

dan_a commented on 2007-04-19 07:26

Hi Toni,
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

I have to agree with dan_a. I haven’t committed this myself because I think there should be a better solution to the problem. Ideally, we need to move the framebuffer to uncached RAM. My own attempts at doing this have so far not been successful.

Also, last time I tried the patch, I was still getting graphical glitches during playback.

dan_a

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.

barrywardell

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.

The screen garbage was only small bits of the screen while playback was happening, but it was still noticable. Why doe you suggest 64MB offset for non-cached memory? Is it not supposed to be 32MB?

According to dan_a the cached area is 64MB. But it seems, this is not really verified because of missing specs.

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.

Update to sync with ‘battery-optimized-cleaned-update’ and bootloader fixes:
- 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.

Hello i am new to this patching thing so could someone please tell me how to apply this patch???

rp commented on 2007-05-22 21:07

i guess this patch can be closed after todays commit from Mike?

MikeS commented on 2007-05-23 01:09

I’m hoping so but I kind of like the one that opened it to decide it’s fixed on these longstanding issues as well as being notified of any problems with the change first.

MikeS commented on 2007-05-30 14:44

I’d like to close any tasks related to Sansa e200 audio glitches since I’m not aware of any complaints or resultant bugs but the material here seems to cover other ground like frequency scaling. Perhaps that should be separated out and moved to a new task before hand? Antonius…you there? Op.?

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing