All Projects

Enter the screen once, everything seems ok. Exit the screen and return, 90% of the time just once, and it crashes inside peak_meter_draw_get_btn. Removing function calls from that function (get_action, peak_meter_peek, drawing code and adding a simple button_get to be able to exit) doesn’t make the problem disappear. It looks like peak_meter_draw_get_btn just doesn’t return properly. Why? No idea.

Another thing that is happening on the target is at boot after USB connection, the backlight sometimes is completely non-functional (no visible screen but can shut off). That never used to happen.

No voice file is present at all. Did settings reset, etc. This started some time just _before_ convering voice to buflib. I mentioned it but not a soul considered it relevent as far as I could tell.

I’m putting this here so it doesn’t get blown off since apparently I’m the only one that would notice a problem on Gigabeat S. Perhaps it is telling us something about the general state of things? Yes?

Oh, yes, now USB stack overflowing during screen dump once when I tried it. I never saw the beast do that before.

Not many details. If we're not going to use it, then strip the $Id$ field that used to hold file properties from everything, if we care to.

These devices can spend alot of time in ISR's waiting to perform operations like reading the DBOP or waiting for it to go idle. AMSv2 has PMU read and write functions that keep interrupts disabled for a full two I2C transfer. This can prevent audio interrupts from being serviced in a timely manner resulting in occasional dropouts for playback or small bits of lost data for recording. The solutions are 1) Enable stack interrupts on all targets 2) Rewrite ascodec_read/write_pmu to disable interrupts only to place two consecutive requests in the queue but wait with interrupts enabled for completion.

Interrupts callbacks are in SVC mode on its own stack. I'm not certain what size is reasonable. Theoretically all enabled interrupts could happen up to the highest level, potentially consuming quite a bit of stack in the worst case and 1/2 the current IRQ stack just to save context.

I also disabled semaphore_release context switch for the moment. A different scheme that explicitely checks for thread execution context will be needed as interrupts being disabled won't be a way to discern whether or not interrupt context is executing.

One interesting issue on Fuze v2 that I have not been able to figure out is that if the GPIOA ISR is interrupted by a higher-priority interrupt, execution ends up in all sorts of strange places, with the concomitant fault screen or freeze. Unless the cause of that is remedied, GPIOA's ISR will have to be the highest priority or the enabling of IRQ during ISR selected on a per-handler basis. GPIOA's ISR is very short so shouldn't hurt latency very much.

Surprisingly, no other stacking I checked by running recording and delaying for a few thousand microseconds inside the ISR in order to force audio interrupts on top of another produced any sort of fault.

As the title suggests, voice menus cease to operate after using the recording screen. A reboot is required to restore voice menu functionality. I checked using r30339 on Gigabeat S and Sansa Fuze v2 thus suspect any SWCODEC target with recording would be affected. I do not at this point know which commit introduced the issue or if further voice issues exist.

Adds key sounds like keyclick and track skip beep to mpegplayer since seems like a good place to start using mixer functionality, in a small way, in plugins. Also, consolidates the functionality into a couple common system sounds calls to add ease of use and consistency for plugins. Mpegplayer, as usual, follows core playback settings.

Here we slice up PCM frames into about 1/20s chunks. Codecs set elapsed times and offset before the next PCM insert which associates those values with the audio data it subsequently commits to the buffer.

Codecs are modified only minimally so that they set elapsed/offset before outputting anything.

Why?

* Accurate position reporting of samples, especially when using the time index in an uncoventional way (as a sub-track indicator for instance).

* Timing is accurate through track duration regarless of pitch changes.

Now, this is still pretty prelimary. There will likely be short time-reporting glitches in the WPS when switching tracks. Crossfade is not properly converted so don’t use it here!

I don’t want to invest too much into the current way of doing mixing to accomodate a new buffer format. I’d like  FS#12150  in first before making changes to the format.

