Generating ringtone melodies through the Calypso DSP====================================================The DSP in the Calypso and other GSM DBB chips from TI includes a built-incapability for generating ringtone melodies to be played through a loudspeakerdriven by the ABB, without using an external melody generator chip. Morespecifically, the DSP in question supports two flavors of internal melodygeneration, called Melody E1 and Melody E2 - although it is unclear whetherMelody E2 is implemented in the DSP ROM or in the DSP code patches downloadedby TI's firmwares.The Melody E1 mechanism produces simple polyphonic melodies with up to 8simultaneous notes; these melodies consist of simple sine waves generated bythe DSP as commanded by the bits read from the melody file as explained below.Melody E2 is a more complex mechanism for producing melodies (also polyphonicwith up to 8 simultaneous notes) using the sounds of specific instruments,rather than simple sine waves, but we currently lack the bits required in orderto understand or exercise it, hence our current focus is on the simpler MelodyE1 mechanism.How these melodies are played=============================TI's RiViera Audio Service firmware component provides a front-end to thevarious audio services provided by the lower-level DSP+L1 combo. In the caseof Melody E1 and Melody E2 features, the combination of the DSP and TI'sARM-side L1 code effectively defines the format of the melody bits themselves,but the RiViera Audio Service takes care of reading these bits from FFS andfeeding them to L1.To play an E1 format melody, the UI code needs to call audio_melody_E1_start();one of the arguments to this API function is the FFS absolute pathname of themelody file. The API function will open this file and pass the open filedescriptor along with other parameters in the message posted to the Audio task;the latter task will prefetch the first buffer-full of melody bits from the fileand then post an MMI_MELODY0_START_REQ message to the L1A task. The Melody E1handler in L1A will set up some preliminaries and fire up the Melody E1 L1Stask, and the latter will then pass the melody bits to the DSP at appropriatetimes.Melody E1 file format=====================We have found a rather terse and not particularly thorough description of theMelody E1 bit format on pages 160 through 163 of this PDF document:https://www.freecalypso.org/LoCosto-docs/PSL1DOC/L1/L1M_AS001_1.pdfThis description is not complete enough to enable proper understanding orimplementation, but by combining it with a study of the L1A and L1S code thatreads these bits and passes most of them to the DSP, we have reconstructed asomewhat more complete picture.The format is word-oriented, i.e., the basic unit of data in a Melody E1 fileis the 16-bit word. Most of these words are passed to the DSP for finalinterpretation inside the latter, hence we won't be able to have a 100% certainunderstanding of what happens there unless we can find the source for the DSPROM code or expend a Herculean effort to reverse-engineer it, but some of thewords are interpreted and acted upon by the ARM-side L1 firmware code, which wehave source-reconstructed already. When these words are written in a disk orFFS file, the byte order is little-endian, as it is ARM code that reads these16-bit words from a byte-oriented source.The very first word in a Melody E1 file gives the global list of oscillatorsused by this melody; this word is read by the L1A code before the L1S task isfired up. The presence of this word is not documented at all in the tersedescription given in L1M_AS001_1.pdf, and our attempts at producing our own E1melodies were going nowhere until we discovered that this word is needed throughthe study of our reconstructed TCS211 L1 code. This initial word correspondsto the osc-set line in our ASCII format.After the initial word giving the global oscillator set, the melody fileconsists of what we shall call time blocks. Each time block begins with a timedescriptor word which is interpreted and acted upon by ARM L1S code, followedby 0 to 8 oscillator descriptors which are loaded into DSP API words. Thesewords are described in TI's document, so we are just going to supplement thatdescription wherever we have discovered something to the contrary.The lower byte of the time descriptor word tells the L1S task how long it shouldwait before loading the following oscillator descriptors into the DSP. Itappears that TI's intent was for this time value to be measured in 20 ms audioframes, but what the ARM L1S code actually does is multiply the given time valueby 4 and use the result as the number of TDMA frames to count - the L1S codeexecutes on every TDMA frame. 13 TDMA frames equal 60 ms, thus 4 TDMA framesdo not exactly equal 20 ms, but come a little short. It is not clear whetherthe melody files generated by TI and/or their customers account for thisdiscrepancy or not. In any case, the time value given in the file needs to benon-zero - putting a zero in there will cause the L1S counter to be set to 65535TDMA frames (a 16-bit unsigned counter loaded with 0 and decremented by one),which is probably not what you want.The upper byte of the time descriptor word is a bit mask indicating which DSPoscillators are to be loaded at this time. This bit mask byte can be zero, inwhich case the time block consists of just the time descriptor word. However,the L1S code does absolutely nothing to the DSP in this case, hence an empty(no oscillators) time block is indistinguishable from adding the time to thefollowing non-empty block. But the largest time value that can fit in the byteis 255, hence empty time blocks can be used to produce larger time deltas.A time descriptor with zeros in both upper and lower bytes indicates the end ofthe melody; this terminator is required.Now we come to the interesting part: the oscillator descriptors that are loadedinto the DSP to cause the actual melody generation to occur. The DSP's NDB APIpage contains 4 words for each of the 8 oscillators, and these NDB API words arewhere the oscillator descriptor words from the melody file ultimately go.Please refer to the description of the ml_load1 and ml_load2 bits on page 162of TI's L1M_AS001_1.pdf document. Now here is what the L1S code actually does:first it loads 2 words from the file buffer into the DSP's NDB page - yes,directly into there. Then it does the following logic (code simplified fromthe actual into more readable pseudocode): load_size = 0; if (word1 & ml_load1) load_size++; if (word1 & ml_load2) load_size++; if (load_size) load load_size words at word2 address in the DSP's NDB pageThis logic is peculiar: what happens if ml_load2 is set but not ml_load1? Theresult will be that the word meant to be word3 (the envelope word) will getloaded into the word2 location in the DSP's NDB page. Unless the DSP actuallychecks the ml_load bits and expects the envelope word in the word2 location inthis case, which I highly doubt, this L1S behaviour looks like a bug to me - sodon't use the word3 present but not word2 combination in your melodies.It appears that these ml_load1 and ml_load2 bits are only checked by the L1Scode and ignored by the DSP. I say so because when I tried creating a melodyin which word2 and word3 were always omitted, the result was bogus. It appearsthat the first time a given oscillator is loaded, all 4 words must always begiven, otherwise the DSP will act on whatever garbage happens to be in thoseNDB API words from before. When the same oscillator is subsequently reloaded,omitting word2 and/or word3 will cause that word's previous value to be reused.A few notes regarding some bits in word0:ml_synchro (bit 0): the L1S code ORs a 1 into this bit in the NDB API wordafter it has loaded all of the words. It thus seems more correct to me to puta 0 in this bit in the files, so that the DSP sees the new descriptor when itis complete - but of course we can never know for sure without knowing whatactually happens inside the DSP.ml_directF: both common sense and the TSM30 source (which uses the Melody E1feature of the DSP in that old Calypso version) suggest that ml_directF isbit 1, ml_square1 is bit 2 and ml_square2 is bit 3, i.e., it appears that thetable on page 161 of L1M_AS001_1.pdf is wrong in this regard. Also note theorder in which the fields are described on page 162 of the same PDF document.This is where our current knowledge ends. Until we either obtain a copy of thesource for the DSP ROM or painstakingly reverse-engineer it, all we can do islook at the few existing examples of E1-format melodies we can find (see below)and experiment with putting different values in the various fields based on thedescription in the L1M_AS001_1.pdf document.Examples of E1-format melodies==============================We've been very fortunate to discover that the legendary TSM30 phone appears tohave used the Melody E1 feature, and that there are a bunch of E1-formatmelodies embedded in the famous TSM30 source from HispaPhreak. I have extractedthese melodies, played them through the earpiece speaker on a Pirelli DP-L10phone running FreeCalypso Magnetite (our own FCDEV3B with a loudspeaker that wecan actually use has not been built yet as of this writing), and found some ofthem to be quite pleasant-sounding. These extracted TSM30 melodies can be foundhere:ftp://ftp.freecalypso.org/pub/GSM/ringtone/tsm30-melody-e1.tar.gzI also found a couple of melodies in our TCS211 reference semi-src underchipsetsw/services/Audio/tests; these two melodies illustrate how one can loadword2 and word3 the first time and then omit them afterward when reloading thesame oscillator. (All of the TSM30 melodies always load all 4 words in everyoscillator descriptor.)Our own ASCII format for E1 melodies====================================In this FreeCalypso host tools package we have a utility for decoding existingMelody E1 binary bits into an amenable-to-study ASCII format, as well as autility for generating new E1-format binary melodies from an ASCII text sourcein the same format. The ASCII format is of our own invention, and consists ofnumeric fields which map directly to the various bit fields in the DSP+fw'sbinary format.Our ASCII format for E1 melodies consists of 3 parts: an osc-set global headerline, a sequence of time blocks, and an end line. The noteworthy aspects are:* Each time block is given as a time line followed by 0 or more osc lines. This lines must follow in direct succession without intervening blank or comment lines, and each time block must end with a blank line.* The end marker line is mandatory; having the ASCII file just end without it is an error.Please see the source code for fc-e1decode and fc-e1gen for the rest.Some words regarding Melody E2==============================E1-format melodies are self-contained: if you have a valid binary melody filein E1 format from whatever source, you can play it through the DSP of anyCalypso device that runs our TCS211-based Magnetite firmware. But it is not sosimple with Melody E2. In order to play a melody in E2 format, one needs notonly the melody file itself, but also the set of *.mwa (instrument wave) filescorresponding to the set of instruments used by that melody. It appears thatthe melody group at TI had produced as many as 48 different instrument wavetables: see the list in the non-production #if (AUDIO_SIMULATION) || (AUDIO_L1_STANDALONE)section of the Cust_audio_melody_E2_load_instrument() function in l1audio_cust.cin both TSM30 and LoCosto/Peek sources. (The LoCosto version lists 48instruments whereas the much earlier TSM30 version lists only 40 of them, thusthe list must have been added to over the course of TI history.) A given E2melody selects a subset of 1 to 8 instruments out of the larger set to be usedin that melody, and these selected instrument waves are loaded into the DSP'sAPI RAM before the actual play of the melody itself.Unfortunately all we have are the *.mwa file _names_ for the 48 Melody E2instruments that apparently existed at TI once upon a time, but not any of theactual bits. The TSM30 source uses only Melody E1, not E2, thus we do notcurrently have any source from which we can take any E2-format melody examplesor E2 instrument wave tables for TI's DSP. We also don't have any documentationfor any of these bits, and analysis of the Melody E2 code in L1 shows that it issignificantly different from E1. The code in TCS211 L1 that reads Melody E2file bits is not of much help for making our own E2 melodies, as all of the realmagic happens in the DSP, not on the ARM side.Thus our FreeCalypso hardware+firmware combination is capable of playing both E1and E2 melodies, but we won't be able to exercise the latter capability untiland unless someone finds a surviving copy of some existing E2 melodies alongwith the *.mwa instrument wave files they require, whether it is the sameinstrument set as listed in the non-production section of l1audio_cust.c or adifferent one. But if someone does obtain a set of such melody bit files, ourFreeCalypso devices running FreeCalypso firmware are ready to play them.