i have a Bluetooth module and micro controller to decode the music. but i don't know how the music is send serially. i have searched for this problem. but i didn't get anything useful.
i need to make a Bluetooth music player system using micro controller. my aim is to play music wireless.
i want to know how the mp3 files are sending in a android device. how the song is encoded. and the idea of decoding the data. thank you
my Bluetooth module is HC-05
and i'm using 8051 micro controller
its for my project
Use the AudioTrack.write() method to write music data out to a stream. You can choose the encoding, sample rate, channels, etc. when you create the AudioTrack object. If you are just sending the data over a serial connection you should be able to do whatever you want. If you are sending audio to a headset, it has to be mono, 8000 bps, PCM modulated.
most probably it will be in PCM or PWN at the receiving end i.e Micro controller, connect DAC amplify analog signal it should work.
Related
How the voice call audio is transferred from modem to the AP side in Qualcomm chipsets in Android? And how the call audio gets played in the AP side? Source code flow would help. Any references?
I'm expecting a source code flow analysis.
I have read the HSP bluetooth specification but I don't understand If I can use the headset bluetooth profile to send data (e.g. audio stream) from headset to phone and from phone to headset. If the HSP specification I see that the headset send AT commands to audio gateway, but I don't understand how the data are transferred from audio gateway to phone and from phone to audio gateway.
I want to change data between 2 android devices that have only HSP, HPF and A2DP profiles. It is possible to send/receive data to/from 2 devices with only this bluetooth profiles?
Technically you can transfer data via the audio channel. E.g. a wav file is also some binary data, containing audio Ra data, so why not transfer any other binary?
You just have to bypass the encoder (sbc or similar) what maybe is not so easy. Otherwise your binary data is destroyed.
Moreover, note that you talk from audiogate and smartphone. Usually the smartphone IS the audiogate. E.g. when using smartphone and headset, the smartphone also called audiogate in the Bluetooth spec.
If you try to connect 2 android devices with audio streams, of of these needs to take the headset role.
You could also transfer data using hfp by using AT commands. Might get a bit ugly. By the way, if you can send AT commands, these commands are most likely transferred over rfcomm. So I am wondering why you cannot access it.
I am working on something that requires some raw data to be sent to the speaker in real time on an device that runs on android.
Example
I have a formula that generates the wave form. how do I send that data to the speaker for listening in android?
The simplest way to write raw PCM data is via the AudioTrack class: https://developer.android.com/reference/android/media/AudioTrack
You can operate it in a streaming mode, if needed.
How would I go about streaming audio from one device to another over the internet? I'm aware of sending basic data using Java sockets, but wondering how to:
Start streaming midway through a file (say, during the middle of a song)
What format is needed for the data being sent. MediaPlayer can take a url as a data source, so how should the audio be represented when being sent from the server side?
Thanks
Having implemented a music streaming app, I can share a little with you.
If you want to stream and use the Android MediaPlayer class, MP3 or OGG is your best bet for a format.
If your architecture is client-server, i.e. real server in the Internet serving streams to Android devices, then just stream MP3 or OGG bytes over HTTP. Just point MediaPlayer to a URL on on your server.
If your architecture is peer-to-peer with your own custom socket code, you can create a "proxy http" server that listens on localhost on a dedicated thread. You point your MediaPlayer instance to your local in-process socket server (e.g. http://localhost:54321/MyStream.mp3). Then you have to implement code to parse the HTTP get request form MediaPlayer, then proxy the stream bytes between your custom P2P socket protocol and listeners connected to your local http server. A lot of radio streaming apps do exactly this so as to parse the ICECAST metadata from the MP3 stream. Here's the code I use for my radio streaming app that does this.
For the "start midway through the file" scenario, you might find my MP3 Stream Reader class useful. It wraps an InputStream (file, socket stream, etc..) and syncs to the next valid frame from where ever you started from. Just call read_next_chunk to get the next block of audio and its format. MediaPlayer might do most of this heavy lifting for you, so this might not be needed.
A and B are talking on the phone. During the call, A presses a button that pulls audio from a resource and plays it over the phone call to B.
Is this possible using the Android framework? The goal is for the person on the other end of the call to hear the audio.
If it's not possible, is it a hardware limitation or a limit of the Android framework?
I believe that you cannot achieve that, according to the documentation HERE :
Note: You can play back the audio data only to the standard output device.
Currently, that is the mobile device speaker or a Bluetooth headset.
You cannot play sound files in the conversation audio during a call.
According to http://developer.android.com/reference/android/media/AudioManager.html, there are a number of channels though which audio can be played:
STREAM_ALARM The audio stream for alarms
STREAM_DTMF The audio stream for DTMF Tones
STREAM_MUSIC The audio stream for music playback
STREAM_NOTIFICATION The audio stream for notifications
STREAM_RING The audio stream for the phone ring
STREAM_SYSTEM The audio stream for system sounds
STREAM_VOICE_CALL The audio stream for phone calls
These are what the android framework allows for. It would seem to me that two are of potential interest to you: STREAM_DTMF or, more likely, STREAM_VOICE_CALL. I haven't experimented personally, but if I was trying to do this, I would start by trying those two.