From: Ray Lambert <listlizard_at_interthingy.net>
Date: Sat, 15 Jan 2005 13:42:47 -0500

Hi Linus,

>Date: Thu, 13 Jan 2005 08:30:47 +0100
>From: Linus Nielsen Feltzing <linus_at_haxx.se>
>
>Ray Lambert wrote:
>
>
>>The first question is about lang and voice files. I have added one
>>small string to english.lang, but this clearly needs to get into the
>>other lang files as well. How does this happen?
>>
>>
>It is done automatically when the translator for that language runs the
>uplang script to import the new strings into the language file. Before
>that happens, the english strings will be used by Rockbox.
>
>
Okay, great. So I don't have to worry about it.


>>And what about the voice files? Is there someone who does that or is it my responsibility?
>>
>>It is nobodys responsibility, but anyone that feels like it can create a
>>new voice file and upload it to the wiki.
>>
>>
Okay cool. I guess I'm going to just concentrate on the code for now then.


>>The second question is about icons on char-mapped displays. (I have
>>added an A-B Repeat status bar icon for the bitmapped display.) From
>>reading the source code, it appears that it may be possible to define a
>>custom icon for the char-mapped screens (perhaps using a font only?),
>>but I couldn't determine how it is done. I also don't have a player
>>device so I can't even use trial and error. Is this actually possible
>>and if so how is it done?
>>
>>
>Well, the "off-screen" icons are not customizable. All you can do is to
>define a new character to be included in the character map. This isn't
>very usable for the A/B repeat, since the repeat status isn't shown
>using characters, but rather the "off-screen" repeat icons. IIRC, there
>are only icons for repeat and repeat-1 :-(.
>
>
I'm not sure what you mean by "off-screen" icons. Are you saying there
are two different display areas on these devices; one that uses fonts
and one which doesn't, or something like that?

In any case, I guess it sounds like there's nothing I can do. :(


>>Next, I was wondering if some folks with non-recorder devices could
>>suggest key pairs that could be used for the Set A Marker and Set B
>>Marker functions. I won't be able to test them but I could at least put
>>something in the patch that has a chance of working on those devices.
>>
>>
>You can leave that to us. It looks like ON and the -/+ are free on the
>player. I don't know about the Ondio though.
>
>
Okay, cool. FYI: Since my original post I've added one more key
mapping: ON+OFF will unset both markers.


>>My last question is about the A-B implementation. I am currently
>>detecting when the B marker gets hit by comparing the position in
>>id3->elapsed with the previously set B marker (also taken from
>>id3->elapsed). I am doing this in wps.c, in the key loop.
>>
>>
>The "cleanest" way would probably be to implement it in the MP3 thread,
>but that involves quite a lot of tricky work. Let's do it your way
>first, and then improve it if we need to.
>
>
Since my post, I've found a new way to do from mpeg.c which was pretty
easy and seems to be more accurate. I put the check in playback_tick()
(since that's where id3->elapsed gets updated). This seems to work very
well but I'm not sure if it's a good design decision to put my code there.

The main question is whether it's safe. playback_tick() is called from
a timer interrupt. Everything in my code seems to be safe to touch in
an interrupt (atomic and read-only); the only question is whether the
calls back to mpeg.c are safe. They all end-up doing a queue_post(),
which is safe so long as the queuing operation is safe. It seems to be
but I'm not certain. queue_post() executes a
set_irq_level(HIGHEST_IRQ_LEVEL) before touching the queue. I suspect
that disables interrupts, which would make the operation safe to call
from an interrupt. Can you confirm this?

There's also a question of using too much CPU in the interrupt. But
there's really only a few integer comparisons taking place and the
queue_post() call. So I think that's okay. I haven't noticed any
problems in my testing so far.

What do you think about this?


>Thanks for working on this!
>
>Linus
>
My pleasure. I hope it will be considered for acceptance into the trunk.

I'm just about ready to submit the patch. I'd like to test it a little
more first and I'd like to hear your thoughts on the playback_tick()
issue I discussed above, and then I'll submit.

Thanks!

~ray

_______________________________________________
http://cool.haxx.se/mailman/listinfo/rockbox
Received on 2005-01-15