Audio capture issue with BeagleBone Black and Audio Cape Rev B

[Dien Nguyen]

Hi All,

We tried the Audio Cape Rev B with BeagleBone Black. The kernel version is 3.14.17 (https://github.com/RobertCNelson/bb-kernel.git branch am33x-v3.14)

We was able to play and record via the Audio Cape. If we record and play the file via the Audio Cape, it works fine. But when we move the recorded file to other machine or play it via the USB Sound Card, the speed of the recorded file seems 1.5 time slower than it really is.

On the board, we recorded the audio with

arecord -t raw -f S16_LE -r 44100 /tmp/1.raw

Then, we playback the file with command

aplay -t raw -f S16_LE -r 44100 /tmp/1.raw

1/ On x86 machine, the voice become very slow. If we change the sampling rate to 63000, it is played close to the real voice we recorded.

2/ Trying with a USB Sound Card plugged directly to the board.

aplay -t raw -f S16_LE -r 44100 -D plughw:1,0 /tmp/1.raw

We saw the same issue as seen on x86 machine

It seems that there is something wrong with the sampling rate clock. May anyone please give some suggestions

Thanks

[John Syn]

From: Dien Nguyen <nguyentie...@gmail.com>
Reply-To: "beagl...@googlegroups.com" <beagl...@googlegroups.com>
Date: Sunday, November 30, 2014 at 7:14 PM
To: "beagl...@googlegroups.com" <beagl...@googlegroups.com>
Subject: [beagleboard] Audio capture issue with BeagleBone Black and Audio Cape Rev B

I’ve seen the same problem when recording on the BBB and then playing the same file on my Ubuntu Desktop. Not sure why this happens. I’m using 3.15.10-bone8. 

Regards,

John

Thanks

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Dien Nguyen]

Hi John,

Did you solve the issue yet, may you please share how to fix it? We also tried with 3.18 and the issue is still there.

Thanks,

Dustin

You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/XmMg5DjJvsk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.

[Jesse Cobra]

Curious what happens if you try 48k sampling?

[Dien Nguyen]

Hi Jesse,

Tried out with 48KHz, same issue occurred. Have you recorded and played successfully with any kernel version?

Thanks,

Dustin

[Nicolae Rosia]

Hello,

The clock is wrong. For some reason the clock clock rate is not
changed to 12MHz as set in dts file but to 24MHz (ti,codec-clock-rate
= <12000000>;).
If you change the clock to 24MHz in your dts, it will work as expected.

Regards,
Nicolae Rosia.

On Mon, Dec 1, 2014 at 4:42 PM, Dien Nguyen

[John Syn]

From: Dien Nguyen <nguyentie...@gmail.com>
Reply-To: "beagl...@googlegroups.com" <beagl...@googlegroups.com>

Date: Sunday, November 30, 2014 at 9:37 PM
To: "beagl...@googlegroups.com" <beagl...@googlegroups.com>
Subject: Re: [beagleboard] Audio capture issue with BeagleBone Black and Audio Cape Rev B

Hi John,

Did you solve the issue yet, may you please share how to fix it? We also tried with 3.18 and the issue is still there.

I never really looked into the issue because it wasn’t important to me. As long as I could record and playback on the BBB, I was OK, but I did notice the issue when I recorded on the BBB and then played back on my Ubuntu desktop. I looked at the schematics and I see that GPIO3_21 (AUD_MCLK) is driven by either Y4 (24.576MHz) or MCASP0_AHCLKX. So I did a few measurements and AUD_MCLK is always 24MHz no matter what the sampling rate. In the DTS the codec-clock-rate is shown as 12000000 so this doesn’t make any sense. Perhaps the MCASP code isn’t reading this number correctly and is defaulting to 24MHz. 

Regards,

John

[John Syn]

From: Jesse Cobra <jesse...@gmail.com>
Reply-To: "beagl...@googlegroups.com" <beagl...@googlegroups.com>
Date: Sunday, November 30, 2014 at 11:05 PM
To: "beagl...@googlegroups.com" <beagl...@googlegroups.com>
Subject: Re: [beagleboard] Audio capture issue with BeagleBone Black and Audio Cape Rev B

Curious what happens if you try 48k sampling?

I get the same results.

Regards,

John

[John Syn]

On 12/1/14, 10:27 AM, "Nicolae Rosia" <nicola...@gmail.com> wrote:

>Hello,
>
>The clock is wrong. For some reason the clock clock rate is not
>changed to 12MHz as set in dts file but to 24MHz (ti,codec-clock-rate
>= <12000000>;).
>If you change the clock to 24MHz in your dts, it will work as expected.

I¹m not sure that is how this is supposed to work. Surely the DTS defines
the clock rate rather than reflecting the clock rate? My guess is that the
ALSA subsystem is reading the DTS codec-clock-rate, but the MCASP_AHCLKX
isn¹t been set correctly by the MCASP code and simply defaulting to 24MHz.

Regards,
John
>

[Dien Nguyen]

Hi John and Nicolae,

Thanks for your help, changing the sysclk to 24MHz, we are now able to capture file on the board and play it on PC. John is right that the modification in dtb has no effect, I forced the sysclk in the driver ./sound/soc/davinci/davinci-evm.c

    ret = of_property_read_u32(np, "ti,codec-clock-rate", &drvdata->sysclk);                            
    if (ret < 0)                                                                                        
        return -EINVAL;                                                                                 
drvdata->sysclk = 24000000;                                                                             
printk("###%s: sysclk %d\n", __FUNCTION__, drvdata->sysclk);

Need to do more debug to see if U-boot fixed up the dtb value.

Thanks a lot,

Dustin

[Dien Nguyen]

Hi John,

Have you tried to record with external microphone?

The recording works fine if I connect the Audio Cape directly to the speaker source (a tablet) with a male-to-male 3.5mm cable. In case of using external microphone, the Audacity Frequency Analysis shows there is no frequency that is higher than 3KHz.

I tried the same test with USB Sound Card and it works fine.

Do you have some special setting for alsamixer?

Thanks,

Dustin

[John Syn]

From: Dien Nguyen <nguyentie...@gmail.com>
Reply-To: "beagl...@googlegroups.com" <beagl...@googlegroups.com>

Date: Tuesday, December 2, 2014 at 6:35 PM
To: "beagl...@googlegroups.com" <beagl...@googlegroups.com>
Subject: Re: [beagleboard] Audio capture issue with BeagleBone Black and Audio Cape Rev B

Hi John,

Have you tried to record with external microphone?

You have to bias the microphone, but the audio cape didn’t implement the microphone bias circuitry so you will have to bias the microphone externally for it to work. If you search for the TLV320AIC3106EVM schematic, you can see how to bias the microphone. 

The recording works fine if I connect the Audio Cape directly to the speaker source (a tablet) with a male-to-male 3.5mm cable. In case of using external microphone, the Audacity Frequency Analysis shows there is no frequency that is higher than 3KHz.

I tried the same test with USB Sound Card and it works fine.

I haven’t checked the audio bandwidth, but if I use a sampling rate of 96KHz, the audio quality sounds fine.

Do you have some special setting for alsamixer?

The only settings I change is Press F4 for Capture, make “Line Line2 Bypass” = 100 and “PGA” = 50

Here is the command I use:

arecord -c1 -f S32_LE -r 96000 -t wav -vv test.wav

or

aplay -C -c1 -f S32_LE -r 96000 -t wav -vv test.wav

I use the second command because my debugger gets confused when loading alsa-util debug symbols. After all, arecord is just a soft link to aplay. 

Regards,

John

[Dien Nguyen]

Hi John,

Thanks a lot for your detail instruction. We will try with the external biased microphone. 

Regards,

Dustin

[jama...@gmail.com]

Hi

I wanna get audio with a microphone and BBB. I am new. I dont know how to work with PRU to get the audio with BBB. could you help me please?

best regards

chiya

[Dennis Lee Bieber]

On Thu, 13 Aug 2020 10:05:38 -0700 (PDT), in
gmane.comp.hardware.beagleboard.user
jamal73sm-Re5JQE...@public.gmane.org wrote:

You should have started a new thread instead of piggy-backing on a
thread about the "Audio Cape rev B" -- unless you are using that cape.

>Hi
>I wanna get audio with a microphone and BBB. I am new. I dont know how to
>work with PRU to get the audio with BBB. could you help me please?
>

I suspect that, unless you are using a USB microphone (which generates
PCM/WAV data directly) then you will need to use one of the ADC pins. Those
pins are limited a max of 1.8V -- so you likely will need to apply some
sort of level shifter to the output of the microphone.

If you plan to use the PRU, you should check the TI manual for SoC used
on the BBB to confirm it can set up and read the ADC.


--
Dennis L Bieber

[chiya mohammadi]

Hi Dennis. 

thank you for your reply. Unfortunately I live in Iran and I can't go to TI website. 

I wanna get the audio with 6 ADMP401 microphones and a BBB. 

I couldn't go to the TI website and couldn't find proper documents on other sites. 

so I don't know how to work with PRU and ADC.

please, help me somehow if possible. 

best regards

chiya

‫‪Dennis Lee Bieber‬‏ <‪dennis....@gmail.com‬‏> در تاریخ جمعه ۱۴ اوت ۲۰۲۰ ساعت ۱:۵۷ نوشت:‬

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/XmMg5DjJvsk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/tgbbjfpg8djt91iv5qe3ftj0j6dag0gfbg%404ax.com.

[chiya mohammadi]

I can't go to this link:

http://processors.wiki.ti.com/index.php/PRU-ICSS

It will be great if you send me the user guide. Or an instruction that you know.

thanks

‫‪chiya mohammadi‬‏ <‪jama...@gmail.com‬‏> در تاریخ جمعه ۱۴ اوت ۲۰۲۰ ساعت ۲۳:۴۶ نوشت:‬

