Hi Brad,
Your a2play code on the CVS is not 'exactly' according
to the specifications.
The specifications demand that the source encodes the
media payload into an appropriate format (SBC in this
case) and then stream the packet to the sink. The sink
then decodes the packet and plays the stream.
But in your code, you are sending an already encoded
file instead of streaming a simple PCM file by
encoding the file into SBC frames in a real time
manner.
Infact there is no use of storing SBC files at the
source. The source should read the PCM file (for
example a .wav or .snd file), encode the data into SBC
and then form the A2DP packet.
And who the hell has .sbc files on his system ??
I improved your code to fulfill the above
requirements. My code does exactly what a2play code
does. The only difference is that my code reads a pcm
format file(.snd file which is Sun/NeXT format), it
converts the file to SBC packets during the streaming
process.
So the source need not keep .sbc file on his system.
A .snd file can be listened to using the Linux
application called 'play'.
I am using the SBC codec library from the CVS.
I have tested my code with the help of Dongles with
various stacks:
1) BlueZ stacks on both source and sink.
2) BlueZ stack on source and IVT Corporation's
BlueSoleil on the sink side (Windows)
My code is working fine in all cases.
Please tell me if you would like to update the CVS
with my code.
Also, I am ready to put up the A2DP sink code on the
CVS.
Please tell if you would like to put it on the CVS as
well.
And please, I intended no offence to anyone. I was
just waiting to get over with certain formalities.
Thanks and Regards,
Mayank
________________________________________________________________________
Yahoo! India Matrimony: Find your life partner online
Go to: http://yahoo.shaadi.com/india-matrimony
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Mayank
> Your a2play code on the CVS is not 'exactly' according
> to the specifications.
>
> But in your code, you are sending an already encoded
> file instead of streaming a simple PCM file by
> encoding the file into SBC frames in a real time
> manner.
it was written as a proof of concept. it actually doesn't work well at
all if you give it a raw sbc file because it's not paced correctly. it
works most consistently if it's used like
mpg123 --au - file.mp3 | sbc/sbcenc - | ./a2play bdaddr
we count on mpg123 to enforce timing correctly, but even then, a2play
can block the pipeline and mess up the timing, for example if the link
is lossy.
> Infact there is no use of storing SBC files at the
> source. The source should read the PCM file (for
> example a .wav or .snd file), encode the data into SBC
> and then form the A2DP packet.
agreed
> I improved your code to fulfill the above
> requirements. My code does exactly what a2play code
> does. The only difference is that my code reads a pcm
> format file(.snd file which is Sun/NeXT format), it
> converts the file to SBC packets during the streaming
> process.
>
> Please tell me if you would like to update the CVS
> with my code.
yes, definitely. if it's very big, email it to me directly.
to maintain license compatibility, we want (especially avdtp) code
contributions to be GPL so they could go into the kernel if appropriate.
is that license ok with you?
> Also, I am ready to put up the A2DP sink code on the
> CVS.
>
> Please tell if you would like to put it on the CVS as
> well.
very good! yes.
> And please, I intended no offence to anyone. I was
> just waiting to get over with certain formalities.
understood. i don't think anyone took offense. i mainly wanted you to
feel that we are interested in helping you and working together. you
shouldn't feel like you've reached a dead end.
very cool.
Brad
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel