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_*
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.c so it
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 weigh in if it's
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).
snip
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 to
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
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 the
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
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,
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
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
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
12 matches
Mail list logo
