Microphone Bias Voltage Level

Hi,

I’m wondering how I can set the mic bias voltage level on the Audio Cape, it is currently off and I cannot get my mic to work. Can I do this via alsa or something similar?

Thank you,

Tris

Hi!

diff --git a/sound/soc/davinci/davinci-evm.c b/sound/soc/davinci/davinci-evm.c
index 7ad7b37..e196aa5 100644
--- a/sound/soc/davinci/davinci-evm.c
+++ b/sound/soc/davinci/davinci-evm.c
@@ -117,15 +117,13 @@ static const struct snd_soc_dapm_route audio_map[] = {
 	{"Line Out", NULL, "RLOUT"},
 
 	/* Mic connected to (MIC3L | MIC3R) */
-	{"MIC3L", NULL, "Mic Bias 2V"},
-	{"MIC3R", NULL, "Mic Bias 2V"},
-	{"Mic Bias 2V", NULL, "Mic Jack"},
+	{"LINE2L", NULL, "Mic Bias 2.5V"},
+	{"LINE2R", NULL, "Mic Bias 2.5V"},
+	{"Mic Bias 2.5V", NULL, "Mic Jack"},
 
 	/* Line In connected to (LINE1L | LINE2L), (LINE1R | LINE2R) */
 	{"LINE1L", NULL, "Line In"},
-	{"LINE2L", NULL, "Line In"},
 	{"LINE1R", NULL, "Line In"},
-	{"LINE2R", NULL, "Line In"},
 };

Thank you, does that mean I need a device tree overlay that tells the driver I’m using a mic as well as line in?

Will I need to recompile the kernel to apply this patch?

I think you just need to recompile the kernel with the code provided. Then you use alsamixer to tell which device captures sounds

Is there a dummies guide to replacing a kernel on a BBB built with a flasher with a new one?

sure!
http://eewiki.net/display/linuxonarm/BeagleBone+Black

Did it work? Can you please say the procedure? I am working on a project that has a similar requirement.

Did it work? Can you please say the procedure? I am working on a project that has a similar requirement.

The mic bias voltage on the TLV320AIC3104 isn’t connected on the audio cape so you will need external circuitry to use a mic.

Regards,
John

If i use usb audio interface instead of the cape, is there a need for biasing ?

all the usb soundcards i’ve tried so far can don’t need biasing. just solder an electret mic directly to a minijack and connect it to the input of the usb soundcard. though note that sound quality varies. some cards make a lot of noise (one logilink model even was blinking a led when active and that interfered and could be heard in the mic input signal.)
terratec aureon dual usb is the best sounding card i’ve found so far. though i don’t own an audio cape so i can’t compare.

If i use usb audio interface instead of the cape, is there a need for biasing ?

What about using microphone input from a headphone for recording and using the headset for playback? Does it need any extra circuitry?

Will USB headset with mic work for audio application that records sound and playback on beaglebone with quality?Here is there is no need for separate pre- amplifier or circuit that requires biasing mic voltage?

Hi there,

I’m looking to use an electret microphone with a beaglebone black for my project. Can’t I directly plug the mic into an analog pin and use the data?
Do I need a pre amplifier circuit kind of thing to use the mic with a BBB?

You would be better off using an audio codec for this purpose. Unfortunately, the Audio Cape doesn’t bring out the microphone circuitry, but you could use a audio preamp and connect to the audio cape audio input.

Regards,
John

Hi!

@TJF,

You do realize that audio is more than just an ADC. Think equalization, dynamic range, etc. Also, you need streaming and that requires a lot more code on the ARM side which isn’t necessary when you use a CODEC and the ALSA framework.

Regards,
John

OK, so without using PRU you would read from /dev/iio:device0, but the sampling rate isn’t going to be fast enough for you. You can increase the sampling rate by modifying the ADC dts parameters which you will find in the ADC overlay.

sudo sh -c "echo ‘BB-ADC' > /sys/devices/platform/bone_capemgr/slots"

Problem is as you increase the sampling rate, the CPU utilization increases because the driver uses interrupts for each scan cycle.

Currently the ADC driver is configured for 16x oversample, Open Delay = 152 cycles and Sample Delay = 1 cycles.

time in us for processing a single channel, calculated as follows:

num cycles = open delay + (sample delay + conv time) * averaging

num cycles: 152 + (1 + 13) * 16 = 376

clock frequency: 24MHz / 8 = 3MHz
clock period: 1 / 3MHz = 333ns

processing time: 376 * 333ns = 125us

Regards,
John

Please ensure your replies include beagleboad group e-mail list.

The standard ADC driver is based on IIO framework and does not use the PRU, hence you will find the driver under /drivers/iio/adc/ti_am335x_adc.c.

The libpruio was developed by jeli.freiherr@gmail.com and you should ask him about his library. He has excellent documentation here:

http://users.freebasic-portal.de/tjf/Projekte/libpruio/doc/html/

The library is based on UIO and the following documentation will help you understand the concepts:

https://www.kernel.org/doc/htmldocs/uio-howto/index.html

Regards,
John

From a pin allocation prospectively, allocating the right McASP pins may
introduce other problems (pin sharing, etc). The ADCs have dedicated analog
pins to avoid this.

For basic ("telephony quality") audio, the ADCs are quite work able. Things
you need to consider are -
- Signal conditioning (converting the mV range into a signal that fits
0-1.8V). Biasing is pretty easy - a cap and a resistor should work with many
mics.
- Noise filtering.
- Software
- The reference on the BBB is hard wired to 1.8V.

I have gone down this path and have it working with PocketSphinx. Highlights
of the journey -
- Opamps or single transistor AMPs do work but there is a lot of tuning needed
keep a usable signal from the ADC. over a range of distances to the mic
without having to do a lot of shouting or dealing with clipping.
- Using a single chip AGC/mic preamp does make things a lot easier to tune.
- The ADC is quite noisy.
- The output sample rate is 8KHz. There are different settings that can give
you 8KHz on the ADC but they have different noise characteristic. The settings
will have to be tuned to match the signal conditioning circuit.
- Data output via a simple character driver. Original plan was to get this
into ALSA but haven't found time for that yet. IIO is nice but that requires
some kind of userland decoding for pocketsphinx. The character driver outputs
match the 'file' input format for pocketsphinx.