Audio Cape with Beaglebone Black

Hussein,

Just to clarify, using the 3.8.6 kernel allows the audio cape to work out of the box? Do I also need to disable the virtual HDMI cape as well? Thanks,

Hi,
using 3.8.13 kernel I disabled HDMI cape in am335x-bone-common.dtsi, recompiled it using DTC and substituted previous am335x-boneblack.dtb in /boot.
Now audio cape is seen:

root@beaglebone:~# aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: EVM [DA830 EVM], device 0: AIC3X tlv320aic3x-hifi-0 []
Subdevices: 1/1
Subdevice #0: subdevice #0

I noticed, both on BeagleBone and BeagleBone Black, that quite often the .wav files I play are noisy and distorted. But sometimes it happens they are played well.
Anyone could point out why?
Thanks
Filippo

On a beaglebone I re-installed Angstrom-Cloud9-IDE-GNOME-eglibc-ipk-v2012.05-beaglebone-2012.11.22.img, kernel 3.2.34, and audio cape is working fine with same hardware and same audio files.

The only difference is in how audio cape is recognized (kernel 3.2.34):

root@beaglebone:~# aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: EVM [AM335X EVM], device 0: AIC3X tlv320aic3x-hifi-0 []
Subdevices: 1/1
Subdevice #0: subdevice #0

instead of (kernel 3.8.13)

root@beaglebone:~# aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: EVM [DA830 EVM], device 0: AIC3X tlv320aic3x-hifi-0 []
Subdevices: 1/1
Subdevice #0: subdevice #0

Regards
Filippo

Hi Filippo,

This is my first post to the list, so greetings everyone.

Regarding the audio cape, I can confirm that the 3.8.13 kernel for the Beaglebone currently does not work with the TLV320AIC3106 codec that is on the audio cape. I’ve built a custom cape that uses the same codec and where the codec is connected to the beaglebone using the same pins, and while this works fine using the 3.2 kernel I can’t get it to work on 3.8.13 using the (excellent) patch set from Robert Nelson. In my setup I can switch between the 3.2 and 3.8 kernel while keeping everything else the same, what I have been able to tell is that the codec seems to be programmed identically under the two different kernels (by reading the codec_reg file under the debug file system). Further, looking at the actual HW pins (clock, frame sync, data in & data out) they seem to have the same frequency under both kernels as well, though I haven’t decoded that actual data sent to the codec. Programming of the codec clock rate (using the device tree “ti, codec-clock-rate” attribute) also seems to take effect on the 3.8 kernel. I’m not sure how to continue debugging this so I’d like to ask for suggestions on how to find the root cause? Note that all of this is on the Beaglebone white, I have not attempted the black version yet.

Thanks!
Daniel

Hi Daniel,
thank you for feedback.
I think the issue is not BB version dependent.
I think the issue depends on kernel version.
Sadly I have no advice to give you.
I hope that the problem will be addressed. I know that audio cape is not supported on BBB, but it should be supported on BBW.
Considering that the issue affects the latest official angstrom distribution for BBW, I think that there are good chances that at least one audio expert will address it.
If not, the backup solution is to rely on 3.2 kernel. It would be a pity because I like the device tree compiler and overlays mechanism very much.
Regards
Filippo

Hi,

I agree with your statement that this issue depends on the kernel version and not the BB version. I’ve done some more debug, from the application layer the sounds system appears to be identical between the 3.2 and 3.8 kernels, at least the output of aplay -vv is the same on both versions. However, what I have discovered is that when looking at the HW layer the relation between a known datastream coming out on the McASP dataout pin and the frame sync is fixed (as one would expect) on the 3.2 kernel but it varies on the 3.8 kernel. The method I used to discover this was to create a known set of data (dd if=/dev/zero of=test count=32 bs=1) and send that out as raw samples (cat test | aplay -t raw). On the 3.2 kernel the frame sync signal is aligned with the data, but on the 3.8 kernel the frame sync appears asynchronous to the data stream. That is, I get the correct frequency on the frame sync signal on the 3.8 kernel, but it is not synchronized to the audio data stream. Unfortunately, I don’t know the driver layers well enough in the Linux kernel to know how to debug this further. Let me know if I should post this to some other forum as well?

And yes, I can also see that this issue impacts angstrom v2012.12 release on the BBW.

Regards
Daniel

Thank you for your detailed analysis.
What surprises me is that the audio distorsion doesn’t happpen on every play.
And yes, you should ask for help anywhere you think you could find it. As we did on this forum as well.
Regards
Filippo

Hi,

I’m trying to follow this thread. I’m confused about two things:

Is there any version of the kernel which consistently produces undistorted stereo audio output and input with the audio cape? And if so, is the behavior dependent on BeagleBone version?

I’m about to embark on an audio project, and I’m trying to identify an ARM A8 Linux development environment for the project. I thought the BBB was it, but this whole situation looks ominous. I only know of one solution that is known to work for audio input and output (a friend told me about it):

BeagleBone White with external USB audio box (must find out which one) and unknown kernel version.