[Dennis Lee Bieber]

On Fri, 14 Aug 2020 23:46:27 +0430, in gmane.comp.hardware.beagleboard.user
chiya mohammadi <jamal73sm-Re5JQE...@public.gmane.org> wrote:


>thank you for your reply. Unfortunately I live in Iran and I can't go to TI
>website.

That is going to be a problem. Since the documents are copy-righted no
one can legally redistribute them, even if TI doesn't require registration
for them (I know I've had to go through a set of security questions to get
approval to download some stuff from TI).

>I wanna get the audio with 6 ADMP401 microphones and a BBB.

Are you talking raw chips or something on a carrier like
https://www.sparkfun.com/products/9868
I would point out that on the break-out,
https://learn.sparkfun.com/tutorials/mems-microphone-hookup-guide#arduino-software-example
the /idle/ output is already half of Vcc -- 1.6V -- and the BBB ADC maxes
out at 1.8V. You'll need an analog level shifter (op-amp perhaps, or a
potentially power-draining resistor voltage divider network) to change 0.0
- 3.3V => 0.0 - 1.8V.

>I couldn't go to the TI website and couldn't find proper documents on other
>sites.
>so I don't know how to work with PRU and ADC.

I don't see anything obvious in the TRM about the PRU having access to
analog data. It has access to the eCAP but I think that mostly provides
timing for digital event capture. Most of the ADC mentions seems to be part
of the TSC_ADC_SS (touch screen controller - analog digital converter -
subsystem).

It does have the ability to set an "interrupt" pin for the PRU (PRU
does not have true interrupt -- the code must poll the pin to detect a
change and branch based on it). Don't know if the PRU can access the
sampled data.

Sampled data is stored in FIFOs which can be handled by DMA or by the
(the ARM processor, not the PRU?) CPU.


The easiest starting point is likely Python
https://learn.adafruit.com/setting-up-io-python-library-on-beaglebone-black/adc
but I suspect that won't be fast enough for capturing audio. Detecting
audio, yes, but recording it... doubtful.

Heck -- based upon
https://e2e.ti.com/support/legacy_forums/embedded/starterware/f/790/t/392567?Test-ADC-Sample-rate-with-the-BeagleBone-Black-3359-processor-
"""
The AM335x has a single ADC with 8 input analog multiplexer. The maximum
sample rate of the ADC is 200 kSPS. So if you need to sample 4 inputs for
each sequence of the FSM, the maximum sample rate of each of these 4 inputs
would be 50 kSPS.
"""

So even if you program it at the register level, six inputs means a
maximum sample rate per input is only 33.3k -- or 0.75% of CD audio
(44.1k).


https://github.com/monkeyiq/adc-iio-continuous-sampling-userspace
http://beagleboard-gsoc13.blogspot.com/2013/07/sampling-analogue-signals-using-adc-on.html
might have some applicability though they are quite old...

Most examples use the sysfs form to access the ADC values -- I don't
find any examples actually programming the low-level ADC registers
directly.

http://theduchy.ualr.edu/?p=962 Ah -- this one actually does mention using
the PRU. Unfortunatly -- the author never provided the code, and one needs
the TRM to figure out where the step config registers are addressed.

It is mentioned that the OS set-up for ADC is configured for 16x
averaging -- that's going to cut the 33.3k per channel down to just over
2k.


*************************************************

The most useful I've found is https://github.com/pgmmpk/bbb_pru_adc
which is up to Debian 10 compatibility, so something from the last year or
so. Capture speed of 15kHz without averaging. Again, this is a Python
module so there is that overhead. HOWEVER, the PRU access is C (and maybe
PRU assembly) in the "firmware" files. Studying those may give you some
idea of where to start.

************************************************



--
Dennis L Bieber

[chiya mohammadi]

Thank you Dennis for everything. It took a lot of time for you. I really appreciate that.

Your guidance was very useful.  

I am using the microphone on the carrier, not just the raw chip. 

I actually wanna do source localization like the paper that I've attached to this email. 

they connected the microphone to the board directly(fig 14 in the attached paper), but as you said the low sample rate is the problem. They recorded the audio with 20K samples per second. But I wanna get data with more than 40K S/s like 100K S/s. Probably I should use an external ADC with a proper sample rate and connect it to the board with SPI pins. 

The problem is Beagle Bone doesn't have a good and enough document, But Raspberry Pi has lots of books, sites, youtube videos etc. 

Thank you again for everything

I am a student at Iran university of science and technology and I am doing my master now. this is my phone number 09145533622 you can send me a message or call me on whatsapp if I can help you somehow. I owe you :)))

‫‪Dennis Lee Bieber‬‏ <‪dennis....@gmail.com‬‏> در تاریخ شنبه ۱۵ اوت ۲۰۲۰ ساعت ۲۲:۴۵ نوشت:‬

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/XmMg5DjJvsk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/rq3gjf9h9dak1bpop5rrds1sov3q2l15o9%404ax.com.