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: "ext Marcel Holtmann" <marcel@holtmann.org>,
	"ext Brad Midgley" <bmidgley@gmail.com>,
	linux-bluetooth@vger.kernel.org
Subject: Re: SBC big endian issues?
Date: Mon, 19 Jan 2009 13:26:07 +0200	[thread overview]
Message-ID: <200901191326.07133.siarhei.siamashka@nokia.com> (raw)
In-Reply-To: <200901172010.05061.siarhei.siamashka@nokia.com>

[-- Attachment #1: Type: text/plain, Size: 1975 bytes --]

On Saturday 17 January 2009 20:10:04 ext Siarhei Siamashka wrote:
> On Saturday 17 January 2009 00:02:09 ext Luiz Augusto von Dentz wrote:
> > Hi Siarhei,
> >
> > It seems gstreamer does have G_BYTE_ORDER, so you probably don't need
> > those #ifdef. I also notice some unnecessary white spaces in the of a
> > line.
>
> Hi,
>
> I did not verify that patch thoroughly (I only checked that it compiles)
> and also seems like I somehow forgot to pass it through 'checkpatch.pl'.
> Thanks for a good catch.
>
> Regarding G_BYTE_ORDER, you are probably right.  I'm not very familiar with
> gstreamer yet, so somebody else could probably fix this stuff much faster
> than me.
>
> In any case, it probably makes sense to relay all the endian conversion
> related things to gstreamer and ALSA, and use only native byte order in
> SBC. This will simplify the code a bit and will make optimizing it easier.
>
> I'm quite worried about big endian systems, but I have plans to buy a PS3
> home in about a month timeframe unless something extraordinary happens  :)

OK, here is an updated patch.

Now I also tested GStreamer plugin on qemu mips big endian image. It works
fine with this change. Having native byte order and not strictly little endian
is a good idea because all the other gstreamer elements (vorbisdec,
flacdec, ...) produce output in native byte order. Unless sbcenc uses native
byte order on this big endian system, audioconvert element is needed to be
added to gstreamer pipeline and it most likely introduces some extra overhead.

I did not check ALSA part and probably can't even do this with qemu, but
removing _LE suffix should also do the job there (according to ALSA
documentation).

Also an interesting observation is that gstreamer is very slow. Using
gst-launch to encode audio file to SBC is something like 1.5 times slower
than sbcenc utility when benchmarked on x86 system. I wonder if
something could be done about this.


Best regards,
Siarhei Siamashka

[-- Attachment #2: 0001-Use-native-byte-order-for-audio-in-GStreamer-and-ALS.patch --]
[-- Type: text/x-diff, Size: 2119 bytes --]

>From f9afd1641cb22ed93b9f0d0992e9a78810ff8159 Mon Sep 17 00:00:00 2001
From: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Date: Mon, 19 Jan 2009 10:26:28 +0200
Subject: [PATCH] Use native byte order for audio in GStreamer and ALSA plugins

This fixes endianness inconsistency between default SBC
configuration and GStreamer/ALSA.
---
 audio/gstsbcdec.c     |    2 +-
 audio/gstsbcenc.c     |    2 +-
 audio/pcm_bluetooth.c |    4 ++--
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/audio/gstsbcdec.c b/audio/gstsbcdec.c
index fedc129..00af4fc 100644
--- a/audio/gstsbcdec.c
+++ b/audio/gstsbcdec.c
@@ -50,7 +50,7 @@ static GstStaticPadTemplate sbc_dec_src_factory =
 		GST_STATIC_CAPS("audio/x-raw-int, "
 				"rate = (int) { 16000, 32000, 44100, 48000 }, "
 				"channels = (int) [ 1, 2 ], "
-				"endianness = (int) LITTLE_ENDIAN, "
+				"endianness = (int) BYTE_ORDER, "
 				"signed = (boolean) true, "
 				"width = (int) 16, "
 				"depth = (int) 16"));
diff --git a/audio/gstsbcenc.c b/audio/gstsbcenc.c
index 3ecaacf..789bf78 100644
--- a/audio/gstsbcenc.c
+++ b/audio/gstsbcenc.c
@@ -147,7 +147,7 @@ static GstStaticPadTemplate sbc_enc_sink_factory =
 		GST_STATIC_CAPS("audio/x-raw-int, "
 				"rate = (int) { 16000, 32000, 44100, 48000 }, "
 				"channels = (int) [ 1, 2 ], "
-				"endianness = (int) LITTLE_ENDIAN, "
+				"endianness = (int) BYTE_ORDER, "
 				"signed = (boolean) true, "
 				"width = (int) 16, "
 				"depth = (int) 16"));
diff --git a/audio/pcm_bluetooth.c b/audio/pcm_bluetooth.c
index bf24206..5dfd778 100644
--- a/audio/pcm_bluetooth.c
+++ b/audio/pcm_bluetooth.c
@@ -1182,7 +1182,7 @@ static int bluetooth_hsp_hw_constraint(snd_pcm_ioplug_t *io)
 		SND_PCM_ACCESS_MMAP_INTERLEAVED
 	};
 	unsigned int format_list[] = {
-		SND_PCM_FORMAT_S16_LE
+		SND_PCM_FORMAT_S16
 	};
 	int err;
 
@@ -1237,7 +1237,7 @@ static int bluetooth_a2dp_hw_constraint(snd_pcm_ioplug_t *io)
 		SND_PCM_ACCESS_MMAP_INTERLEAVED
 	};
 	unsigned int format_list[] = {
-		SND_PCM_FORMAT_S16_LE
+		SND_PCM_FORMAT_S16
 	};
 	unsigned int rate_list[4];
 	unsigned int rate_count;
-- 
1.5.6.5


  reply	other threads:[~2009-01-19 11:26 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-05  8:15 SBC big endian issues? Siarhei Siamashka
2009-01-05 15:36 ` Brad Midgley
2009-01-05 15:55   ` Siarhei Siamashka
2009-01-05 16:25     ` Brad Midgley
2009-01-05 16:29       ` Brad Midgley
2009-01-05 18:19       ` Siarhei Siamashka
2009-01-05 19:26         ` Brad Midgley
2009-01-07 12:40           ` Siarhei Siamashka
2009-01-07 13:43             ` Marcel Holtmann
2009-01-16 17:23               ` Siarhei Siamashka
2009-01-16 22:02                 ` Luiz Augusto von Dentz
2009-01-17 18:10                   ` Siarhei Siamashka
2009-01-19 11:26                     ` Siarhei Siamashka [this message]
2009-01-19 12:05                       ` Marcel Holtmann
2009-01-20  6:22                         ` [Patch] SAP client plugin framework Liu, Raymond
2009-01-22  5:05                           ` Liu, Raymond
2009-01-19 15:02                       ` SBC big endian issues? Brad Midgley
2009-01-20 10:20                         ` Siarhei Siamashka
2009-01-20 11: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=200901191326.07133.siarhei.siamashka@nokia.com \
    --to=siarhei.siamashka@nokia.com \
    --cc=bmidgley@gmail.com \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=luiz.dentz@gmail.com \
    --cc=marcel@holtmann.org \
    /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