Artesia Posted February 15, 2005 Report Share Posted February 15, 2005 Hi,I am looking into the possability of making a PIC powered SPDIF Signal 'processor'. The idea of this device; is to allow the adjustment of the signal sample frequency & bit depth in real time to give a sound to the processed signal much like early samplers. Regarding the PIC18F452 - would it have sufficient data transfer rate to Receive a 16bit 44/48khz stereo SPDIF signal & then relay it on again ?I could probably figure this if i did the math - though someone here may well know the answer to this already.Further on this point, assuming that the pic can handle realying this information - i'd assume that it was within it's capability to then pull appart this data & then do a simple bit of math to then allow downsampling the frequency sample rate ?If this is looks feasable (even if it means using a more powerful pic) i'll have a go at this sometime - should be a good way to get to grips with pic programming from scratch. Also - got afew more ideas on how to process the signal; so this could be a really fun project to toy with ! :) Quote Link to comment Share on other sites More sharing options...
TK. Posted February 15, 2005 Report Share Posted February 15, 2005 Hi Artesia,this is perverse, isn't it? Reducing the bitrate on a interface which was invented for best digital quality? ;-) (btw.: I would use a VST for such a simple job)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.More infos here http://www.epanorama.net/documents/audio/spdif.htmlBest Regards, Thorsten. Quote Link to comment Share on other sites More sharing options...
Artesia Posted February 16, 2005 Author Report Share Posted February 16, 2005 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 BitsSo, 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 ? :) Quote Link to comment Share on other sites More sharing options...
TK. Posted February 16, 2005 Report Share Posted February 16, 2005 Hi,it's a typical job for a FPGA (I'm writing this since I'm currently playing with a Xilinx Spartan3 development board ;-)This means that you have to learn VHDL. Fortunately the SPDIF core doesn't need to be reinvented, it's already available at this site: http://www.opencores.com/projects.cgi/web/spdif_interface/overviewBest Regards, Thorsten. Quote Link to comment Share on other sites More sharing options...
Artesia Posted February 16, 2005 Author Report Share Posted February 16, 2005 fair comment :)Looking into that - however the website is under too high a load this afternoon to churn out the downloadable bits :/Been thinking some more about how this might be implimentable - and it occured that if a datatable containing say 192 slots for subframes). Then a quite flexable stucture for manipulating the packet order in any way desired - could be acheived by having a outgoing 'subframe address read table' with 192 freely editable address slots. An example of how this might work with 16 slots for some examples:(some of these examples would require streching over subframes to work as intended)(SubFrames stored as - F01 to F16 )(F00 = Blank SubFrame)Un-modifyed 'playback':Read Line: 'play' Subframe no:001 F01002 F02003 F03004 F04005 F05006 F06007 F07008 F08009 F09010 F10011 F11012 F12013 F13014 F14015 F15016 F16an example of what a downsamplng might look like with a 16 subframe table:Read Line: 'play' Subframe no:001 F01002 F01003 F01004 F01005 F05006 F05007 F05008 F05009 F09010 F09011 F09012 F09013 F13014 F13015 F13016 F13Then onto some other uses...Playing time interval sections backwards:Read Line: 'play' Subframe no:001 F16002 F15003 F14004 F13005 F12006 F11007 F10008 F09009 F08010 F07011 F06012 F05013 F04014 F03015 F02016 F01 'random' garbling :(This implimentation would probably give a DAC a heart attack ;)Read Line: 'play' Subframe no:001 F08002 F11003 F02004 F15005 F14006 F10007 F01008 F06009 F09010 F03011 F05012 F12013 F04014 F16015 F13016 F07 Gapper effect :Read Line: 'play' Subframe no:001 F01002 F02003 F03004 F04005 F00006 F00007 F00008 F00009 F09010 F10011 F11012 F12013 F00014 F00015 F00016 F00 Seudo Jitter :Read Line: 'play' Subframe no:001 F01002 F02003 F03004 F04005 F01006 F02007 F07008 F08009 F09010 F10011 F07012 F08013 F13014 F14015 F15016 F16 Seudo Stutter :Read Line: 'play' Subframe no:001 F01002 F02003 F03004 F04005 F01006 F02007 F03008 F04009 F09010 F10011 F11012 F12013 F09014 F10015 F11016 F12Playing a time interval section in a 'cyclic' loop :Read Line: 'play' Subframe no:001 F01002 F02003 F03004 F04005 F05006 F06007 F07008 F08009 F08010 F07011 F06012 F05013 F04014 F03015 F02016 F01Playing time interval sections in a 'cyclic' loop :Read Line: 'play' Subframe no:001 F01002 F03003 F06004 F08005 F10006 F12007 F14008 F16009 F16010 F14011 F12012 F10013 F08014 F06015 F03016 F01Shuffle':Read Line: 'play' Subframe no:001 F01002 F02003 F13004 F14005 F05006 F06007 F09008 F10009 F07010 F08011 F11012 F12013 F03014 F04015 F15016 F16hmm - crazy im sure ...But playing with editable lookup tables could provide a whole lot of fun methinks :)even without modifying the packet contents :] Quote Link to comment Share on other sites More sharing options...
TK. Posted February 17, 2005 Report Share Posted February 17, 2005 You know what the word "evaluation" means? ;-)Sooner or later I will try out the SPDIF modules on my FPGA board, maybe I can tell you thereafter if using a PIC for processing is feasible or notBest Regards, Thorsten. Quote Link to comment Share on other sites More sharing options...
pilo Posted February 17, 2005 Report Share Posted February 17, 2005 hihiinteresting topic :DI'd love to play with FPGA, but don't have money and time now....for that kind of stuff you can also use the small DSP from wavefront semi (old alesis semi), the al1301 (used in Mrs Parker), I think ;) Quote Link to comment Share on other sites More sharing options...
jdutcher Posted February 19, 2005 Report Share Posted February 19, 2005 i'm also quite interested in this project (although i have neither the time nor the skill to help out). please keep us up to date with any findings! Quote Link to comment Share on other sites More sharing options...
Steven_C Posted February 19, 2005 Report Share Posted February 19, 2005 Oh boy! you guys are way beyond the technical depth of dsp and programming that I can understand! (chuckle) I am so surprised that someone wants to go to the trouble to get that 80's sampler sound! Quote Link to comment Share on other sites More sharing options...
moldava Posted February 19, 2005 Report Share Posted February 19, 2005 Wouldn´t that be a task for a dspic? Quote Link to comment Share on other sites More sharing options...
Artesia Posted February 20, 2005 Author Report Share Posted February 20, 2005 'Task for a dsp pic...' No and possibly yes...The idea of this is to take truely base level approach to manipulating the audiostream itself. Which isn't something that the run of the mill dsp chip would automatically lend itself to (?). Idea being, to see what wonderful & awful things can be done by mashing up the order of the actual audio packets in realtime (like 'shuffling a pack of cards') - something which i don't think anyone has tried yet...maybe a dsp pic could lend itself to this; But given they seem to be for just running algorythms in a somewhat more restricted framework - maybe not.Thornsten's suggestion for a suitable platform is probably the best line to start trying this one out i guess :) Quote Link to comment Share on other sites More sharing options...
TK. Posted February 20, 2005 Report Share Posted February 20, 2005 It definitely is - just to give you an impression: I've synthesized the spdif_tx unit with some additional circuirity which intitializes the SFRs. The logfile says that ca. 10% of the FPGA is allocated, and that it runs with up to 180 MHz. However, in pratice you've to take care for the tx clock frequency, because it must be divitable by the bitrate, thats currently my blocking point (have to wait for the next Reichelt order to get some parts for a PLL)Best Regards, Thorsten. Quote Link to comment Share on other sites More sharing options...
Artesia Posted February 21, 2005 Author Report Share Posted February 21, 2005 wow tk :) ..that was quick, getting round to that - ur more organised than me ;) :) ..maybe i'll catch up one day :) Quote Link to comment Share on other sites More sharing options...
DrBunsen Posted March 9, 2005 Report Share Posted March 9, 2005 Wouldn´t that be a task for a dspic?Or one of these?http://www.dsperado.com/ Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.