public inbox for linux-bluetooth@vger.kernel.org
 help / color / mirror / Atom feed
From: Siarhei Siamashka <siarhei.siamashka@nokia.com>
To: "ext Luiz Augusto von Dentz" <luiz.dentz@gmail.com>
Cc: linux-bluetooth@vger.kernel.org
Subject: Re: [PATCH] Added possibility to analyze 4 blocks at once in SBC encoder
Date: Fri, 2 Jan 2009 18:51:26 +0200	[thread overview]
Message-ID: <200901021851.27048.siarhei.siamashka@nokia.com> (raw)
In-Reply-To: <2d5a2c100812311304u562e6363wc16f1bdf28ac9552@mail.gmail.com>

On Wednesday 31 December 2008 23:04:20 ext Luiz Augusto von Dentz wrote:
> Hi Siarhei,
>
> > Nevertheless, I think it is time to focus on performance :) The attached
> > patch contains code preparations which are needed for SIMD optimizations
> > for the analysis filter. Also theoretically it should be possible to
> > tweak code to have both 32-bit and 16-bit fixed point analysis filter
> > compiled in and switch between them at runtime (at user's request or
> > semi-intelligently depending on audio bitrate).
>
> Picking a implementation at runtime would be really great,

What I had in mind was that we can have two source files which
include 'sbc_tables.h'. Then compile one of them with
SBC_HIGH_PRECISION macro defined, and the other one
without it. This way we will have two sets of functions, which
can be called via function pointers transparently from the rest
of code, as long as they have the same interface.

Having high precision analysis filter variant may be beneficial for
extremely high bitrates, when we might want to keep as much of
precision as possible. For the normal cases the extra precision is
just excessive.

I also have an idea about improving precision for the case of 16-bit
multiplications only. This would involve only tweaking coefficients in
the tables with no code changes at all. I hope to reduce rounding
errors to the very minimum. Will post about the progress a bit later.

If the precision difference between 16-bit and 32-bit implementations
can be reduced, there will be a bit less reasons to use a slow high
precision version anymore :)

> that is why I suggested using liboil in the other thread.

I don't see much relation with liboil here.

I'm not against liboil in general, but its usefullness for sbc codec just
needs to be proved.

-- 
Best regards,
Siarhei Siamashka

  reply	other threads:[~2009-01-02 16:51 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-31 15:29 [PATCH] Added possibility to analyze 4 blocks at once in SBC encoder Siarhei Siamashka
2008-12-31 21:04 ` Luiz Augusto von Dentz
2009-01-02 16:51   ` Siarhei Siamashka [this message]
2009-01-01  8:54 ` Marcel Holtmann
2009-01-02 16:13   ` Siarhei Siamashka

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200901021851.27048.siarhei.siamashka@nokia.com \
    --to=siarhei.siamashka@nokia.com \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=luiz.dentz@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox