From: Michael Sevakis <jethead71_at_sbcglobal.net>
Date: Sat, 24 Mar 2007 17:38:57 -0500

Last big note in here:

1) 32 bit because of the internal multiply accumulate operations , greater
efficiency working with longword data on the cpus and also the fact that
most codecs - it may be all but speex now - output > 16 bits, some codecs
can avoid extra downscaling before sending to dsp, etc. etc. I may except
this for voice and just store its channel in 16 bits and scale up when
processing and mixing. If I kill the voice thread and have a special
dedicated voice codec (NOT in the core)then I'll just have it output 16 bit
samples. Really processing 16 bit samples with 32 bit code should work, they
just need different scaling later.

2) Latency will never be allowed to increase. :) Latency means something
totally different here.

3) I desire codec switching in this and have no wish to ever remove it and I
don't see much advantage to doing so.

Super-simplified ASCII diagram (Use fixed font):

Codec1 a)
>-------|Ded. Lead Buf|--|Main Mem Pool|------------|b)DSP|---+
Codec2 a) |
>-------|Ded. Lead Buf|--|Main Mem Pool|------------|b)DSP|---+-----+
Voice d)
|b)Sum|--|c)DMA Buf|--|hw|
>-------|Truncate|-|Ded. Lead Buf|--|Main Mem Pool|-|b)DSP|---+-----+
Beep e) |
>----------------------------------------|b)Beep Generator|---+

a) Crossfade involves nothing more than alternating codec channels and
applying envelopes. Fading in advance won't save us from this. Voice can
operate with downstream resampling though. Main mem pool must be large
enough to hold entire fade. 96kHz stereo audio, 32-bit, 7-second fade needs
5,376,000 bytes + links.

b) Thread operates these and returns memory to pool after sending to DMA. If
a limiter can operate here when mixing, then all channels can be mixed full
volume. Really only a concern for voice/beep. Fade in/out will operate here
too- no more volume control hack. Some early premix before doing certain
operations like crossfeed would keep load lighter:

|Resample|--|Gain|-+ Codecs
                   +---|Crossfeed|-|Channel Modes|-+-|Tone|-|Eq|-+->DMA
|Resample|--|Gain|-+ | |
|Resample,etc.|------Voice-------------------------+ |
>--------------------Beep----------------------------------------+

* We'd better have any eq wrap problems fixed here.

c) Simple dumb queue with a 100ms latency or however small can be gotten
away with. We never stop or pause this. It runs to empty always but won't
matter because of the small delay.

d) Supplied by codec thread

e) Virtual channel

Suppose I'll post this stuff on said page when I get it all together in
detail.

----- Original Message -----
From: "pondlife" <pondlife_at_ntlworld.com>
To: <rockbox_at_cool.haxx.se>
Sent: Saturday, March 24, 2007 12:30 PM
Subject: Re: Menus don't speak during paused playback


> Hi Mike,
>
> > 1) Somewhat smaller file buffer (more mem used for storing 32bit
samples -
> > what with really low mem SWCODEC like iFP?)
>
> Why 32-bit samples? Processing efficency? Wouldn't an option to use
16-bit
> be helpful? I tend to use my DAP to play 128k MP3s in a car, not as an
> audiophile - thus preferring battery life over s/n ratio.
>
> > 2) Limiting crossfading times (a channel must hold the length of a
> crossfade
> > since only one codec is active at a time).
>
> How limited would this be? The current (7 second?) window is quite
useful.
> Maybe each channel could have multiple buffered blocks, and crossfades
could
> somehow be prepared in advance (i.e. latency is allowed to increase during
> crossfades). I'm thinking of the decode and PCM playback as being largely
> independent, with a new set of channel buffers between them, if that makes
> any sense!
>
> > 3) Possibly a bit more CPU intense though can't say for sure.
> > Perhaps optimization elsewhere would offset this.
>
> This is likely to be true, although the code could be that much simpler
that
> it makes little difference. There is considerable expense in the current
> codec switching anyway.
>
> > 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.
>
> I vote for no crossfade in this case.... KISS above all else.
>
> > 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."
>
> Set up a wiki page - start with this conversation and point devs to it (ML
> and IRC).
>
> --
> Steve B
>
>
>
>
Received on 2007-03-24