Siryn is an optimised version of the Siren 14 decoder from Polycom. Siren 14 is a mono audio compression standard, with "near CD quality" (similar to low bitrate MP3), that takes a fraction of the CPU for encode or decode. Other benefits of this excellent standard are that both encoder and decoder are tiny (both test applications are less than 30K) and that encode takes only a small amount of time longer than decode.
Like MP3 it requires a license from the patent holders to use, but unlike MP3 this license can be had for free, with no royalty under very reasonable terms.
Full details of these terms are available on the Polycom website, and you should refer there for full details, but to summarise, you can become a licensee for free and ship Siren14 support within your own application without any royalties as long as:
Those seem like pretty good terms to me, but if you feel unable to sign up to them, they say they will license Siren14 under other terms, but don't expect to get them for free.
On becoming a Siren licensee, Polycom will supply you with their standard Siren 14 source code, in both floating and fixed point versions. This code is written for clarity of exposition, not speed. It goes to great length to be very clear on what mathematical operations it is doing (by calling functions for each operation to ensure that rounding/overflow are correctly handled and counted) and as a result runs much more slowly than it needs to.
The Siryn lib is a development of the fixed point version of this library. The unnecessary function calls have been removed, algorithmic improvements have been applied and the speed critical sections have been entirely ARM coded for speed.
The net effect is that both encoder and decoder now run in a fraction of the time they used to. The library will work on any architecture 4 or above ARM (i.e. ARM 7 or later), but has an option to perform slightly better on ARMs with the architecture V5 E extensions. The bit reading sections of the code assume a little endian memory system, but this can probably be changed if required.
I also have a version of the code that works on a Thumb-2 based system (such as the ARM Cortex-M3).
(If you want to use Siren 14 on a non ARM/Thumb platform, contact me anyway, because I can probably produce a non-ARM specific version with most of the algorithmic optimisations in without much effort.)
The API to the library is slightly changed (simplified) in an effort to reduce the amount of memory allocation/stack usage.
When I became a Polycom Siren licensee, I contacted them to say I was interested in developing an optimised ARM version of the library and then licensing it to other people who had obtained a license from Polycom. They informally informed me that this was fine. As long as you have a license to use Siren 14 from Polycom (be it the free license, or some other one), I am free to license the Siryn implementation to you. I cannot release you from any of the terms of your license - you are still responsible for obeying all the conditions placed upon you by it.
So, assuming you have a license from Polycom, under what terms will I release Siryn to you?
Most simply, I will license Siryn to anyone who pays me a suitable fee. Contact me and we can discuss what fee is appropriate for your desired usage.
Alternatively, I'll license it for free under a home brew license of my own. The license terms are described below. I think they're pretty clear, but then IANAL, so if you want them clarified etc, feel free to rent me a lawyer for the afternoon.
Firstly, by "free" software I mean software that you do not derive any kind of revenue from. Shareware isn't free. Software that generates advertising revenue isn't free. Software bundled with other software/hardware that has to be paid for and can't be freely obtained elsewhere isn't free.
Free software does NOT need to give source away, but of course it can if it wants to.
Given this definition, if you want to use Siryn as part of a free piece of software, please do. Obviously, because of the licensing from Polycom, I believe that the source for Siryn can't be distributed freely. If your reading of the license doesn't agree with mine, please contact me and we can discuss it.
If you want to use Siryn (or a derivative of it) in any other type of system (be it software/hardware etc), then you need to contact me first.
I'm not looking to make my fortune here; Shareware programs with a reasonable fee, will almost certainly get permission to use the library as if they were 'free' code.
On the other hand, if someone wants to put Siryn into a piece of hardware or commercial software, I'd kinda like to make something for the time and effort I've put in.
You'd probably like some timings, to show how much better Siryn is than all the other alternatives, right?
My test and timing process is as follows:
Extract "Don't fear the Reaper" by the Blue Oyster Cult from CD (3 minutes, 49 seconds). Resample it twice to give raw PCM mono versions at 16kHz and 32kHz. Encode these files using the Siryn example apps at each possible setting (see the table below).
My decode test app then loads each of these encoded files into memory in turn and times the memory->memory decode of each. Results are as follows:
Sample Rate | Bandwidth | Bitrate | Decode Time | CPU requirement |
---|---|---|---|---|
16000 | 7000 | 16000 | 1.954s | 3.5MHz |
16000 | 7000 | 24000 | 2.035s | 3.7MHz |
32000 | 14000 | 24000 | 3.602s | 6.5MHz |
32000 | 14000 | 32000 | 3.783s | 6.9MHz |
32000 | 14000 | 48000 | 4.061s | 7.4MHz |
My encode test app works similarly; it loads each of the raw files into memory in turn and times the memory->memory encode of each. Results are as follows:
Sample Rate | Bandwidth | Bitrate | Encode Time | CPU requirement |
---|---|---|---|---|
16000 | 7000 | 16000 | 2.942s | 5.3MHz |
16000 | 7000 | 24000 | 3.209s | 5.8MHz |
32000 | 14000 | 24000 | 4.632s | 8.4MHz |
32000 | 14000 | 32000 | 5.069s | 9.2MHz |
32000 | 14000 | 48000 | 5.667s | 10.2MHz |
These timings are performed using an iMate Jam, a WinCE phone with a 416MHz XScale PXA272.
The decoder is pretty thoroughly optimised. There are some areas of the encoder that may possibly benefit from ARM coding, but nothing thats going to radically improve its speed (the best we could hope for is that encode and decode should take the same time).
I am reluctant to give exact comparisons of these times to the reference decoder/encoders, as they are so emphatically written for clarity rather than speed, and so are almost certainly not going to be used without optimisations applied - but roughly I'd expect at least a 10 times speedup with Siryn, probably much more.
I warrant absolutely nothing about Siryn. The Tremor lib says the following and it sounds like the kind of thing I should be saying here too:
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
Related Pages: | |||
---|---|---|---|
Siryn | Tremolo | Theorarm | YUV 2 RGB |