Primarily I put this up early so that videogame music enthusiasts can enjoy the benefits.

Implements a multi-channel mixer with fully-independent playback and volume control on each channel.

Long-standing bugs addressed:
Voice and keyclick do not work while playback is paused – fixed
Fade on stop/paused does not work on all outputs - fixed

Voice and keyclick are as responsive to user input while playing music as when not, which was not previously the case. Additionally, voicing in the audio menus where pcmbuf is running with low-latency is stable.

PCM interface for each channel is largely identical to current callback mechanism. The main difference is the function call names and the need for a channel ID.

Mixing is done during the mixer’s main PCM callback, which calls the callback for all active channels. Double buffering of short mix frames ensures there is enough time to compute the final downmix before hardware FIFO’s run out of data. One minor change to PCM drivers is required to implement it so that the next frame may be produced while the current plays.

Silence plays for 3 seconds before PCM is actually stopped after all channels report ‘no more’ in order to prevent popping for keyclick and voice output. Recording workaround in order to be sure PCM is stopped for half-duplex PCM drivers is a bit messy right now but works.

Playing PCM from plugins while music is playing should be possible so long as their callbacks aren’t very demanding. Same goes for the possibility of voicing/click/beep whle recording where full-duplex PCM is implementable.

Yes, as usual it all takes a good bit more RAM to have something nice but it appears a worthwhile trade.

A problem was mentioned in rockbox-dev where album art might not get picked up initially when starting playback (http://www.rockbox.org/mail/archive/rockbox-dev-archive-2011-05/0000.shtml). I can see how the problem can happen and a way to rememdy it, at least for now. This adds an event that is fired when the remaining handles are finished that the UI has to care about, iff the track was only partially loaded at the time the new track event was fired.

Ok, so maybe it’ll stay or maybe it won’t. Some other strategies are possible in the way things work underneath that could make such an event unneeded but the changes would be somewhat deep.

Does just what it says - moves the automatic resume submenu out of the general settings submenu over into the playback settings menu!

It’s about time to start testing this since it’s been working well enough for me now and better than current SVN. It renovates the codec and playback system, addressing whatever bugs are in scope for it and largely confined to directly-related files. It’s not all changes I want to make but I almost made my 512KB .patch goal :p. Redoing PCM and some other stuff would be going too far in one felled swoop).

Codec interface is radically changed. NSF codec needs some updating with the metadata parsing if it’s to work correctly because it can’t poke values into the WPS any longer; the codec’s metadata is private to it and playback. I’ve considered some sort of proper metadata push interface if we do want to do that sort of thing. Anyone who knows about them, give certain codecs a check; however for the most part, the changes are fairly formulaic.

There’s a #define in playback.h called ‘AUDIO_FAST_SKIP_PREVIEW’ which enables fast skip preview to keep the displayed track in time with user actions but does use more RAM, so if it’s of little benefit on a target (most likely a flash one), it can be disabled for it.

Patch allows Doom to run when EABI tools are used to build for ARM targets. All enum typedefs are converted to int or unsigned depending upon the presence of negative values in the enumeration. The change is global to the plugin to avoid worrying if something was missed somewhere.

