This is great that you took the time to write this up. Did you also find a page for this on the wiki so we can refer to it and refine it as needed?<br>
<br>Your document would be fit some of the needs for a design document and I would encourage developers to comment and contribute and come to agreement. <br><br>I am working on requirements specifications that represent the Use Case or the student view of the visible aspects of the feature. This provides high level guidelines for development as well as good information for those
who want to test the feature.<br>
<br>Here are a couple of ideas for requirements from your notes: <br>
<br>* The student should be able to download standard midi files from the internet and play them on the laptop.<br>* Activities should be able to access a local, shared audio sample library.<br><br>The details of how to do that are in your notes. Are there other high level, user-visible requirements that people want to point out related to this topic?
<br><br>[You can see where I am starting to write up requirements here: <a href="http://wiki.laptop.org/go/Requirements">http://wiki.laptop.org/go/Requirements</a><br>comments welcome]<br><br>Thanks,<br>Kim<br><br><br><div>
<span class="gmail_quote">On 7/15/07, <b class="gmail_sendername">Jean Piché</b> <<a href="mailto:email@example.com">firstname.lastname@example.org</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br><br>Hello all,<br><br>After trial-2 madness has passed, we have to make a serious audio<br>decision: we really need a system-wide audio sample library. I<br>suspect many activities that use sounds (including our own) will be
<br>blocked if a decision is not made. Here are some reasons:<br><br>• Presently, activities wanting to share audio resources cannot do so<br>through a shared directory. Containerizing activities may actually<br>agravate that situation but I am presuming this can and will be fixed
<br>regardless. I will enter this on trac. An activity supplying a<br>resource for its own private use when the resource is of general use<br>leads to the wasteful duplication of data.<br><br>• We need a sample bank to play Standad MIDI Files off the internet.
<br>I have a few misgivings about the quality of the music available for<br>download in this format, but the SMF is a very compact and useful<br>music storage technology. I am certain all will agree it should be<br>supported on the machine.
<br><br>• Last and not least: this resource needs to live locally, not on a<br>remote server. In the vast majority of cases, kids will use the<br>resources that are immediately available and that do not require<br>installation. There is no reason an appropriate system-wide resource
<br>cannot be put together for the XO.<br><br>Here is a proposal:<br><br>A default library:<br><br>There are compelling reasons to make the XO audio sample bank conform<br>to the General MIDI spec ( <a href="http://en.wikipedia.org/wiki/">
http://en.wikipedia.org/wiki/</a><br>General_Midi ). The specification contains 127 sounds plus a number<br>of drum/percussion sounds for a total of roughly 180 individual<br>sounds, many of them quite short. GM is biased towards western
<br>instruments but it provides everything to correctly play midifiles<br>off the internet. A GM sample bank could be put together for the XO<br>in a relatively modest space leaving room for a number of other<br>sounds needed by individual activities such as TamTam, eToys or other
<br>Csound-based activities.<br><br>Allocation on disk<br><br>A figure of 25MB was discussed at OLPC headquarters last year as a<br>disk allotment for sound file resources. I am assuming this is still<br>the case. The standard GM1 set can take a lot, not so much or really
<br>little disk space depending on how it is planned. I propose that the<br>set be given 10Mb of the availbale space. The rest can be made<br>available to activities needing special sounds. TamTam, for<br>instance, would use many sounds from the GM1 set and many custom sounds.
<br><br>Location and priviledges:<br><br>The audio sample bank should be located in the system tree (/usr/<br>share/sounds ?) where it is readily readable by any activity. A<br>policy is needed for write-access but activities would need the
<br>possibility of copying audio resources in this location at install<br>time up to a limit of 25MB. To take the example of TamTam again, any<br>special sounds needed by TamTam wouls be copied into the designated<br>location at install time. The location would not be writable by
<br>individual users. If kids wish to use their own sounds, these would<br>go into their home directory and activities would have to provide<br>ways of integrating those sounds.<br><br>Sampling rate and format:<br><br>Sampling rate has a major impact on quantity of storage required and
<br>audio quality. There is also an impact on performance. A faster<br>sampling rate has a huge impact on performance. Here is a comparison<br>of sr vs length for 25MB storage of 16bit linear PCM monophonic audio<br>files:
<br><br>sr duration<br>32kHz = 390 seconds<br>22.05kHz = 566 seconds<br>16kHz = 781 seconds<br><br>Consider that the small speakers on the XO are not capable of
<br>rendering anything above a 22kHz sr. On the other hand, earpods may<br>be available giving a vastly improved bandwidth. We shoudl also<br>consider the possibility of connecting the audio output of the XO to<br>external sound systems. Barry suggested that a 32kHz sr is desirable
<br>to cover higher audio quality applications and I would agree with<br>that. Even at 32k, we have enough space for a good set of sounds in<br>addition to the GM1 set. It is also easy to pull down from 32k to re-<br>sample at 16k and 8k, so activities can compensate for performance
<br>loss at higher sr. The proposed format for individual sounds is:<br>16bit linear PCM single channel @ 32KHz.<br><br>Keep in mind that this concerns audio samples only, not audio<br>soundfiles in general. Playing mp3 and wave files is an entirely
<br>different problem which is not concerned with sampling rate issues.<br><br><br>Sound names:<br><br>The GM1 sample set proposes standard names for sounds along with<br>their MIDI Program Change number from 0 to 127: <a href="http://www.midi.org/">
http://www.midi.org/</a><br>about-midi/gm/gm1sound.shtml . I propose that the sounds simply be<br>stored under these names in WAV or AIFF format with, possibly, a<br>number at the end of the name. Any other slots above the GM set
<br>would start numbering from, say, 256 with the name of the sound file<br>determined by the activity that puts it in the bank there.<br><br>Availability and Licencing:<br><br>A good sample set is not trivial to put together. The problem of
<br>licencing is also specially thorny in our case. Some of the public<br>domain sounds used in TamTam may have slight restrictions and we will<br>need to adress this before FRS. Whatever the situation and if<br>resources are not readily available to develop a sampel set of our
<br>own, I strongly suggest that OLPC start looking at companies that<br>would be wiling to licence one of their existing sample sets. Rick<br>Boulanger did say last month that negociations were taking place with<br>M-Audio to adapt one of their sample libraries. Are there
<br>developments in that direction? I would hazard that OLPC will not<br>have the choice but negociate a deal with an existing sample company<br>or, alternatively, record its own bank. GPL sounds do exist out there<br>but the quality is spotty and not all categories of sounds are
<br>readily available.<br><br><br>Comments sought and welcome!<br><br><br>Jean Piché<br>TamTam<br><br><br>_______________________________________________<br>Devel mailing list<br><a href="mailto:Devel@lists.laptop.org">Devel@lists.laptop.org