All this squeaky clean sound conversion is great for transporting those sounds to and from the analog & digital domains. however it does little to add character to the sound 
The essance of such a project would be to encapsulate the elements of sound distortion + artifacts inherent to varying imperfect transitions between these domains. The General problem with downsamplng ins software is that it tends to smooth the signal by applying a ‘low pass’ filter - rather than spitting it out raw. + other things like lower bit jitter sound interesting (think Casio CZ series).
Would be nice to have this as a stand alone widget +
With the versitility of simple manipulations the streams directly - i would assume that effects could be acheived which; somthing like Reaktor could not be hacked to do.
Anyway, as TK notes - not likely to be able to do anything useful with the standard MIOS pic. Will Read up some more on this - maybe somthing could be done with another chip.
The resampling could at a guess be acheived by having enough memory to load a whole ‘sample frame’ into memory at once & then ignoring ‘x’ number of frames (in relation to the given sample freq) + giving the last read frame as the current frameset until this table is updated with the next frame that is read.
…hmm might need afew more mhz - but with a frame worth of memory this might work (?) 
Thanks for the feedback - will ponder this…
Update #1:
With the information provided on TK’s link (Ta !) - the ammount of actual audio sample data in the various packets & sub packets brakes down like so:
[ SubFrame] 16 bit SubFrame = 16 bits - (per SubFrame)
[ Frame] 16 bits x 2 SubFrames = 32 bits - (per Frame)
[ Block] 32 bits x 192 Frames = 6,144 bits - (Per Block)
A subframe is the smallest packet of data 32 bits (16 bits ‘reserved’ for the audio samples), which represents one sample frame for one audio channel. a bit flag is also assigned to say weather this frame belongs to the left or right channel; presumably the two ‘Frame’ ‘SubFrames’ are the left & right channels.
[18F452 RAM] 1536 Bytes x 8 = 12,288 Bits
So, when stripping the data down - There is enough space in 18F452 RAM (1536 Byte) to store exactly 2 Blocks worth of data. Whilst ignoring the other (allbeit important) other non audio bits.
[ AllData OneBlock] 32bit x 2 x 192 = 12,288 bits - (All Data Total Per a Block)
The datarate of SPDIF at 48kHz is 3.072 Mbit/s, this means that you have only 3 PIC instructions per bit - doesn’t look feasible.
Now assuming that 3 instructions can be carried out during the period of one Bit of a SPDIF DataBlock arriving - then at 12,288 bits per a DataBlock - this would leave the oppertunity to execute 36,684 instructions in this timeframe ! + theres enough ram to do some juggling with..
The real problem arrives when it comes to simaltainiously sending & Receiving that data - maybe two pics could resolve this by one dealing with stripping the data appart, whilst the other picks & repeats the raw data packets to create the desired result.
With the ammount of ram available on the 18f452 - this would allow for a 1 Block lag - with higher memory capacity pics from this family; maybe upto 3-6 Block lag could be used to borrow back time to do more instructions.
- Any Further Thoughts on this matter anyone ?