Firstly, on the x5 remote, the forground and background theme colors get applied to the remote screen even thought they are not supposed to be. The RWPS is fine with black on white. For Cabbie this means the the various lists and statusbar are black background with gray text (which isn't very readable there). Switching themes to iCatcher sets it black on white like it should be and reloading Cabbie set it back to gray on black.

The settings code appears to be correct and only applies the colors to the main screen. Somewhere, somehow the main lcd settings get leaked over.

Secondly, no auto refresh on any sort appears to happen on the remote statusbar– not time, not playback icons, not volume, perhaps not battery (I didn't watch long enough).

Firstly, on the x5 remote, the forground and background theme colors get applied to the remote screen even thought they are not supposed to be. The RWPS is fine with black on white. For Cabbie this means the the various lists and statusbar are black background with gray text (which isn’t very readable there). Switching themes to iCatcher sets it black on white like it should be and reloading Cabbie set it back to gray on black.

The settings code appears to be correct and only applies the colors to the main screen. Somewhere, somehow the main lcd settings get leaked over.

Secondly, no auto refresh on any sort appears to happen on the remote statusbar– not time, not playback icons, not volume, perhaps not battery (I didn’t watch long enough).

Firstly, on the x5 remote, the forground and background theme colors get applied to the remote screen even thought they are not supposed to be. The RWPS is fine with black on white. For Cabbie this means the the various lists and statusbar are black background with gray text (which isn’t very readable there). Switching themes to iCatcher sets it black on white like it should be and reloading Cabbie set it back to gray on black.

The settings code appears to be correct and only applies the colors to the main screen. Somewhere, somehow the main lcd settings get leaked over.

Secondly, no auto refresh on any sort appears to happen on the remote statusbar– not time, not playback icons, not volume, perhaps not battery (I didn’t watch long enough).

Firstly, on the x5 remote, the forground and background theme colors get applied to the remote screen even thought they are not supposed to be. The RWPS is fine with black on white. For Cabbie this means the the various lists and statusbar are black background with gray text (which isn’t very readable there). Switching themes to iCatcher sets it black on white like it should be and reloading Cabbie set it back to gray on black.

The settings code appears to be correct and only applies the colors to the main screen. Somewhere, somehow the main lcd settings get leaked over.

Secondly, no auto refresh on any sort appears to happen on the remote statusbar– not time, not playback icons, not volume, perhaps not battery (I didn’t watch long enough).

This utilizes the hardware equalizer in the WM8978 with a front end presenting them as tone controls. Filter cutoff settings are presented as well as enabling the Enhance 3d effect. All items are located in the Sound Settings submenu.

EQ bands: Bass, Low-Mid, Mid, High-Mid, Treble
EQ frequency: Bass Cutoff, Low-Mid Center, Mid Center, High-Mid Center, Treble Cutoff
3D effect: 3-D Enhancement

Edit:
Additionally, I also hope to spur discussion to reach a consensus on just how to include these sort of hardware features in the sound menu in a friendly way and let it be the model. The fronting as tone controls just came from the idea of having another “EQ” in addition to the Rockbox software one as being possibly confusing to the user.

Changes playback on PP502x based targets to use DMA. More battery life is possible since not as many CPU cycles will be needed in order to transfer audio to the codec and a reduction is buffering time is possible too. Needs testing just to make sure everything works alright for all relevant targets and if possible I’m curious about battery benches, etc.

No recording work with the DMA engine is done here. If playback is reliable, it’s likely just about the details for that.

It appears on my e260 there is a couple megahertz reduction in boost compared to the same tracks doing it the old way.

Enables charging for Gigabeat S.

Can charge through USB. When connected to USB only, the unit seems to have trouble actually doing that since the disk always spinning when connected. At least it seems that way at the moment.

The AC adapter will supply enough current to charge regardless.

Well, my unit seems to like whatever is thrown at it but apparently that isn't the case for everyone. If you had trouble with the ASM YUV update for 20GB H10 which caused display problems in mpegplayer, then try each of these patches by themselves and report for each if it works or not.

This implements a playback engine with frame-accurate seeking for mpegplayer (in all streams). The UI portion for seeking during playback is not included (that's the next step after a commit) but the underlying machinery will do that. The time resolution of the current resume screen is now 1-second with 1-minute coarse browsing available on all targets.

Startup and resume should be much faster since the disk buffer is implemented as a direct-mapped file cache for random access. Addition of the UI will be rather simple with the drawing of rotated text on portrait displays being the most difficult aspect but doable.

To note: Encode with frequent GOPs (1 second or less which is the usual case). These are the random access units and guarantee a keypoint for random access. Encoding with GOPs 100s of pictures long (I have files from someone that are encoded this way) is never a good idea if you want rapid random access to a particular point in the file. Right now it doesn't give up trying to find GOPs if they're too far away. Whether that matters very much definitely depends on processor power since winding a couple-hundred frames from a keypoint to the proper frame really doesn't matter much on a gigabeat. :) That's tweakable later anyway.

Poke at it and do tell…I want to commit soon. Minor tweaks aren't the concern here. I'd like to unload it before doing deeper stuff.

EDIT: I do need to straigten out the Copyright parts in the headers. I just pasted mine in all the new files just to have the Rockbox header.

This changes the suppoted voice format from MPEG audio to Speex and moves the decoder to the core which simplifies the playback engine greatly and factors voice away from playback.c.

This enabled SPC files to be played with echo on PortalPlayer targets like iPods and Sansa. It operates in a pipelined manner by running emulation on the COP and audio output on the CPU. Comes with a few asm optimizations to help out a bit though most help is just from the parallel processing.

Only reason this won’t go into SVN right away is that there is no compatibility with voice. There is no facility to swap-out multithreaded codecs – multiprocessor or otherwise. I plan to address this since I think codecs should have full control over their processing setup. The piplined method should be preferred for especially intensive codecs anyway.

This will compile for single core ARM and Coldfire as well and doesn’t create the extra thread in that case.
Single-core ARM still gets the asm tweaks.

This is _potentially_ applicable to any scrollwheel-based device. This first patch will only work on the e200 series however. It’s not SVN ready but since the availablity of event data is sort of hacked in to make it just work.

List acceleration is based upon velocity-squared time a constant times number of missed wheel interrupts. The perceived velocity in the list should remain rather constant regardless of CPU load for any given wheel speed.

Fine control remains fine and yet you can move very far with a single wheel flick. It should be easy to aim for a particular range in the list (looking at the scroll bar). A small amount of time with it should make aiming pretty much a reflex action.

This patches the button driver uses GPIO interrupts to read all buttons. Sharp clickwheel response is the biggest benefit. Contains other ancillary changes to make it work correctly and well.

I also suggest the interrupt handling/dispatching scheme be evaluated on other PP targets. CPU_INT_CLR and its companions in their respective heirarchical positions is simply an ack mechanism it seems.

Test and report; I'd like to do a commit on it shortly. ;)

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.

Adds synchronous interthread message sending with a return value.

Features:
1) Can be #ifdef-ed away if a target doesn’t require the functionality
2) Data is allocated and functionality enabled on a queue by queue basis with queue_enable_queue_send. Only one more pointer member in the event_queue structure
3) Uses scheduler blocking mechanism
4) Minimal overhead in checking if a message is sent or posted. Add one function call (queue_reply) to thread function with sendable queues.
5) Overflow safe
6) Interrupt safe (though interrupts must not call queue_send)
7) A sender knows the reply is for the senders particular post
8) queue_send automatically degrades to queue_post and returns NULL when sending is not enabled on the queue
9) Nets out at 164 bytes with only a single module using it. I expect savings in overall if used throughout when appropriate. callback_queue in playback.c should be able be removed and replaced with sending messages to the audio thread and receiving a return value since additional queues are currently used to implement message return values.

