Haha, Steve. :p
I gotta get this off my mind and this is close enough to on topic and
explains the "differently" and "soon" thing some more. Some tradoffs must be
oked before committing to anything:
1) Somewhat smaller file buffer (more mem used for storing 32bit samples -
what with really low mem SWCODEC like iFP?) On the bright side, 512K more is
available now. Perhaps another big chunk if we get to dumping the malloc
2) Limiting crossfading times (a channel must hold the length of a crossfade
since only one codec is active at a time). The good thing is, by and large,
channels can share the same memory space. The price is storing more list
links since packeting must be fairly fine grained so everything seems
instant to the ears.
3) Possibly a bit more CPU intense though can't say for sure. Perhaps
optimization elsewhere would offset this.
4) If samplerate switching is employed, 1-3 become even more important.
Agreement on the proper behavior regarding crossfading 2 or more tracks of
different samplerates. Some discussion has taken place and maybe all logical
consequences addressed already since it seems to lead to two options: no
crossfade in this case or don't switch rates.
5) Another thread that must have an IRAM stack. I'm thinking about how to
dump the voice thread so it may be no problem. DMA can't do the job it does
now and keep things moving when the codecs aren't loaded anymore. Processing
in the IRQ handler is just not in the realm of possibility.
Of course there's always those insights into design that happen during
implementation that could help.
Think I should dedicate any pages to discussion of these concerns? Will
anyone actually participate in deciding what they will and won't accept as
compromises? I'd at least like basically voting on "I'd rather make the
tradoffs to have the flexibility and instant response" or "Forget it, I'd
rather just have the memory (and cycle?) savings of the current system."
----- Original Message -----
From: "pondlife" <pondlife_at_ntlworld.com>
Sent: Saturday, March 24, 2007 3:34 AM
Subject: Re: Menus don't speak during paused playback
> Currently, pausing playback actually pauses ALL audio output - hence no
> voice. There has been some discussion about rewriting the playback engine
> so that the mixing takes place differently to resolve this, but it's not
> likely to happen soon.
> This affects all targets.
> Steve B
Received on 2007-03-24