Marcel,
This is the improved version for the sbcdec.c file
which you asked for.
It uses /dev/dsp to play the decoded samples.
The output is pretty well if we incorporate the proper
endian type.
I suggest that you keep it as a separate file incase
someone wants to use the AO Libraries.
Thanks and Regards,
Mayank.
________________________________________________________________________
Yahoo! India Matrimony: Find your life partner online
Go to: http://yahoo.shaadi.com/india-matrimony
Moin,
Am Tue, 3 May 2005 14:20:23 +0100 (BST) schrieb Mayank Batra:
> If the source is sending me sbc file encoded from pcm
> file that was in big endian format, and i have an
> audio device that supports only little-endian format,
> then don't u think that i need to patch the sbc.c file
> when the data field is being filled ?????
No. Inside the SBC stream the endianess is clearly defined (as much
endianess as is left) and as long as the encoder got it right on the
encoding side you will be fine. The endianess that comes out of the
decoder has mostly nothing to do with SBC but only with what the
programmer wants.
So yes, we'd either have to define the interface so that our
decoder/encoder only generates/accepts big or little endian data and it
is up to the application to convert as necessary, or that choice must be
made a runtime configurable parameter of the functions.
--
Henryk Pl?tz
Gr??e aus Berlin
~~~~~~~ Un-CDs, nein danke! http://www.heise.de/ct/cd-register/ ~~~~~~~
~ Help Microsoft fight software piracy: Give Linux to a friend today! ~
Hi Brad,
> > I think that we should move the complete AVDTP handling into a2dp.c and
> > make a2play and a2recv only contain the soundcard/file setup and the
> > main event loop.
>
> agreed. The alsa-lib driver will be event-driven from the start, so I
> will probably want to work on the alsa-lib driver next and once that's
> done, I will have a better idea of how to implement the new model for
> a2dp.c.
maybe I can come up with something. I will see how much free time I get
for working on A2DP.
> my headsets are "in the mail" so I'll be back on it soon. You had done
> some avdtp alsa-lib work I think and if that's a good starting point, I
> would like to work from that. If it's not fleshed out enough, I'll just
> start from your rfcomm alsa-lib code.
A big thing is to get the timing (delays) right and so far I haven't
managed to find a good timing source. The gettimeofday() and RTC is not
really working inside the ALSA plugin. And the ALSA guys are a little
bit silent at the moment :(
> > First question is if we ever wanna allow a2play and a2recv to output SBC
> > files or should it always be a soundcard or a PCM file? If we skip that
> > SBC part, we can integrate the SBC processing directly into the a2dp.c
> > file and hide it. This will makes things a lot easier.
>
> I don't think we will need the sbc streams. I don't think I'd use them
> even for debugging. We will want a way to have the use of /dev/dsp be
> optional (ie optionally read and write audio files) but that shouldn't
> complicate things much.
Fine with me, too.
Regards
Marcel
-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Henryk,
>
> > The output is pretty well if we incorporate the
> proper
> > endian type.
>
> Ahh, so it works for you now? (I was not able to
> test it yet ...)
It is working PERFECTLY alright. There is absolutely
no difference b/w .snd file and .sbc file qualities.
> I hadn't thought of endianess all the way long. I
> was using big endian
> for the .au file input (don't remember why) in the
> encoder and then
> mostly consequently everywhere from there on.
OK, now one question to u and Marcel,
If the source is sending me sbc file encoded from pcm
file that was in big endian format, and i have an
audio device that supports only little-endian format,
then don't u think that i need to patch the sbc.c file
when the data field is being filled ?????
Mayank
________________________________________________________________________
Yahoo! India Matrimony: Find your life partner online
Go to: http://yahoo.shaadi.com/india-matrimony
-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Marcel
> I think that we should move the complete AVDTP handling into a2dp.c and
> make a2play and a2recv only contain the soundcard/file setup and the
> main event loop.
agreed. The alsa-lib driver will be event-driven from the start, so I
will probably want to work on the alsa-lib driver next and once that's
done, I will have a better idea of how to implement the new model for
a2dp.c.
my headsets are "in the mail" so I'll be back on it soon. You had done
some avdtp alsa-lib work I think and if that's a good starting point, I
would like to work from that. If it's not fleshed out enough, I'll just
start from your rfcomm alsa-lib code.
> First question is if we ever wanna allow a2play and a2recv to output SBC
> files or should it always be a soundcard or a PCM file? If we skip that
> SBC part, we can integrate the SBC processing directly into the a2dp.c
> file and hide it. This will makes things a lot easier.
I don't think we will need the sbc streams. I don't think I'd use them
even for debugging. We will want a way to have the use of /dev/dsp be
optional (ie optionally read and write audio files) but that shouldn't
complicate things much.
Brad
-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Brad,
> FYI, I factored out a2dp.h and renamed a2snk to a2recv. I'm going to
> wait to create an a2dp.c with common code since there isn't much currently.
I think that we should move the complete AVDTP handling into a2dp.c and
make a2play and a2recv only contain the soundcard/file setup and the
main event loop.
This sounds a little sketchy, but the current problem with a2play is
that it is not fully event driven. It is more a sequential approach and
we should really change it.
First question is if we ever wanna allow a2play and a2recv to output SBC
files or should it always be a soundcard or a PCM file? If we skip that
SBC part, we can integrate the SBC processing directly into the a2dp.c
file and hide it. This will makes things a lot easier.
Regards
Marcel
-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Guys,
FYI, I factored out a2dp.h and renamed a2snk to a2recv. I'm going to
wait to create an a2dp.c with common code since there isn't much currently.
Brad
-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Brad,
> Thanks for also cleaning up the stuff I did to make libao optional.
you are welcome.
> Is a2snk working now then? Can I factor out the common stuff in
> a2snk/a2play without messing up changes anyone is holding onto?
The sbcdec does not accept input from standard input at the moment and I
think we should implement the soundcard access over /dev/dsp directly
into a2snk. And for a2play we may wanna add support to read its input
from the soundcard.
And btw we should rename a2snk to a2recv.
> Any suggestions for the name of the new header file that a2snk/a2play
> will include? avdtp.h seems like a poor choice...
Simply name the common code a2dp.c and a2dp.h.
Regards
Marcel
-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Marcel,
Thanks for also cleaning up the stuff I did to make libao optional.
Is a2snk working now then? Can I factor out the common stuff in
a2snk/a2play without messing up changes anyone is holding onto?
Any suggestions for the name of the new header file that a2snk/a2play
will include? avdtp.h seems like a poor choice...
Brad
Marcel Holtmann wrote:
> Hi Mayank,
>
>
>>>This is the improved version for the sbcdec.c file
>>>which you asked for.
>>>
>>>It uses /dev/dsp to play the decoded samples.
>>>
>>>The output is pretty well if we incorporate the proper
>>>endian type.
>>>
>>>I suggest that you keep it as a separate file incase
>>>someone wants to use the AO Libraries.
>>
>>I will move the version using AO to sbcdec_ao and use your version
>>instead. However first I must cleanup your coding style a litte bit.
>
>
> I had to change a lot more and so I started over. Please take a look at
> the end result in the CVS.
>
> Regards
>
> Marcel
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: NEC IT Guy Games.
> Get your fingers limbered up and give it your best shot. 4 great events, 4
> opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
> win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
> _______________________________________________
> Bluez-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Mayank,
> > This is the improved version for the sbcdec.c file
> > which you asked for.
> >
> > It uses /dev/dsp to play the decoded samples.
> >
> > The output is pretty well if we incorporate the proper
> > endian type.
> >
> > I suggest that you keep it as a separate file incase
> > someone wants to use the AO Libraries.
>
> I will move the version using AO to sbcdec_ao and use your version
> instead. However first I must cleanup your coding style a litte bit.
I had to change a lot more and so I started over. Please take a look at
the end result in the CVS.
Regards
Marcel
-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Moin,
Am Sun, 1 May 2005 13:43:48 +0100 (BST) schrieb Mayank Batra:
> The output is pretty well if we incorporate the proper
> endian type.
Ahh, so it works for you now? (I was not able to test it yet ...)
I hadn't thought of endianess all the way long. I was using big endian
for the .au file input (don't remember why) in the encoder and then
mostly consequently everywhere from there on.
--
Henryk Pl?tz
Gr??e aus Berlin
~~~~~~~ Un-CDs, nein danke! http://www.heise.de/ct/cd-register/ ~~~~~~~
~ Help Microsoft fight software piracy: Give Linux to a friend today! ~
Hi Mayank,
> This is the improved version for the sbcdec.c file
> which you asked for.
>
> It uses /dev/dsp to play the decoded samples.
>
> The output is pretty well if we incorporate the proper
> endian type.
>
> I suggest that you keep it as a separate file incase
> someone wants to use the AO Libraries.
I will move the version using AO to sbcdec_ao and use your version
instead. However first I must cleanup your coding style a litte bit.
And we should also change sbcdec to accept inputs from standard input
instead of files only.
Regards
Marcel
-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel