I'm currently in the process of designing a digital audio mixer and I'm not the most experienced when it comes to embedded systems.
I'm using a PCM 4201 ADC http://www.ti.com/product/PCM4201/description and I notice that it outputs left/right justified 24 bit MSB data. This sounds pretty good but the processor I want to use, the DM3730 processor http://www.ti.com/product/DM3730/description happens to use LSB data. Is this a problem or is there an easy way to convert this without introducing latency?
Related
I had a assignment for college where we needed to play a precompiled wav as integer array through the PWM and DAC. Now, I wanted more of a challenge, so I went out of my way and created a audio dac over usb using the micro controller in question: The STM32F051. It basically listens to my soundcard output using a wasapi loopback recorder, changes the resolution from 16 to 12 bit (since the dac on the stm32 only has a 12 bit resolution) and sends it over using usart using 10x sample rate as baud rate (in my case 960000). All done in C#.
On the microcontroller I simply use a interrupt for usart and push the received data to the dac.
It works pretty well, much better than PWM, and at a decent sample frequency of 48kHz.
But... here it comes.. When there is some (mostly) high pitch symphonic melody it starts to sound "wobbly".
Here a video where you can hear it: https://youtu.be/xD3uTP9etuA?t=88
I read up on the internet a bit about DIY dac's and someone somewhere (don't remember where) mentioned that MCU's in general have interrupt jitter. So may basic question is: Is interrupt jitter actually causing this? If so, are there ways to limit the jitter happening?
Or is this something entirely different?
I am thinking of trying to compact the pcm data send over serial (as said before, resolution of 12 bits, but are sent in packet of 2 8bits forming 16bits, hence twice the samplerate as the baud rate, so my plan is trying to shift 12 bits to the MSB and adding four bits of the next 12 bit value to the current 16 bit variable, hence only needing 12 transfers instead of 16 per 8 samples. Might read upon more efficient ways of compacting data for transport.), put the samples in a buffer and then use another timer that triggers at 48kHz for sending the samples to the dac. Would this concept work? Or would I just waste time?
For code, here is the project: https://github.com/EldinZenderink/SoundOverSerial
I like to sample a signal which is generated by the pins of my Raspberry Pi. I made the experience that high sample rates are difficult to realize.
First I done a fast approach with Python(super slow). Then I changed to ANSI C + the bcm2835.h lib. I gained significant performance gains.
Now I am asking my self the question: How to do the best sampling under Linux?
My tries were undertaken in user space. But what is about, switching to kernel space? I can write a simple character device kernel module. In this module the pins are periodically checked. If the state changed some information is put into a buffer. This i/o buffer is polled by a synchronous file read for a application in user space. The best solution for me would be, if the pin checking can be done with a fixed frequency(sample period should be constant for signal processing).
The set up for this could be:
#kernel: character module + kernel thread + gpio device tree interface + DSP at constant sampling time
#user space: i/o app reading synchronous from character module
Ideas/tips?
I have a solution for you.
I have written such a module:
https://github.com/Appyx/gpio-reflect
You can synchronously read any signal from the GPIO pins.
You can use the output and calculate the signal with your sampling rate.
Just divide the periods.
I've to design an IO-module for an industrial control system in a CAN-bus network.
The IO-pins (10-40 pins) have to be all multi purpose: digital and analog in- and output. Further the pins have to serve as a communication port when needed: Modbus RTU, modbus TCP, DALI, etc. (Analog input max 7 channels)
I understand that all of this options need different HW; like galvanic isolation or different voltage levels etc.
Costs have to be as low as possible.
I was thinking of making this bit of additional hardware as a plug-in module or as an optional additional sandwich PCB.
My question is: Is an FPGA the right choice for this because of the reconfigurable purpose of the IO-pins? (Xilinx, altera/intel and microsemi have FPGA's with ADC's)
You didn't specify if IOs have to be reconfigurable at compile or runtime. In most cases, you cannot change IO properties (type, voltage, terminations,etc.) once HDL code is compiled into FPGA bitstream.
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.
I would like to play 32 bit audio from my computer. Is this possible? I know about "AL_EXT_FLOAT32" extension, but does any hardware/windows even support this? And if there is support for it, will it just be reconverted and played as 16 bit audio?
Is it possible to play 32 bit audio from a PC with consumer hardware?
As far as I'm aware, most consumer hardware only supports 16-bit audio output. Some of the premium sound devices sometimes support up to 24-bit. Most digital audio systems support 16 and 24-bit PCM steams. I have not seen consumer devices which support 32-bit PCM.
Most likely windows will just scale it down or, with some devices, will crash the sound driver (remember some Sound-Blasters on XP).
Many music formats can be stored in (normalized) 32-bit floats, and will quite possibly be processed by OpenAL or Operating system's audio mixer in 32-bit floats. The mixer then sends the data to the driver, which is usually 16-bit.
I don't know OpenAL, but I think that format is about the input audio format (or the internal mixer?), not the audio output it will produce?
That, or it supports high-end professional equipment?