On Sun, Jun 08, 2008 at 01:01:57AM +0100, Simon Pickering wrote:
> Other than that, I'm hopeful it should just drop in to replace the
> contents of the sbc directory in Bluez-utils and compile and work. I
> just tried to cross-compile Bluez-utils, and other than the lack of
> Flex (which is a
> I've re-written the original thread-based (async) code today and it's
> now synchronous - a call is made to sbc_encode() on the ARM and it's
> passed through to the DSP and the work is done and the data passed back.
>
> This should all fit in without any changes to the code which calls the
> sbc
>>> It would be easier to plug your work into everything else if you wrote
>>> it up as a patch to the regular sbc.c so it transparently chooses the
>>> soft or dsp codec at runtime. It would work with the alsa plugin, gst,
>>> and eventually pulse without extra work.
>>>
>>> Marcel will have to w
On Sat, Jun 7, 2008 at 12:17 AM, Simon Pickering
<[EMAIL PROTECTED]> wrote:
> Hi Chaps,
>
>> I have been thinking more about this and I think another approach
>> could be considered.
>>
>> It would be easier to plug your work into everything else if you wrote
>> it up as a patch to the regular sbc.
> I only say stepping around gstreamer since the gst way would be to
> make one gst plugin for soft and one for dsp codec and let gst choose
> one when building a pipeline. ie, they're prepared for multiple
> implementations of a given codec.
Ah, ok, I'm with you now.
Well as you said before, l
Simon
I only say stepping around gstreamer since the gst way would be to
make one gst plugin for soft and one for dsp codec and let gst choose
one when building a pipeline. ie, they're prepared for multiple
implementations of a given codec.
--
Brad
___
Hi Chaps,
> I have been thinking more about this and I think another approach
> could be considered.
>
> It would be easier to plug your work into everything else if you wrote
> it up as a patch to the regular sbc.c so it transparently chooses the
> soft or dsp codec at runtime. It would work with
Simon
I have been thinking more about this and I think another approach
could be considered.
It would be easier to plug your work into everything else if you wrote
it up as a patch to the regular sbc.c so it transparently chooses the
soft or dsp codec at runtime. It would work with the alsa plugi
Simon
> Atm we have to use ALSA to produce A2DP output, is the data sent
> thought here simply piped straight into sbcenc running standalone?
the alsa plugin with most of the bluez logic is a shared object, so
the alsa audio client is effectively transmitting directly to the
headset.
> I'd like
>> Just a quick note to say that the DSP task encodes the test .au file
>> correctly. Still a minor ;) issue that the DSP crashes after the DSP
>> has finished the encoding task (I think this is probably due to a
>> non-existent semaphore being written to, will have to test my theory
>> tomorrow)
Simon
> Just a quick note to say that the DSP task encodes the test .au file
> correctly. Still a minor ;) issue that the DSP crashes
It sounds like an awesome achievement. I'm looking over things now.
If it can be coded generically, it would be nice if the standard bluez
gstreamer plugin could
Hi Simon,
> Just a quick note to say that the DSP task encodes the test .au file
> correctly. Still a minor ;) issue that the DSP crashes after the DSP
> has finished the encoding task (I think this is probably due to a
> non-existent semaphore being written to, will have to test my theory
Hi all,
Just a quick note to say that the DSP task encodes the test .au file
correctly. Still a minor ;) issue that the DSP crashes after the DSP
has finished the encoding task (I think this is probably due to a
non-existent semaphore being written to, will have to test my theory
tomorrow)
13 matches
Mail list logo
