Rockbox

This is the bug/patch tracker for Rockbox. Click here for more information.

Quick links: Bugs · Patches · Rockbox frontpage

Tasklist

FS#6815 - iAudio X5 Remote Ticking Reduction - need testing and help

Attached to Project: Rockbox
Opened by Michael Sevakis (MikeS) - Wednesday, 14 March 2007, 03:44 GMT+2
Last edited by Marcin Bukat (MarcinBukat) - Sunday, 05 June 2011, 13:39 GMT+2
Task Type Patches
Category Remote
Status Closed
Assigned To Michael Sevakis (MikeS)
Player Type iAudio X5
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Private No

Details

Find the option under General Settings|Display|Remote LCD Settings|Reduce Ticking

On my player this basically eliminates all remote ticking when the CPU is running at 124MHz. My player is practically silent at 45MHz but some players tick as badly at 45MHz as at 124MHz. I cannot test to find a good strategy/setting for the lower CPU frequency though I suspect a similar one should work for that.

Experiments show the sequence used in the patch to be the most effective of all tried with the lowest loss of framerate. The technique used for iRiver kills the framerate too much and isn't as good for the x5. It seems keeping the clock pulses as even as possible is one key as well as flipping clock and data at the same time. It behaves almost as though there are filters on the line specifically for emi reduction. :-\\

I will need feedback as to the effectiveness of this in general (and at high CPU speed) and hopefully I'll get some help sorting it out for the lower CPU speed.
   x5-remote-ticking-reduce.patch (11.7 KiB) 
 firmware/target/coldfire/iaudio/lcd-remote-iaudio.c |  208 +++++++++++++++-----
 firmware/target/coldfire/iaudio/lcd-remote-target.h |    3 
 firmware/export/config-iaudiox5.h                   |    3 
 3 files changed, 166 insertions(+), 48 deletions(-)

This task depends upon

Closed by  Marcin Bukat (MarcinBukat)
Sunday, 05 June 2011, 13:39 GMT+2
Reason for closing:  Out of Date
Additional comments about closing:  Outdated long ago.
Comment by Evgeniy (tralivali) - Wednesday, 14 March 2007, 06:57 GMT+2
I cannot apply this patch, because have no compiler etc...
Comment by Michael Sevakis (MikeS) - Wednesday, 14 March 2007, 08:07 GMT+2
Here's a build with it:
http://www.rockbox.org/twiki/bin/viewfile/Main/MichaelSevakis?rev=1;filename=rockbox.zip
Comment by Pascal Briehl (ColdSphinX) - Friday, 16 March 2007, 18:16 GMT+2
An other Build with it:
http://forums.rockbox.org/index.php?topic=8936.0
Comment by Evgeniy (tralivali) - Wednesday, 21 March 2007, 06:18 GMT+2
Michael,
there are still clicks...
Comment by bundy (bundy) - Wednesday, 21 March 2007, 13:15 GMT+2
I confirm. Clicks are still present (also at 124 MHz).
Comment by Michael Sevakis (MikeS) - Wednesday, 21 March 2007, 14:30 GMT+2
You made sure to set the boost up manually in the Debug Menu to rule out anything at 45MHz? If so, some players have a serious problem that would require slowing the lcd alot whereas mine only requires a modest slowdown. This could be adjustable so you can set it just until the clicks are gone.
Comment by Michael Sevakis (MikeS) - Wednesday, 21 March 2007, 14:35 GMT+2
I will experiment with other variations and post them as well. Hopefully this can be solved quickly with some help.
Comment by Evgeniy (tralivali) - Saturday, 24 March 2007, 13:54 GMT+2
Actually there are no clicks, Mike, last time I forgot to turn the option on.
Please ingrate it into the main build, could you?

I will listen more carefully, but... ;)
Comment by Michael Sevakis (MikeS) - Saturday, 24 March 2007, 18:42 GMT+2
Ok, that's what I want to hear (or is that _not_ hear :). It needs a bit of tweaking before that and at least this should cure the majority of people's devices I think. There is only one I know of that had a clicky remote at 45MHz and I'll keep on the lookout to refine this. Adding it to the main build shouldn't be too long then. I've just got a small amount of something else to finish and I'll start running this thread again.
Comment by Evgeniy (tralivali) - Saturday, 24 March 2007, 18:47 GMT+2
You mean that different devices are different? How can that be?

That time I had problems with hearing, so I'm not sure now about clicks... =|
Comment by Michael Sevakis (MikeS) - Saturday, 24 March 2007, 20:27 GMT+2
Yes, there's variation in devices due to grounding issues and that's why it's an option. For example take my H120; my remote never clicks so why should I have the framerate penalty? Others have a serious problem with it on iRivers. I have never tested the penalty on iRivers but since this works for you it seems the x5 can have a rather modest one. Allow some experimentation time and it should be good to go soon.
Comment by bundy (bundy) - Monday, 26 March 2007, 16:31 GMT+2
I tested with/without tick reduction on 45MHz and on 124MHz (manually boosted) - I hear ticks. Could it possibly be also headphones dependent? On some with big impedance (32 Ohm) I hear no ticks, but on earbuds (stock and some other ~16 Ohm) I hear them.
[Btw. I've had a nice issue on remote screen right now - the screen flipped and some lines on bottom were as some noise(?) as in TV with no signal ;) - I suspect this patch as I have only 2 - the second one is battery_estimation.patch from maxwen0. ]
Comment by Michael Sevakis (MikeS) - Monday, 26 March 2007, 20:27 GMT+2
I suppose the changed impedance could affect it, sure. I'll try some other phones. As far as LCD corruption, shouldn't be from speed issues cause it's slower...perhaps timing. Perhaps the chip select stuff. :\\
Comment by Evgeniy (tralivali) - Wednesday, 28 March 2007, 00:13 GMT+2
May be you could also think about applying this patch to M2 target later. Thanks!
Comment by Evgeniy (tralivali) - Saturday, 07 April 2007, 11:30 GMT+2
Couldn't you merge this patch to the main builds?

Theese special builds are very buggy.
Comment by Michael Sevakis (MikeS) - Monday, 09 April 2007, 21:32 GMT+2
Ticking reduction for iAudios would likely be included in any other port if those working on it want it added.

This will get in SVN. I haven't had much time and I was working on improving mpegplayer which also diverted me a bit from low latency audio work...which it might help with anyway. Doing some work on something else and stepping away for a bit leads me to more ideas about what to do about something. There's almost never an exception and I don't know why my so-called brain works that way.
Comment by Evgeniy (tralivali) - Sunday, 22 April 2007, 13:33 GMT+2
Also I found this bug:

sometimes the remote shows "a wave" and then the screen becomes garbled:
1) Horizontal 1/3 of screen is visible, the rest of space is blank
2) The screen is inverted horizontal AND vertical - like mirrored (I see twice-mirrored letters)

Waiting for the merge to main build, thank you.
Comment by Michael Sevakis (MikeS) - Sunday, 22 April 2007, 19:41 GMT+2
This bug comes without using the patch? If it only comes with the patch, that's a bit of a concern for adding it to SVN.
Comment by Evgeniy (tralivali) - Sunday, 22 April 2007, 19:47 GMT+2
I've never seen this bug in the main build. And with this build (yours one) it happens for sure, but you just need to wait. And, I forgot, this can be solved by plugging the remote out-and-in-again. Then the screen is OK for 20-30-50-100 mins again.

The build pointed by Pascal Briehl (ColdSphinX) in the beginning is very buggy (cannot even play files without remote) and I don't use it.
Comment by Evgeniy (tralivali) - Sunday, 22 April 2007, 19:48 GMT+2
And the border between twice-inverted letters and the blank space is filled with digital garbage.

May be I can take a picture of it, if you would need.
Comment by Pascal Briehl (ColdSphinX) - Monday, 23 April 2007, 06:40 GMT+2
Evgeniy (tralivali) can you explain the bugs on my build? 3 weeks ago I bricked my remote plug in the case and had to solder the headphone-out :(
But with my current build everything works fine for me.
Comment by Evgeniy (tralivali) - Monday, 23 April 2007, 07:41 GMT+2
Pascal, it hangs constantly. No matter you use remote or not. I. e. the build is very unstable, though interesting.
Comment by bundy (bundy) - Wednesday, 25 April 2007, 08:27 GMT+2
Recently my audio connector on the remote somehow disconnected from the remote board so I had to open it to repair it (it was(?) still under warranty ;) ).
I took a photo - what surprised me was the version of the board (M3). I searched on the web, and it seems like it is the same for all(?) COWON products. But I keep asking myself: What if it DOES matter?