At this point I think I’ll buy a BBB board and see if it works with the same kernel and USB audio box my friend is using. If that doesn’t work, I’ll buy a BBW and duplicate his setup. It would be nice if the situation were cleaner!

  • Andy

Hi,

I now have a working setup for playback with my custom TLV320AIC3106 based audio amplifier cape, while this is not the same cape as the audio cape (BB-BONE-AUDI-01) they are similar enough that I believe the issue is the same for both. The issue is with the davinci_mcasp.c driver, and part of the problem comes from the 0002-BeagleBone-Black-TDA998x-Initial-HDMI-Audio-support.patch which changes directions on some clock pins on the McASP peripheral. Another patch which I’m not sure if fully correct is this one;http://mailman.alsa-project.org/pipermail/alsa-devel/2012-October/055969.html. I’ll pick up a thread with the maintainers of this driver to see if we can get it sorted out properly, my patch shouldn’t be included now because it will likely break something else…

Regards
Daniel

Danie3l, thank you very much! I’m a newbie, just bought a BBB and audio cape primarily for a ham SDR project, but for other projects as well. This thread has been a great help in getting as far as I have with the audio cape. It was delivered yesterday, and of course was not recognized. Updating the kernel to 3.8.13 and modifying the uEnv.txt file took care of that. Now I have the same problem with distortion as Filippo and others, so I’ll be waiting to see what the driver folks come up with.

Pete (NI9N)

Hi,

Short update, upon closer review it turns out that the changes in http://mailman.alsa-project.org/pipermail/alsa-devel/2012-October/055969.html which are applied to the current 3.8.12 kernel do not hurt a davinci-evm compatible audio setup (ie, for example the BB-BONE-AUDI-01 audio cape or the custom cape I have developed). The core of the problem is with a few lines in the 0002-BeagleBone-Black-TDA998x-Initial-HDMI-Audio-support.patch, and I’ve been in touch with Darren that wrote this patch. He said that it was a quick fix to get HDMI working on the BBB, but that he would take another look at making a proper solution now to restore the audio cape support.

I now have a BBB with a patched Ångström 2012.12 image here next to me playing music :slight_smile: This is using my custom audio cape which in addition to the codec also contains a 2 channel audio amplifier to be able to directly drive speakers. Works nicely :slight_smile:

Below is my temporary hack to restore davinci-evm functionaly, note that applying this likely breaks HDMI and possible other things.

Regards
Daniel

Index: git/sound/soc/davinci/davinci-mcasp.c

Hi,

I am having same problem with you.
When I play .wav files with the command of aplay, sound comes with noise so often.
Sometimes get clear.

I am using audio cape with BBB on latest Angstrom.
Any solution for this???

Br,
Maria

Daniel,

Is this basically a setup and/or hold time problem caused by an inversion of the I2S clock (or is it not as simple as that)? I ask because if the issue is as simple as this, those doing I2S DAC-hardware hacks could do interim fixes by adding a tiny bit of hardware and an inversion jumper to their projects…

Don

Don,

The issue currently in the 3.8.13 kernel is that when Darren wrote the
patch to handle HDMI on the BBB he had to make some changes to the
McASP driver related to audio format and clock enable/disable settings
in the AM335x CPU. At the time, there was not support in place to do
this "properly" so the patch made HDMI work but caused a regression
for the audio cape. I don't think there is a way to fix this in HW, it
is not as simple as just adding delay or inversion.

The patch I sent out fixes this in such a way that the audio cape
should work, but likely breaks HDMI. Darren has said he would take
another look at a "proper" fix which will allow both HDMI and the
audio cape to work.

Regards
Daniel

Hi Daniel,
nice shot!

You can have audio via HDMI. You can have audio via the Audio cape. But you cannot have both.

Gerald

Daniel, thank you for posting your hack. Please forgive me for asking a dumb question, but I’m new to this. I’m assuming your hack is inserted into the Angsrom kernel. Can that be done without building the entire kernel? Can you recommend some reference that would show me how to take such a hack and produce a working kernel? Thanks!

Pete

Hi Pete,

Yes, the workaround is a kernel patch and would require a complete kernel rebuild. Not sure I have a good reference for the complete sequence, but these are good starting points;

http://www.angstrom-distribution.org/building-angstrom

http://www.slimlogic.co.uk/2011/05/openembeddedangstrom-kernel-workflow/

/Daniel

By the way (and you probably already new this) it looks like the record path works well, as long as the mode is S16_LE. I tried the following on my BBB:

arecord -fS32_LE -c2 -r96000 -twav -d10 /tmp/test2.wav

and was able to play the resulting file with iTunes. It sounded great! However, S24_LE played back at the wrong rate (too fast). S32_LE resulted in very low volume. No doubt I’m making a dumb mistake …

Gerald,

I agree, you can’t have audio on both HDMI and audio cape at the same time. What I meant with allowing both the work is that it should be possible on the 3.8 kernel to configure through capemgr which one you would like to use at a given time, that is currently not the case (only HDMI works, not the audio cape).

/Daniel