> So how about adding the dirchache.size != 0 condition there to not update>
> last_size if size is 0? Like this:
> https://github.com/dreamlayers/rockbox/commit/d438eb3b9ee9a824e2cac85aaa306c3891694e3a
Hmmm... .size isn't going to be zero at that point if there's been even one
entry added
It could cause issues with dircache not being able to expand itself to fit more
files. The size is zeroed if it gets overstuffed (more than 3/4 of the reserved
is used) or wasn't able to finish to establish a new set point so it can scan
later without blocking.
Mike
On Monday, February
No need for that anymore. Problem solved -
http://git.rockbox.org/?p=rockbox.git;a=commit;h=8618f2c227e7daed2d1dd566090c2c4588533470
Sorry for bothering.
Hmmm...I thought about that right away and just assumed it was looked into
already. Buffer alignment in the higher level code was removed
Any others or is everything else at least reasonably functional? I find
abandoned starts terribly annoying to work around. It's not as if it's
impossible to go back, grab the code from the history and use it as a
starting point to re-port something.
I have patches that perfectly clean up
The reason I dig this up from the dead is to suggest including IFP7xx in the
purge. It's very incomplete with special exclusions in various places
emphasizing its lack of finish. I doubt anyone's gonna do anything with it.
I know I'm not and I don't want to maintain it when I update certain
We don't accept feature requests, only bugs.
Now I see the problem. We only accept bugs!
Do not go gentle into that good night.
Rage, rage against the dying of the light.
I agree with taking this course. Their presence is inconvenient at best.
Next, I'm off to read other's opinions on the matter.
BTW, ideally the rbcodec lib shouldn't rely on any code elsewhere in the
rb tree.
True, but one step at a time. :-)
I think this patch would just leave header files. Nothing now in
librbcodec's own SOURCES file would bring in any code.
For warble, there are still four dependencies (after
Changes over here:
http://gerrit.rockbox.org/r/#/c/456/
Release early; release often...release prematurely; release constantly? :-P
Hello all,
On behalf of the Rockbox developers, I'm very pleased to announce that
Rockbox 3.11.2 has just been released!
Sorry, i didn't explain it properly, was referring to protect I2C read and
write functions using a critical section instead of the actual mutex, then
a thread accessing I2C cannot be interrupted by the tick handler.
That's a very bad thing to do. I2C shouldn't keep interrupts masked that
long
The least invasive way to fix this bug would probably be to figure out
if I2C is already in use when trying to read the hold switch in the tick
task, and if it is just skip updating the hold switch status for that
tick.
Really a nice hack, just one line of code to check if the mutex is locked.
No need to look at the actual mutex, just have a volatile bool
i2c_in_use that you set to true after locking the mutex and to false
before releasing it. Then skip the hold switch reading part of the tick
task if that flag is set to true.
Just giving fair warning. :-) If there's no need for
pthread has mutex_trylock() for this case. Maybe worth having it too?
Best regards.
I could get the same functionality out of mutex_lock_w_tmo(mutex, 0)
without much more to it than implementing a simple try and without any
restrictions.
Mike
pthread has mutex_trylock() for this case. Maybe worth having it too?
Best regards.
I could get the same functionality out of mutex_lock_w_tmo(mutex, 0)
without much more to it than implementing a simple try and without any
restrictions.
Mike
Stilly me. Prio inheritance has to be undone
Tick tasks are run from ISR. There is absolutely no need to read keys
in ISR IMO, reading in ISR gives no benefits in this case.
As far as I can see, there's no reason at all to poll keys all the time
except in the sense of generating consistent repeat behavior, which means
the button tick is
..[E]xciting new features will be welcome again after
we branch for 3.11.
Frank
wHeat thins!
- Original Message -
From: Jonathan Gordon jdgo...@gmail.com
To: Rockbox development rockbox-dev@cool.haxx.se; Rockbox
rock...@cool.haxx.se
Sent: Thursday, February 23, 2012 7:03 PM
Subject: Call for testers for gerrit#120
Hi all,
http://gerrit.rockbox.org/r/#/c/120/ changes the way
- Original Message -
From: Boris Gjenero boris.gjen...@gmail.com
To: Rockbox development rockbox-dev@cool.haxx.se
Sent: Saturday, February 04, 2012 1:28 PM
Subject: Re: PP502x cache bug and ATA DMA test build
On 03/02/2012 8:43 PM, Michael Sevakis wrote:
For H10 20GB, dircache init
- Original Message -
From: Michael Sevakis jethea...@comcast.net
To: Rockbox development rockbox-dev@cool.haxx.se
Sent: Saturday, February 04, 2012 3:36 PM
Subject: Re: PP502x cache bug and ATA DMA test build
I'll give the newer cache tester a spin on 5024 with an unmodded build
My H10 exploded rather violently with using ATA DMA and testing there was
part of the reason it was switched off. Will give it a try and report back.
Mike
For H10 20GB, dircache init and database init seem to pass alright where as
before with DMA it would fault frequently. It's running UDMA 2.
My H10 exploded rather violently with using ATA DMA and testing there was
part of the reason it was switched off. Will give it a try and report
back.
BTW, I checked the patch but haven't had time to get on IRC. It's sensible
to have thing go through the driver first.
Mike
I don't see the assumption. Gigabeat S resets the chip in order to select
the interface type so how could it assume the registers are left intact? I
think only the oscillator is assumed to be left intact, which isn't a factor
on that device since it uses an external clock.
It might *only* be the internal oscillator but also *only* prevents the
chip for working and
*only* freezes Rockbox :) And since the internal oscillator is part of the
registers.. You can't
get away with the problem by saying that it works for a particular device
?!
Can't just set the
Yes. It's just like status = (status == USB_INSERTED) ? status :
USB_EXTRACTED;
Hi,
Noticed a warning for this code in firmware/usb.c, line 557 (as of
r31578):
status = (status == USB_INSERTED) ? : USB_EXTRACTED;
According to the gcc manual (section 5.7), the expression x ? : y (a gcc
Hi,
Noticed a warning for this code in firmware/usb.c, line 557 (as of
r31578):
status = (status == USB_INSERTED) ? : USB_EXTRACTED;
According to the gcc manual (section 5.7), the expression x ? : y (a
gcc extension) has the value x if x is nonzero, otherwise z. So, status
is set to
Almost certainly not. This looks like a bug waiting to happen to me.
Frank
If that patch goes in to fix FreeBSD (why isn't it commited?), it won't
matter anyway.
Mike
I still haven't seen a report of it working on a non-USB_DETECT_BY_CORE
such as nano2g. Did I miss that? Ideally I'd also like to see if
USB_DETECT_BY_CORE now magically works for those now.
Frank
I did test it on the Clip v1 bootloader without difficulties, which doesn't
use ...BY_CORE, if
Speaking of racy, this code in pcm-sdl.c / pcm-android.c
doesn't look very safe:
void pcm_play_lock(void)
{
if (++audio_locked == 1)
SDL_LockMutex(audio_lock);
}
It's only used to lock out the SDL callback, not
Forgot to add: Rockbox gets very unresponsive especially when scrolling.
Not likely anything to do with this stuff.
Speaking of keyclicks. They're not working that fine on android. Delayed
by about 0.5s and repeated when using the touchscreen.
I know what you mean. Pretty much what I'd expect from a having to fill a
long buffer from short mixer buffers without pacing the pcm thread as is
done with SDL. The
On Thursday, 1. December 2011 08:45:36 Michael Sevakis wrote:
I'll try if I can reproduce it with the SDL RaaA target,
debugging/bisecting on the workstation is much easier.
One more thing. You mentioned maemo and really, I did not work on that so
much. I just took my best guess at what
I forgot something else too. The including of optimized mixer assembly for
App targets is disabled. Something needs to be done there to get it to
compile.
Actually I did a test build back then (still floating around on my phone)
and everything was working fine. I didn't notice the performance drop.
Maemo doesn't need pcm_play_lock() as the locking is done
on the gstreamer object level.
It for locking out the callback for the rest of the system,
Is that a size we still can live with?
I forgot to ask: were you proposing to increase it for just maemo or for all
targets? I wouldn't recommend doing the latter. In fact it probably wouldn't
compile on many targets anyway and also scrollwheels wouldn't be able to
click frequently enough.
Am Donnerstag, 1. Dezember 2011, 22:07:33 schrieb Michael Sevakis:
I forgot something else too. The including of optimized mixer assembly
for
App targets is disabled. Something needs to be done there to get it to
compile.
Almost fixed, see FS #12421.
There's something else I left open
We should try to figure out if it also affects real hardware targets
or just maemo / other RaaA targets.
Cheers,
Thomas
The software mixer and the PCM buffer are distinct entities. The PCM buffer
is called by the mixer and the callback is very lightweight, much more so
than before revisions
I think you misunderstood my point, you can implement it differently with
another hardware without any problem. The proposed rds_ interface doen't
imply a particular way of doing things, is it ?
It was not specific as far as what level had a thread. If it's at the bottom
layer in the driver
I don't know how to do an async i2c driver.
Queue transfer descriptors in a linked list and have the i2c interrupt
service them, in queue order, calling a callback when each is completed.
Yes, it must be interrupt based.
I guess it's just the codec i2c driver on AMS that is like that. On
- Original Message -
From: Bertrik Sikken bert...@sikken.nl
To: Rockbox development rockbox-dev@cool.haxx.se
Sent: Friday, November 04, 2011 4:52 PM
Subject: RDS support in Rockbox
The Si4703 can be configured to capture one RDS packet, then
raise an pin voltage for 5 ms. My plan is
Using another thread is probably (maybe) overkill on AMSv2 and i.MX31 and
RDS isn't exactly a data flood so doing it without a thread from an I2C
interrupt callback is probably economical. I'm not sure if any AMSv2 players
actually have an int line from the tuner chip though. The latter as I
- Original Message -
From: Hayden Pearce
To: Rockbox development
Sent: Monday, September 26, 2011 6:17 AM
Subject: Re: Releasing the android app (was: The next release version)
It's ugly because my theme work isn't committed yet ;)
[Saint]
It's a bit clunky in the way it feels and
I wonder if the rockbox fund can pay for a Sansa Clip Zip, so I can do
further rockbox development on this player.
Approved! I've had two fully funded myself (e200v1 and H120).
You're gonna have to contact Sweden for the check though. If you can't get
through, find the nearest embassy. :-)
- Original Message -
From: Mike Giacomelli
To: rockbox-dev@cool.haxx.se
Sent: Sunday, September 25, 2011 3:58 PM
Subject: RE: The next release version
Would prefer to stay at 3.x until we're ready to release the app on the
android market.
Mike
Things seem awfully shaken up right
- Original Message -
From: Alex Parker parker.ale...@gmail.com
To: Michael Sevakis jethea...@sbcglobal.net; Rockbox development
rockbox-dev@cool.haxx.se
Sent: Sunday, September 25, 2011 7:44 PM
Subject: Re: The next release version
I wasn't actually talking about delaying the release
- Original Message -
From: Jonathan Gordon jdgo...@gmail.com
To: Rockbox development rockbox-dev@cool.haxx.se; Rockbox
rock...@cool.haxx.se
Sent: Thursday, July 28, 2011 9:16 AM
Subject: minor skin break, touch regions tag, r30219
Hi all,
So I just commited a chnage which will break
* Add a new tag which if it is used will cause the skin to draw with
the old behaviour. This is a dead simple solution for users who don't
know how to fix the theme properly but cant wait for the actual themer
to fix it.
Perhaps have a new tag that supports the new order then old skins don't
Ladies and gentlemen, we have multichannel sound!
This is beyond cool. Kudos you you, Mike, for pulling this off!
Linus
My pleasure. Thank you all for the kudos.
Now, I have some old FS tasks to close. :-)
Regards,
Mike
Are minor things like audio mixers ok?
- Original Message -
From: Alex Parker rock...@aeparker.com
To: Rockbox development rockbox-dev@cool.haxx.se
Sent: Monday, June 20, 2011 1:22 PM
Subject: Branched for 3.9
Hi all,
I've just created the 3.9 release branch. To check it out, run:
- Original Message -
From: Michael Sevakis jethea...@sbcglobal.net
To: Rockbox development rockbox-dev@cool.haxx.se
Sent: Sunday, May 22, 2011 10:54 PM
Subject: Re: Playback Engine Rework - The basic rundown
- Original Message -
From: Magnus Holmgren magnus...@gmail.com
- Original Message -
From: Magnus Holmgren magnus...@gmail.com
To: Rockbox development rockbox-dev@cool.haxx.se
Sent: Monday, May 02, 2011 2:48 PM
Subject: Re: Playback Engine Rework - The basic rundown
* Album art doesn't always show up immediately. If I exit the WPS and
return, it
- Original Message -
From: Jonathan Gordon jdgo...@gmail.com
To: Michael Sevakis jethea...@sbcglobal.net; Rockbox development
rockbox-dev@cool.haxx.se
Sent: Tuesday, May 10, 2011 1:57 AM
Subject: Re: Playback Engine Rework - The basic rundown
I cant remember if there is a generic
Hopefully the stopping problem is bandaged-up well enough for now. The album
art, well, I did have a look and as far as I can tell, the wps indeed might
miss the album art being ready. I do wish to refrain from sending new track
events that don't actually mean there is a new track. Perhaps a
- Original Message -
From: Magnus Holmgren magnus...@gmail.com
To: Rockbox development rockbox-dev@cool.haxx.se
Sent: Monday, May 02, 2011 2:48 PM
Subject: Re: Playback Engine Rework - The basic rundown
On Mon, Apr 25, 2011 at 19:39, Michael Sevakis jethea...@sbcglobal.net
wrote
- Original Message -
From: Michael Sevakis jethea...@sbcglobal.net
To: Rockbox development rockbox-dev@cool.haxx.se
Sent: Monday, May 02, 2011 7:45 PM
Subject: Re: Playback Engine Rework - The basic rundown
And when I did say:
Could be that I regressed some part of the buffering
- Original Message -
From: Magnus Holmgren magnus...@gmail.com
To: Rockbox development rockbox-dev@cool.haxx.se
Sent: Wednesday, April 27, 2011 10:05 AM
Subject: Re: Playback Engine Rework - The basic rundown
On Wed, Apr 27, 2011 at 13:09, pondlife pondl...@pondlife.me wrote:
be able shed a bit of weight because fewer
internal states would be needed.
Regards,
Michael Sevakis (jhMikeS)
- Original Message -
From: Frank Gevaerts fr...@gevaerts.be
To: rockbox-dev@cool.haxx.se; rock...@cool.haxx.se
Sent: Thursday, April 01, 2010 6:41 AM
Subject: Ladies and Gentlemen...
Ladies and Gentlemen,
After an inconsiderable amount of work, we're now proud to announce
working
- Original Message -
From: Rocker roc...@shaw.ca
To: Michael Sevakis jethea...@sbcglobal.net; Rockbox development
rockbox-dev@cool.haxx.se
Sent: Thursday, April 01, 2010 7:30 PM
Subject: Re: Ladies and Gentlemen...
Hats-off to a great success! I don't know what a Lacombe Entertainment
Am I correct that it is the hardware that
sets the CHG_ENDOFCH bit in the AS3514_IRQ_ENRD0 register? Under what
conditions does the hardware do this? Is there a way I can check to see
if
this is what is happening?
Tony
According to the datasheet, the hardware sets this bit when the
On an original (v1) Sansa e250 I cannot get Rockbox (current build as of 20
may 09) to charge the battery. Under Debug - view battery I see Battery
3.6 V (elsewhere this is interpreted as 8% charge), Charger: present, State:
Discharging. My read through the code seems to indicate that the
Hello,
While working on the PP502x ATA DMA patch (
http://www.rockbox.org/tracker/task/9708 ) I noticed that data in the
buffer is not always properly aligned for DMA. The buffering.c code
word-aligns the first frame, but the DMA code needs alignment of sector
boundaries. For example, if
- Original Message -
From: Joseph Garvin
To: Rockbox development
Sent: Monday, September 01, 2008 8:48 AM
Subject: Re: pcm_set_frequency is ignored
By the way, from what I can tell, on Sansas (and most PortalPlayer
targets), the frequency argument in pcm_set_frequency is ignored.
What's the standard way to get a plugin to play a sound effect? I'm a bit
confused from looking at sources -- some plugins store their sounds in
multiple formats, and wavplay has all sorts of magic constants in it. I have
two problems:
1) How do I convert a wav file into a format that rockbox
I didn't actually check the links and should have said Might not...
instead of It won't I guess I'll do that while I'm at my email
station
since I'm curious.
Michael
I guess I can toss that stuff in there. Most of it isn't even relevant to
our modded, one-processor-type version.
Hi,
I was looking at the mpegplayer plugin and was wondering if it is
updated against current libmpeg2 SVN.
AFAICS it isn't, so I searched a bit what changed and came up with
these changes:
libmpeg2 has been modified to have it work without malloc, decode only Y for
greyscale targets,
Michael Sevakis wrote:
libmpeg2 has been modified to have it work without malloc, decode only Y
for
greyscale targets, unneeded bits removed like checking the CPU type at
runtime and optimized for particular CPUs. It won't be a simple
conflict-free, drop-in update.
I don't think he
be a good candidate for
this project. It would be great if you would consider it as a possibility.
Sincerely,
Michael Sevakis (jhMikeS)
- Original Message -
From: Laszlo Szilagyi
To: rockbox-dev@cool.haxx.se
Sent: Sunday, March 30, 2008 5:16 AM
Subject: GSOC application question
Dear
of the other.
Mike
- Original Message -
From: Laszlo Szilagyi
To: Michael Sevakis ; Rockbox development
Sent: Sunday, March 30, 2008 7:25 AM
Subject: Re: GSOC application question
On Sun, Mar 30, 2008 at 1:33 PM, Michael Sevakis [EMAIL PROTECTED]
wrote:
Dear Laszlo Szilagyi,
One item
Wherever a hardware beep is possible, that should be used. Where not, it is
possible to play some pcm out and switch back monitoring a recording. It's
just a few ms anyway.
One thing is that the recording menu could be voiced even from the recording
screen if recording is shut down first. It has
hmmm...guess the reply is actually on the ML webpage but skipped my inbox.
*getting confused*
Somehow the response only ended up in my mailbox but I'll post it here for
the record.
On 13/10/2007, Michael Sevakis [EMAIL PROTECTED] wrote:
Someone came on IRC with describing the same problem and a new bootloader
fixed it so that seems the likely resolution.
Yes, I just updated. Works fine
Someone came on IRC with describing the same problem and a new bootloader
fixed it so that seems the likely resolution.
- Original Message -
From: Anders Clausen [EMAIL PROTECTED]
To: Michael Sevakis [EMAIL PROTECTED]; Rockbox development
rockbox-dev@cool.haxx.se
Sent: Thursday, October
I think anything I touch becomes something noone else wants to work on :P. I
expect though that I'm still allowed to work on anything that sparks
interest or fix bugs that I find annoying. ;)
A brief list of some major things few or noone other than myself ever
maintained since I got into it:
*
If TI would open up their documentation on the chip I'm sure it could go
over nicely. Rockbox is open source with full source code available. For
example: even with the AS3514 being NDA'ed, we still have the driver in
source form. I'm sure TI is protecting nonsense just like every other NDA'ed
I really think it's best to avoid a separate callback function for each
particular things and instead just go with an interface model that groups of
related callbacks and functions. If you want audio events, provide a pointer
to some sort of audio events interface. Any receiver of events can just
and
registration for each individual event which is messy.
- Original Message -
From: Jonathan Gordon [EMAIL PROTECTED]
To: Rockbox development rockbox-dev@cool.haxx.se
Sent: Tuesday, June 05, 2007 9:01 PM
Subject: Re: 1 standard generic callback system
On 06/06/07, Michael Sevakis [EMAIL PROTECTED
Something noone has answered with yes or no yet:
To avoid channel swapping in all situations and leave the CPU load lighter,
should we not just lose the two least significant bits and simply use 32-bit
L-R pairs as is done in my patch? As soon as the reason for the two bit delay
is discovered,
The entire queue seem to be visible in TX:70002840-7000287f and
RX:70002880-700028bf. I'm not sure where that might help yet if at all. All I
know is that I can write audio to any of the TX range and get sound out. Is it
possible DMA could run regardless of the bus lock? hrm...guess that's a
This brings up some important questions to answer: What audio
processing/switching hardware exists outside the codec chip (besides this)?
Is it an established fact that the OF eq is software? Signal processing
could easily be slipped in on the I2S bus between the CPU and AS3514.
I noticed also
Some basic observations and they are confirmed correct after much toil and
board spamming. :P
Simple to describe:
If I set bits 30 and 38, an endless stream of GPIO interrupts occurrs that I
can't shut down by acknowledging any known bits. It makes absolutely no
difference if any of the known
Ok, I've got a nice scrollwheel that blinks with each GPIOH transistion but
starting rockbox gives me a black sceen...the GPIOH interrupt still functions
though. I _do not_ have a clue why atm the black.
otherwise.
Here the quick tester which I'd expect to have boot, disable the scrollwheel
and blink when turned. It only does the latter two.
You'll get some warnings but that's irrelevant to this check.
- Original Message -
From: Barry Wardell [EMAIL PROTECTED]
To: Michael Sevakis
Wouldn't software interrupts be needed to call code to switch to a supervisor
mode when needed? I _am_ rather new to ARM and such but it's my educated guess
atm based on our other big CPU. I fear major complication from it.
- Original Message -
From: Antonius Hellmann
To: Rockbox
: Antonius Hellmann
To: Michael Sevakis ; Rockbox development
Sent: Wednesday, May 09, 2007 12:18 PM
Subject: Re: PPs running in supervisor mode
Yes, this is correct: In User mode, the control bits of the CPSR are
protected from change, so only the condition code flags of the CPSR can
I'll try that but I may have been there. I did too many combos to recall for
sure though.
- Original Message -
From: Antonius Hellmann [EMAIL PROTECTED]
To: Michael Sevakis [EMAIL PROTECTED]; Rockbox development
rockbox-dev@cool.haxx.se
Sent: Wednesday, May 09, 2007 2:11 PM
Subject: Re
occurs for each pending one and all
IRQs that are flagged should be dispatched at once...if we don't care about
it then clear those remaining bits.
- Original Message -
From: Michael Sevakis [EMAIL PROTECTED]
To: Antonius Hellmann [EMAIL PROTECTED]; Rockbox development
rockbox-dev@cool.haxx.se
Experimental results follow...some seem will rephrase what you already said.
Now my comment in my FS task is out of sync :).
CPU_INT_EN functions as both ack and disable. Setting a bit any number of times
when the corresponding bit is set in the *_STAT register has no effect other
than to ack
BTW: I know there's filtering but the mixing of handlers is unsettling not to
mention the COP being given access to *_button_int(). Neither here nor there in
what you're working on I think.
?
I would've whipped up a IRQ button driver real quick and committed it but I see
I've been beaten to it while fixing playback bugs. :)
- Original Message -
From: Antonius Hellmann
To: Michael Sevakis ; Rockbox development
Sent: Tuesday, May 08, 2007 3:19 PM
Subject: Re: Sansa
interrupt. Well,
the light shuts off when I turn the wheel. :D
- Original Message -
From: Antonius Hellmann
To: Michael Sevakis ; Rockbox development
Sent: Tuesday, May 08, 2007 3:19 PM
Subject: Re: Sansa (PP502x?) GPIO interrupts in rockbox software
Yes, the CPU/COP_INT_EN
It looks like HI_MASK = 0x4000 (bit 30 - same) and GPIO_MASK = 0x40 (bit 6)
for the PP5024 since I get a GPIO interrupt with just those bits set. I'll try
to work out the rest to get it running.
- Original Message -
From: Antonius Hellmann
To: Michael Sevakis ; Rockbox
Don't worry about any date conflict with me though and just do the best
compromise without weighting it in. There's just too much going on (more
why: serious stuff re: health issues in family) so I'm on the maybe list
but I really can't commit to anything. The only thing I'm sure of is the
time to
Hey, I really thought about adding something to this effect myself since
pointers vary depending upon 32/64 bit target. Perhaps a cleanup of the
formatter could actually result in a size reduction and more features at the
same time.
- Original Message -
From: Flyspray [EMAIL PROTECTED]
Hey, if I can just drive there, go Michigan. :)
- Original Message -
From: T.J. Ross
To: Rockbox development
Sent: Friday, April 13, 2007 2:26 AM
Subject: Re: DevCon 2007 - West Edition
I'd be interested in attending if it doesn't interfere with my job and the
trip ends
Sure, it's all good. I'll take responsibility for doing this since I put 'em
there in the first place. I can remove them from pcm_record.c too. No other
files should have them that I recall. It can be done within an hour or so.
- Original Message -
From: Hardeep Sidhu [EMAIL PROTECTED]
Oops forgot about the encoders. They're so much better than defining local
macros for use by one function because of the type checking and not
polluting the namespace but obviously troublesome. Just giving a quick test
now and I think they should all be gone from any work I did anyway.
-
We have no time/pitch stretcher at the moment that can change just one or
the other but it could be done. The pitchscreen is just the same resampling
used to play different sample rate files. A Gigabeat would probably be able
to handle the highest quality methods. It's the most powerful player
A thread can terminate itself with remove_thread(NULL). No other step is
needed and that call will never return. No need to save the pointer or yield
afterwards as _had_ been the norm before.
- Original Message -
From: Timo Horstschäfer [EMAIL PROTECTED]
To: Rockbox development
1 - 100 of 116 matches
Mail list logo