http://img170.imageshack.us/my.php?image=x5remoteia4.jpg
Comment by Michael Sevakis (MikeS) - Wednesday, 25 April 2007, 23:46 GMT+2
For M3/M5/X5 and perhaps others it's all the same remote. The noise varies unit to unit though I'm not specifically aware of any controlled tests with Cowon where someone uses the same player with different remotes and different players with the same remote. Not different models, just different individual players and remotes. I assume this checking has been done with iRiver as certain facts are known there about the grounding being an issue.
Comment by Evgeniy (tralivali) - Friday, 11 May 2007, 09:11 GMT+2
Hello again, Michael. Couldn't you see for a sporadic remote turn-off? The need to re-plugin the remote appears too often...
Thank you very much.
Comment by Michael Sevakis (MikeS) - Friday, 11 May 2007, 10:20 GMT+2
I'm really at a loss for what to do about that. I'm not really sure why it should do it but it could be the chip select line having a problem. Overspeeding it shouldn't since it doesn't. :\\
Comment by Evgeniy (tralivali) - Friday, 11 May 2007, 10:34 GMT+2
But did you catch this behavior yourself?
Comment by Michael Sevakis (MikeS) - Friday, 11 May 2007, 19:10 GMT+2
Only when overdriving the remote display IC to a few frames higher than SVN code outputs but I knew that should cause problems. Other than that, no and probably because my main remote usage is for development and not listening. Is an unpatched build still OK?
Comment by Evgeniy (tralivali) - Friday, 11 May 2007, 19:48 GMT+2
More of that. It seems for today, Pascal's build is OK. Soooo......

May be you'll try to apply a patch to a contemporary source?
Comment by Michael Sevakis (MikeS) - Thursday, 24 May 2007, 04:03 GMT+2
I did some checks and 32-Ohm produces the worst ticking without reduction and the least with reduction. 16 Ohm, less than 32 Ohm without reduction but ticks regardless so I'm guess more extreme slowdown would be needed for that. I hate to slow the display too much and I'll find what just takes care of 16 Ohm.

I'll add a new patch that will apply to current SVN and a build with it shortly.
Comment by Michael Sevakis (MikeS) - Thursday, 24 May 2007, 04:09 GMT+2
http://www.rockbox.org/twiki/bin/viewfile/Main/MichaelSevakis?rev=2;filename=rockbox.zip

For current SVN. No other changes.
   x5-remote-ticking-reduce.patch (11.7 KiB) 
 firmware/export/config-iaudiox5.h                   |    3 
 firmware/target/coldfire/iaudio/lcd-remote-iaudio.c |  208 +++++++++++++++-----
 firmware/target/coldfire/iaudio/lcd-remote-target.h |    3 
 3 files changed, 166 insertions(+), 48 deletions(-)

Comment by Evgeniy (tralivali) - Thursday, 24 May 2007, 09:42 GMT+2
32-Ohm headphones? So clicks still will be? =(

With Pascal's build the remote turns off very rarely, but mostly when you press a key, the key "pause".
Comment by Michael Sevakis (MikeS) - Thursday, 24 May 2007, 15:24 GMT+2
It means 32-Ohm heahphones + reduction = the least clicks of any
32-Ohm headphones - reduction = the most clicks of any
16+reduction approx. = 16-reduction
Comment by Evgeniy (tralivali) - Thursday, 24 May 2007, 15:28 GMT+2
So the elimination isn't absolute now?
Eh... =(
Comment by Michael Sevakis (MikeS) - Friday, 25 May 2007, 11:20 GMT+2
It's the same patch with new SVN...that's all.
Comment by Evgeniy (tralivali) - Saturday, 14 July 2007, 14:00 GMT+2
Is there any build with it?
Comment by Pascal Briehl (ColdSphinX) - Tuesday, 16 October 2007, 14:58 GMT+2
I had to remove this patch, because since this morning it's out of sync and I don't know asm well enough to sync it myself.
So can anyone sync it?
Comment by Jan-Willem (Rost) - Saturday, 08 December 2007, 18:54 GMT+2
Pascal, I'm not having any trouble at all compiling. I guess some of your other patches messes it up.
Comment by brendan (undersys) - Thursday, 29 January 2009, 01:30 GMT+2
MikeS,

Having a bit of a issue when applying this patch to tag "19570" that should be release 3.1 , i think :)
output as follows :-
__
patching file firmware/export/config-iaudiox5.h
Hunk #1 succeeded at 71 with fuzz 2 (offset 18 lines).
patching file firmware/target/coldfire/iaudio/lcd-remote-iaudio.c
Hunk #1 FAILED at 58.
Hunk #2 FAILED at 318.
Hunk #3 FAILED at 372.
Hunk #4 succeeded at 157 (offset -230 lines).
Hunk #5 succeeded at 326 with fuzz 1 (offset -209 lines).
Hunk #6 FAILED at 341.
Hunk #7 succeeded at 356 (offset -229 lines).
4 out of 7 hunks FAILED -- saving rejects to file firmware/target/coldfire/iaudio/lcd-remote-iaudio.c.rej
patching file firmware/target/coldfire/iaudio/lcd-remote-target.h
Hunk #1 succeeded at 28 (offset -1 lines).
___

I am going to have a look and see if i can understand why its doing this. Not done anything like this so I may not be able to fix this.

Thanks
Comment by Frank Bosman (Krystalize) - Saturday, 22 August 2009, 13:04 GMT+2
This occurs on my Cowon iAudio M3 too. May need special attention. As the remote is the only screen available.

Loading...