pcm_record.c modifications are included since that will be the first user of the new api.

Adds new functionality to recording for SWCODEC:
1) Adds samplerate support for all codecs
2) Adds samplerate playback and record support for Coldfire
3) Select for recording format
4) Individual encoder menus where applicable
5) Delayed file creation (up to 16 in waiting) with the option to start each new file immediately if desired.
6) More advanced encoder framework
7) Means to specify samplerates for targets with minimal changes to other code
8) A plugin to check samplerate switching on playback (maybe include this in CVS as a dev plugin?)

IMPORTANT:
What I really really really need checked here is sample rate switching for uda1380 (iRiver). I know it works on the x5 just fine. The plugin is called sampr_test and will start by playing an A at 44100Hz. Changing the selection should change the pitch in proportion to the sample rate (octaves) if things are working. There should be no strange artifacts when doing this (some clicks maybe but x5 is seamless).

88.2kHz monitoring during recording on the x5 does not work and this recording rate will not be included if this issue cannot be resolved though recording itself at 88.2 does in fact work fine on x5.

There are finer issues to be worked out but not for stability…just fine tuning really and then syncing upcoming iPod recording with this which I will help with.

In summation:
I’m basically looking for iRiver owners to try this and report back about the sample rates. For x5 it’s a go. Others can be check to be sure there are no I’ll effects from the changes though nothing should really majorly change for anything other than x5 and iRiver.

