I am bit stuck, how can I make my arduino record into .wav files?
The arduino is connected with a microphone, and am using the Arduino ADC.
Any ideas? Will I be able to play them back using my pc?
many question cross my head
1- Is this possible using an arduino Uno
2- Is this possile using just a microphone connected to the Arduino ADC
3- if yes how can i get the wav format.
The idea gonna be like this
Ardiuno microphone-->Uno ADC -->arduino (library making wav sound)--> Storing data to a an SD card connected via SPI or maybe (connecting a Raspberry as a storage device)
also another question:
4- Do I need an amplifier due to the act that analog output from the microphone is very weak so the ADC couldn't detect the variation
In another log i had seen that i should connect the microphone to a level shifter.And that cause of the analog output is AC so i have to make the negative wave as 0 (for 10 it ADC)
the zero point as 512 and the positive as 1024 (10 bit ADC).(really i'm not sure about this part)
doing some research i got this library "https://github.com/TMRh20/TMRpcm/wiki/Advanced-Features#recording-audio" which is supposed to do the job, I mean making some wav file from the analog input.
So any help would be appreciated
Thx in advance,
Salah Laaroussi
Yes, although a bit complex it is very possible to do this via an uno.
The biggest hurdles to overcome is the limited amount of RAM and the clock speed. You will have to setup twin buffers to handle writing to the SD card. Make sure the card has a high enough write speed or the entire program will come to a screeching halt as you will run out of memory.
apc mag has a great article detailing out the circuit and code.
http://apcmag.com/arduino-projects-digital-audio-recorder.htm/
There are many things you haven't prepared yet:
output of microphone (assuming you know about electronics: still requires a biasing circuit e.g. a resistor + capacitor).
the output of the microphone is still very weak (in the magnitude of mV), which Arduino is incapable of capturing so you need a pre-amplifier
the design of the pre-amplifier will also include DC offset which makes the output of the microphone all above 0VDC which is in the range of the Arduino ADC otherwise the arduino will capture only those above 0VDC.
Related
I have an idea that I have been working on, but there are some technical details that I would love to understand before I proceed.
From what I understand, Linux communicates with the underlying hardware through the /dev/. I was messing around with my video cam input to zoom and I found someone explaining that I need to create a virtual device and mount it to the output of another program called v4loop.
My questions are
1- How does Zoom detect the webcams available for input. My /dev directory has 2 "files" called video (/dev/video0 and /dev/video1), yet zoom only detects one webcam. Is the webcam communication done through this video file or not? If yes, why does simply creating one doesn't affect Zoom input choices. If not, how does zoom detect the input and read the webcam feed?
2- can I create a virtual device and write a kernel module for it that feeds the input from a local file. I have written a lot of kernel modules, and I know they have a read, write, release methods. I want to parse the video whenever a read request from zoom is issued. How should the video be encoded? Is it an mp4 or a raw format or something else? How fast should I be sending input (in terms of kilobytes). I think it is a function of my webcam recording specs. If it is 1920x1080, and each pixel is 3 bytes (RGB), and it is recording at 20 fps, I can simply calculate how many bytes are generated per second, but how does Zoom expect the input to be Fed into it. Assuming that it is sending the strean in real time, then it should be reading input every few milliseconds. How do I get access to such information?
Thank you in advance. This is a learning experiment, I am just trying to do something fun that I am motivated to do, while learning more about Linux-hardware communication. I am still a beginner, so please go easy on me.
Apparently, there are two types of /dev/video* files. One for the metadata and the other is for the actual stream from the webcam. Creating a virtual device of the same type as the stream in the /dev directory did result in Zoom recognizing it as an independent webcam, even without creating its metadata file. I did finally achieve what I wanted, but I used OBS Studio virtual camera feature that was added after update 26.0.1, and it is working perfectly so far.
I have tried to send 12-bit audio to be listened to in real time through the HC05 SPP bluetooth module hooked up to an arduino and DAC over serial with a python RFCOMM socket. I have since learned that Serial Port Protocol is not very great at all for this purpose due to its low bandwidth. I figured I could definitely send the data and then play it out through a DAC, but I doubt an arduino would hold an array the size of a WAV file and maybe not even an mp3 file, but that would defeat the purpose of controlling the audio (play,pause,rewind,etc) from my computer. Would it be more realistic and worthwhile to use an A2DP enabled bluetooth module? Or is it still possible to listen to acceptable quality 12-16 bit audio in real time with SPP? I have tried to use lower bit songs, adjusted baud rates for the arduino and HC-05 serial ports, and tried to adjust the magnitude of the values outputted by the DAC to the audio port and I still seem to get crackly audio. It seems the problem comes down to the low bitrate transfer speed of SPP, or am I wrong?
Is it realistic to stream 12-16 bit audio through SPP bluetooth in realtime?
Sure, at some awfully slow sample rate <= 8 kHz. You'd be better off sending 8-bit audio at a higher sample rate.
Would it be more realistic and worthwhile to use an A2DP enabled bluetooth module?
Yes, absolutely, without question. That's what it's designed for, as I mentioned in your other question.
Or is it still possible to listen to acceptable quality 12-16 bit audio in real time with SPP?
Acceptable is subjective. If it's just voice, you can get away with it. If you want reasonable audio quality for music, almost universally, no, it's not acceptable.
It seems the problem comes down to the low bitrate transfer speed of SPP, or am I wrong?
Without any code to inspect and debug, it's impossible to say what the specific problem is that you're referring to. Undoubtedly, the low bandwidth will not enable good quality audio anyway.
If you must continue to use SPP and simple codecs like PCM, at least use differential PCM to save a bit more bandwidth.
I am currently working on a project which aim to detect Bluetooth and decode Bluetooth packets (I use a Hack RF One to make the detection). I have made a Gnuradio Flowgraph in order to demodulate Bluetooth signal and I am trying to decode visualy the packets by searching a Bluetooth frame on a binary file.
Unfortunately, I didn't succeed to recover a clear view of the Bluetooth signal. To be precise, I am pretty sure that I detect Bluetooth on my sinks but when sending this to a Clock Recovery + Binary Slicer blocks, I am unable to recover interresting data in the binary file (especially the MAC adress of the sending device, which is part of the a Bluetooth packet). Moreover, I would like to know what type of network layer (physical, transport, baseband...) is intercepted in this type of process. In my case, I aim to intercept baseband layer packets.
Additionaly, I am interrested in knowing how to use the gr-bluetooth because I can't find a lot of documentation concerning this block. I think this can be interresting for the development of my project.
Could you please, give me your view, opinion about this problem ? I am stucked at this stage without knowing the exact origin of my issue. (Here is my flowgraph GnuRadio_Flowgraph and a screenshot of one of my Bluetooth detection Detected signal at 2.402GHz).
Thank you very much,
You probably need an ubertooth instead https://www.sparkfun.com/products/10573
I read that the bluetooth frequency skipping is spread wider than the HackRF can read, so at-best, you're going to miss 75% of frames if you only have one hackrf connected.
I'm working on a project that streams data to a laptop. The data is an analog signal with 5 kHz bandwidth (almost like audio) that is digitized at first and should be transmitted over a bluetooth module to a laptop. I've searched a lot about modules that use this protocol to stream data. I figured out simple bluetooth modules like hc-05 or hc-06 because of their limitation of packet's size and interval time can't be used for this application. It has been suggested to use audio bluetooth module like bc127 and csr because of their appropriate sample rate (I want more than 20 kS/s) and their applications so I want to use them but not for an audio signal for my signal. Now I want to ask you:
1- Can I use these modules to acquire my signal (that is not an audio signal) wireless?
2- Do these modules compress signal for transmission and should I decompress it in receiver side (I know they have some audio DSP but I don't know what are they and their function)?
3- Can laptop's bluetooth hardware receive this data without any problem? If not, what are alternatives?
4- is there any filtering in the proccess? i mean filter about voise band(300 Hz ~ 4 kHz)
thank you.
I have a capture card that captures SDI video with embedded audio. I have source code for a Linux driver, which I am trying to enhance to add video4linux2 support. My changes are based on the vivi example.
The problem I've come up against is that all the example I can find deal with only video or only audio. Even on the client side, everything seems to assume v4l is just video, like ffmpeg's libavdevice.
Do I need to have my driver create two separate devices, a v4l2 device and an alsa device? It seems like this makes the job of keeping audio and video in sync much more difficult.
I would prefer some way for each buffer passed between the driver and the app (through v4l2's mmap interface) contain a frame, plus some audio that matches up (with respect to time) with that frame.
Or perhaps have each buffer contain a flag indicating if it is a video frame, or a chunk of audio. Then the time stamps on the buffers could be used to sync things up.
But I don't see a way to do this with the V4L2 API spec, nor do I see any examples of v4l2-enabled apps (gstreamer, ffmpeg, transcode, etc) reading both audio and video from a single device.
Generally, the audio capture part of a device shows up as a separate device. It's usually a different physical device (posibly sharing a card), which makes sense. I'm not sure how much help that is, but it's how all of the software I'm familiar with works...
There are some spare or reserved fields in the v4l2 buffers that can be used to pass audio or other data from the driver to the calling application via pointers to mmaped buffers.
I modified the BT8x8 driver to use this approach to pass data from an A/D card synchronized to the video on Ubuntu 6.06.
It worked OK, but the effort of maintaining my modified driver caused me to abandon this approach.
If you are still interested I could dig out the details.
IF you want your driver to play with gstreamer etc. a separate audio device generally is what is expected.
Most of the cheap v4l2 capture card's audio is only an analog pass through with a volume control requiring a jumper to capture the audio via the sound card's line input.