opus - May 2013 - DSPs which are suitable for porting OPUS

Dear Christian van Bijleveld,

You can use any of the below DSPs of Texas Instruments
1.  TMS320C674x - This supports floating point implementation of opus
2.  TMS320C66x - This supports both floating and fixed point implementations
3.  TMS320C64x - This supports only fixed point implementation

Regards,
Mahantesh


On Mon, May 13, 2013 at 10:12 PM, <opus-request at xiph.org> wrote:
> Send opus mailing list submissions to
>         opus at xiph.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         http://lists.xiph.org/mailman/listinfo/opus
> or, via email, send a message with subject or body 'help' to
>         opus-request at xiph.org
>
> You can reach the person managing the list at
>         opus-owner at xiph.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of opus digest..."
>
>
> Today's Topics:
>
>    1. opus_demo produces garbage (Hermann Weber)
>    2. Re: opus_demo produces garbage (Jean-Marc Valin)
>    3. Re: opus_demo produces garbage (Hermann Weber)
>    4. Exact audio position (Hermann Weber)
>    5. Quality difference between opus_demo.exe and opusenc.exe
>       (Hermann Weber)
>    6. OPUS in embedded platform (van Bijleveld Christian (ST-CO/ENG1.3))
>    7. Re: opus file trimming/clipping (Matt Ruck)
>    8. Re: Exact audio position (Ian Malone)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 13 May 2013 07:43:55 +0200
> From: Hermann Weber <hermie.weber at gmx.de>
> Subject: [opus] opus_demo produces garbage
> To: opus at xiph.org
> Message-ID: <51907D9B.50803 at gmx.de>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Hello!
>
> I am running opus_demo.exe with the following cmds:
>
> -e audio 48000 1 16 -cbr m:\test\test1.raw m:\test\test1.opus
>
> When I open the .opus file with a hex editor, I see only
>
>
>
00000001000000007800000001000000007800000001000000007800000001000000007800000001000000007800000001000000007800000001000000007800000001000000007800000001000000007800000001000000007800000001000000007800000001000000007800000001000000007800000001000000007800000001000000007800000001000000007800000001000000007800000001000000007800000001000000
>
> This pattern repeats over and over again.
>
> What might go wrong here?
>
> Greetings,
> Hermann
>
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 13 May 2013 02:04:42 -0400
> From: Jean-Marc Valin <jmvalin at jmvalin.ca>
> Subject: Re: [opus] opus_demo produces garbage
> To: Hermann Weber <hermie.weber at gmx.de>
> Cc: opus at xiph.org
> Message-ID: <5190827A.1090305 at jmvalin.ca>
> Content-Type: text/plain; charset=ISO-8859-1
>
> What you're looking at is the compressed result of trying to encode
your
> file at 16 *bits* per second (0.016 kbit/s).
>
>         Jean-Marc
>
> On 05/13/2013 01:43 AM, Hermann Weber wrote:
> > Hello!
> >
> > I am running opus_demo.exe with the following cmds:
> >
> > -e audio 48000 1 16 -cbr m:\test\test1.raw m:\test\test1.opus
> >
> > When I open the .opus file with a hex editor, I see only
> >
> >
>
00000001000000007800000001000000007800000001000000007800000001000000007800000001000000007800000001000000007800000001000000007800000001000000007800000001000000007800000001000000007800000001000000007800000001000000007800000001000000007800000001000000007800000001000000007800000001000000007800000001000000007800000001000000007800000001000000
> >
> > This pattern repeats over and over again.
> >
> > What might go wrong here?
> >
> > Greetings,
> > Hermann
> >
> > _______________________________________________
> > opus mailing list
> > opus at xiph.org
> > http://lists.xiph.org/mailman/listinfo/opus
> >
>
>
>
> ------------------------------
>
> Message: 3
> Date: Mon, 13 May 2013 08:16:59 +0200
> From: Hermann Weber <hermie.weber at gmx.de>
> Subject: Re: [opus] opus_demo produces garbage
> To: Jean-Marc Valin <jmvalin at jmvalin.ca>
> Cc: opus at xiph.org
> Message-ID: <5190855B.8060304 at gmx.de>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Okay, got it, thanks.
>
> opus_demo.exe solved all my problems, I think.
> Good sample code.
>
> Thanks.
> Hermie
>
> Am 13.05.2013 08:04, schrieb Jean-Marc Valin:
> > What you're looking at is the compressed result of trying to
encode your
> > file at 16 *bits* per second (0.016 kbit/s).
> >
> >       Jean-Marc
> >
> > On 05/13/2013 01:43 AM, Hermann Weber wrote:
> >> Hello!
> >>
> >> I am running opus_demo.exe with the following cmds:
> >>
> >> -e audio 48000 1 16 -cbr m:\test\test1.raw m:\test\test1.opus
> >>
> >> When I open the .opus file with a hex editor, I see only
> >>
> >>
>
00000001000000007800000001000000007800000001000000007800000001000000007800000001000000007800000001000000007800000001000000007800000001000000007800000001000000007800000001000000007800000001000000007800000001000000007800000001000000007800000001000000007800000001000000007800000001000000007800000001000000007800000001000000007800000001000000
> >>
> >> This pattern repeats over and over again.
> >>
> >> What might go wrong here?
> >>
> >> Greetings,
> >> Hermann
> >>
> >> _______________________________________________
> >> opus mailing list
> >> opus at xiph.org
> >> http://lists.xiph.org/mailman/listinfo/opus
> >>
> >
>
>
>
> ------------------------------
>
> Message: 4
> Date: Mon, 13 May 2013 10:45:00 +0200
> From: Hermann Weber <hermie.weber at gmx.de>
> Subject: [opus] Exact audio position
> To: opus at xiph.org
> Message-ID: <5190A80C.6020201 at gmx.de>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Hello!
>
> I need to extract audio data at a certain position in respect to the
> original audio data.
>
> Is the "-cbr" switch meant to ensure that data can be found on a
> specific position?
>
> I want to be able to predict where certain audio can be found in the
> encoded data.
>
> An example:
> If you put 10 apples into a box and then compress the box, you will not
> be able to predict where apple C can be found in the box.
> Perhaps apple B could be compressed more than apple C, and now the
> "position" of apple C is not predictable anymore.
> This is exactely NOT what I want :-)
>
> Greetings,
> Hermann
>
>
> ------------------------------
>
> Message: 5
> Date: Mon, 13 May 2013 13:24:06 +0200
> From: Hermann Weber <hermie.weber at gmx.de>
> Subject: [opus] Quality difference between opus_demo.exe and
>         opusenc.exe
> To: opus at xiph.org
> Message-ID: <5190CD56.80103 at gmx.de>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Hello!
>
> I encoded a voice file (48kHz) with opusbin\opusenc.exe with the
> standard settings and decoded it.
> The output was amazing. I could not hear any loss at all.
>
> Then i encoded the same file with opus_demo.exe and standard settings
> and then decoded it.
> The output had a sizzling noise, even when I used full bandwidth.
>
> I think I have played around with any of the settings in opus_demo.exe,
> but I just can not get these amazing results as with opusbin\opusenc.exe.
>
> What may I have missed?
>
> Thank you.
>
> Hermann
>
>
> ------------------------------
>
> Message: 6
> Date: Mon, 13 May 2013 14:57:55 +0200
> From: "van Bijleveld Christian (ST-CO/ENG1.3)"
>         <Christian.vanBijleveld at nl.bosch.com>
> Subject: [opus] OPUS in embedded platform
> To: "opus at xiph.org" <opus at xiph.org>
> Message-ID:
>         <8E99D2CE27782C4BA15262EE04CE7AA37952CEC3E9 at
SI-MBX18.de.bosch.com>
> Content-Type: text/plain; charset="us-ascii"
>
> Hello,
>
>
> I am interested in porting OPUS to an embedded platform. The idea is that
> the encoder and decoder will run on different processors. In order to
> choose the proper platform, I need an estimate of the resources which are
> needed for OPUS.
>
> I read the following in the OPUS wiki:
>
> "The Opus code base is written in C89 and should run on the vast
majority
> of recent (and not so recent) CPUs. A few of the platforms on which Opus
> has been tested and is known to run include x86, x86-64, ARM, Itanium,
> Blackfin, and SPARC."
> Are there, or is it known, figures regarding the resources needed for OPUS
> to run on an embedded platform such as DSP or microprocessor? If exact
> figures are not available, but if anyone can give an indication about which
> type of platform is required at least, I would appreciate very much. I can
> image that the amount of resources for the encoder and the decoder may be
> different.
>
> Another question: does OPUS need the support  of an Operating System or
> Real Time Kernel (ie; threads,...)?
>
>
> Met vriendelijke groeten | Best Regards,
> Christian van Bijleveld
>
> Bosch Security Systems BV
> Bosch Communications Systems, BL Public Address and Conference Systems
> (ST-CO/ENG1.3)
> P.O. Box 80 002
> 5600 JB  Eindhoven
> The Netherlands
> www.boschsecurity.com<http://www.boschsecurity.com>
> T. +31 (0)40 257 7076
> F. +31 (0)40 257 7091
> christian.vanbijleveld at nl.bosch.com<mailto:
> christian.vanbijleveld at nl.bosch.com>
>
>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
>
http://lists.xiph.org/pipermail/opus/attachments/20130513/1e31aa21/attachment-0001.htm
>
> ------------------------------
>
> Message: 7
> Date: Mon, 13 May 2013 09:17:45 -0400
> From: Matt Ruck <ultymatt at gmail.com>
> Subject: Re: [opus] opus file trimming/clipping
> To: Ralph Giles <giles at thaumas.net>
> Cc: opus <opus at xiph.org>
> Message-ID:
>         <CAPNsZ0wLhOjdZKPakGKqMKRop_=07TnWfKEBzcOk> e8XKJfmNg at
mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Thanks for your responses. I am potentially interested in developing a
> simple tool to trim a section of an Opus file, similar to the functionality
> of vcut or sox. What I would need to know is an estimate of how involved
> (difficulty and time commitment ) it would be for someone like me, with
> very little experience working with audio or programming in C (although I
> am much more comfortable with higher level languages). I have the source
> code for vcut for reference -- assuming that a similar tool for Opus could
> be based on this, could most of this be reused?
>
>
> On Thu, May 9, 2013 at 7:17 PM, Ralph Giles <giles at thaumas.net>
wrote:
>
> > On 13-05-09 2:06 PM, Matt Ruck wrote:
> >
> > > Would trimming in another format like WAV or Ogg using existing
tools,
> > > and then encoding to Opus be a good way accomplish trimming a
sound
> > > track for Opus, and if so, what tools might be best (e.g., vcut
was
> > > previously mentioned)?
> >
> > Trimming WAV and then encoding to Opus would give you equivalent
quality
> > and is something which can be done with existing tools. You can trim a
> > wave file with the command-line sox tool, or e.g. Audacity, a
graphical
> > audio editor.
> >
> > Something like 'sox in.wav trim 12:53.6 30 out.wav' will cut
out 30
> > seconds of audio starting at 12 minutes 53.6 seconds into the file.
> >
> > That said, if you want to try writing a lossless Opus trimmer,
we'd be
> > happy to help. That' something the Ogg Opus draft which hasn't
seen any
> > implementation feedback on.
> >
> >  -r
> >
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
>
http://lists.xiph.org/pipermail/opus/attachments/20130513/7ce5d621/attachment-0001.htm
>
> ------------------------------
>
> Message: 8
> Date: Mon, 13 May 2013 17:42:26 +0100
> From: Ian Malone <ibmalone at gmail.com>
> Subject: Re: [opus] Exact audio position
> To: opus at xiph.org
> Message-ID:
>         <
> CAL3-7MqRv-Ku-uHYTfH0+qt3KZyK3_bP1hHt5mW5O--rCfP_WQ at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> On 13 May 2013 09:45, Hermann Weber <hermie.weber at gmx.de> wrote:
>
> > Hello!
> >
> > I need to extract audio data at a certain position in respect to the
> > original audio data.
> >
> > Is the "-cbr" switch meant to ensure that data can be found
on a
> > specific position?
> >
> > I want to be able to predict where certain audio can be found in the
> > encoded data.
> >
> > An example:
> > If you put 10 apples into a box and then compress the box, you will
not
> > be able to predict where apple C can be found in the box.
> > Perhaps apple B could be compressed more than apple C, and now the
> > "position" of apple C is not predictable anymore.
> > This is exactely NOT what I want :-)
> >
> >
> >
> (Oops, replied off-list by mistake)
>
> The encapsulation records this information, for Opus in Ogg you want
> 'granule position':
> http://tools.ietf.org/html/draft-ietf-codec-oggopus-00#section-4
> https://wiki.xiph.org/GranulePosAndSeeking
>
> I'm less familiar with RTP, but I think the RTP timestamp is probably
the
> equivalent thing:
> http://tools.ietf.org/html/draft-spittka-payload-rtp-opus-03
>
>
>
> --
> imalone
> http://ibmalone.blogspot.co.uk
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
>
http://lists.xiph.org/pipermail/opus/attachments/20130513/4a30dc2e/attachment.htm
>
> ------------------------------
>
> _______________________________________________
> opus mailing list
> opus at xiph.org
> http://lists.xiph.org/mailman/listinfo/opus
>
>
> End of opus Digest, Vol 52, Issue 12
> ************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.xiph.org/pipermail/opus/attachments/20130514/00f81baf/attachment-0001.htm