Thanks in advance to all who take the time to test and comment but bear in mind I’m not looking for feature requests at the moment as that will be better to work on with this in CVS first. There are things I’d like to add myself. :)

I've talked about a problem before with recorded files (at least with codec system) not having the displayed progress stop a couple of seconds before the true end of the file even though the file actually plays to completion. Well it turns out it's not actually a problem with the recording system at all.

Here's what happened:
* Recorded an 18 second FM Radio segment.
* Test played that and of course progress indication stops at about 16s
* Plugged my x5 into my computer
* Made a copy of the recorded file
* Loaded it in CoolEditPro
* Saved over the copy with CEP (Save extra non-audio information UNCHECKED)
* Played the original…same thing as before
* Played the copy…the copy showed progress to the 18s mark as it should…perfect playback in all respects. Could be a change in the file?
* NO! A file compare shows the original recorded and resaved copy to be IDENTICAL! No difference in data or size!

Now, shouldn't two identical files play exactly the same way?
My hypothesis: This bug must be in the file system functions.

This should be tracked down and fixed by someone knowledgeable in that area with little delay.

Adds ASM routines to lvd_yuv_blit to help with speed yielding a scorching 15.1 fps on the test video. One variant ran 15.3 but would've been way too large considering the .2 fps advantage. I'm sure there's not much more to improve in this regard and the codec is the next place to look for speed.

Reimplements (again) the main lcd display driver routines this time in assembly using burst line tranfers to bring thing back closer to the good ol days when the lcd framebuffer was in IRAM.

Adds a new file to the x5 target tree called lcd-as-x5.S

Driver test plugin and patch included here. Provides function access for the test suite. The patch and souce and in x5-lcd-perf-and-features-test.zip. Please remove this plugin patch before committing.

x5-lcd-performance-before-and-after.txt gives the history of framerates with each change in CVS using test-fps.rock

Prevents interrupts from being reenable at shutdown as well as not giving up control to other threads once KEEPACT has been set low.

Implements lcd_yuv_blit in the x5 driver.
Adds nescessary defines for mpegplayer to use it on the x5.
Hard coded to YUV4:2:0 for now.

Helps a few fps and I get the impression things are close to maxed out as far as speed. Tried everything including lookup tables (which didn't really help at all– even in IRAM). Can blit any rectangle of the image and keeps drawing clipped to the visible display.

The awkward gotos are there to save precious bytes for the leading and trailing pixels drawing.

There's a fair amount here in this one.

* Adds a Backlight (On Hold Switch) option for all platforms where HAS_BUTTON_HOLD is defined (Adapted from  FS#5735  by Bernych). (H100, H300, 3G, 4G, iFP-790, X5)
* Adds LCD Sleep (After Backlight Off) for those defining HAVE_LCD_SLEEP in config (RaeNye's idea). (x5)
* Adds HAVE_LCD_ENABLE (x5, 3G, H300) and BL_X5.
* Turns off visible display op. with backlight for x5.
* Makes nescessary LCD driver changes to implement sleep and disp. shutdown plus a few tweaks that save IRAM and RAM without perf. sacrifice.
* Adds a hack to make sure bl flash doesn't happen if bl is off…namely make sure shutting down screen is always displayed (TODO: skip that if low batt shutdown), bl thread is stopped, and no yields occur once the system is flushed (x5).
* Starts some things to add the hold setting to the remote. No functionality is lost; just moved some code.
* Contains a few miscellaneous changes that my text editor made, namely tabs→spaces, strip trailing whitespace. Not too much but a big pain in the behind to remove. :)
* Other things I can't remember that I did.

When playing a song and *pausing* it, select another track by using joystick right/left or hitting the select button to browse for another sound file to play. Should be paused with track ready. Start playback.

For about a .5-1 second, the previous sound file will continue playback where it left off (peak meters and all) then abruptly start playing the current selection.

Stop doesn’t have this problem.

Speeds up the X5 LCD driver functions and implements all remaining APIs except lcd_blit and contains the bug fix found in  FS#5734 . The driver patch will be updated if the said bug fix is committed first.

The bootloader gets smaller versions of the lcd_update_* functions (less unrolling of loops).

x5-lcd-performance-before-and-after.txt show a table of framerates gathered using test_fps with the best of three runs for each data point. Should be self-explanatory.

x5-lcd-perf-and-features-test.patch.zip contains a test plugin to test the lcd functions that were changed/added. It exposes some APIs needed by the plugin. Remove the patch included in the zip before committing.

Fixes a bug in lcd_set_contrast that sets R_POWER_CONTROL5 to an incorrect value that degrades the display (Vertical lines appear when slowly moving the unit side to side and display is darkened a bit). Also changes the way the contrast option is included to minimize editing for newer ports (add HAVE_LCD_CONTRAST to config*.h a la HAVE_BACKLIGHT_BRIGHTNESS). Doesn’t effect the way other ports using “#if !defined(HAVE_LCD_COLOR)” compile.

Within the day I will add an x5 driver performance and features upgrade that will include these changes (if this isn’t committed before then) because I could not avoid it in a reasonable way and it ~will~ conflict. If this is committed :) ~after~ I post the driver upgrade, I will post an update to it. The smaller bug fix is easier to check out than an entire driver update of course.

Updated version of Rani Hod’s backlight flicker patch that doesn’t conflict with the latest backlight brightness changes.

Fixes backlight flicker when the firmware is started. The power on flicker can be fixed if you flash a new build of the bootloader. Replacing rockbox.iaudio alone will just fix it when the LCD is reset after the bootloader starts the firmware.

BTW: I checked and there are 0x0D’s present in my patch this time! :D Oops.

Improves the backlight brightness setting interface/parameters for the iAudio X5.

Parameters held to acceptable ranges per D305A datasheet:
* PWM frequency reduced to 512Hz to keep within 400-2000Hz range (doesn't hurt brightness).
* PWM duty cycle kept within 15%-100% range.

Higher value now equals brighter display by inverting GPO1 on the PMU. This was reversed before.

Improvements to the set_backlight_brightness function.

Default brightness now the same as the boot setting.

Patch that puts the X5’s LCD chip in standby mode when the backlight turns off and goes through the recommended poweroff sequence on power off. I combined these because implementing one pretty much automatically implements the other.

Note: I don’t know why the entire backlight-x5.c is being diff’ed. I didn’t change the entire file.

Changes:
- Added LCD shutdown and standby code to lcd-x5.c
- Implemented a new function lcd_shutdown() to lcd.h for shutting down LCD during power off. Called from power_off() power-x5.c
- Added #define BL_X5 12 to config.h since having it defined as BL_IRIVER_H100 causes conflicts. I also needed lcd_enable() declared independently from an H100 build.
_ Added lcd_enable calls to backlight_on and backlight_off in backlight-x5.c.
- Added LCD instruction #define’s to lcd-x5.c plus two static routines.