Re: Audio Cape with Beaglebone Black

[Carl Johnson]

I have an audio cape that worked well with the original BeagleBone, although I'm struggling to get it to work with the BeagleBone Black.  I'm running the latest 3.8.11 Angstrom release, and the logs show that it loads the device tree OK but for some reason it isn't recognized as an alsa device.  I'll post an update if I get it working.

I'm also using this audio dongle on the BeagleBone Black, which works quite well in alsa.  It only has a mono microphone input though.

[Gerald Coley]

That is correct on the HDMI interface. You can read about it in the SRM.

http://circuitco.com/support/index.php?title=BeagleBoneBlack

Gerald

On Wed, May 15, 2013 at 11:36 PM, David Scheltema <dcsc...@gmail.com> wrote:

Once I get my Beagle Bone White I am going dig around and see if I cannot make a good SD dump for the BBB.  I believe I read somewhere that you cannot disable the HDMI interface, but I really ought to give you a link to source that --sorry I cannot find it now.

I will keep you all up to date.

David

  
On Monday, May 6, 2013 1:58:02 AM UTC-4, Garry Geisler wrote:

Hi,

I am also trying to get the audio (or DVI with Audio) cape working on the BBB.

My understanding is that since the HDMI is already onboard, it cannot support 2 audio devices.

As I do not require the HDMI interface, I am trying to find a way to disable the HDMI device from loading and load only the Audio cape driver?

So far no success. Please let us know if anyone finds a solution.

Thank you!

Garry


On Wednesday, May 1, 2013 9:46:47 PM UTC-7, Robert Twomey wrote:

Hi, 

I'm looking for a dependable stereo audio in / out solution for the Beaglebone Black. 

I see in this thread the suggestion of using a cheap USB soundcard. However, I've had little luck with cheapo usb audio cards on the raspberry pi. I'm worried that it won't work with this system. 

With the rPi I've been using a C-Media chipset USB audio cards from amazon (http://www.amazon.com/Syba-SD-CM-UAUD-Adapter-C-Media-Chipset/dp/B001MSS6CS/ref=sr_1_1?ie=UTF8&qid=1367469801).

I hope maybe the Audio Cape is a better option for me...

I see the DVI-D Audio cape is listed as "incompatible": http://circuitco.com/support/index.php?title=BeagleBone_Black_Accessories#Capes

Has anyone tried the Audio Cape with the BBB? 

If not, can you recommend a make or model of USB sound card that worked for both input and output?

Thanks very much!

Robert

--
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/groups/opt_out.
 
 

--

Gerald

 

ger...@beagleboard.org

g-co...@ti.com

http://beagleboard.org/

http://circuitco.com/support/

[David Anders]

elmohandis,

indeed this "hack" will allow the audio cape to work. kernel driver support wise, there is nothing preventing the cape from working, only the resource conflict with the virtual hdmi cape. with this hack in place, of course the HDMI will not be functional....

it would great if you could create a wiki page over on elinux.org to document your testing!

Dave


On Friday, May 17, 2013 11:07:29 AM UTC-5, elmohandis wrote:

I can confirm the audio cape runs nicely on the beaglebone black with the stock 3.8.6 kernel.

Upon attempting newer kernel versions, the HDMI "fixes" seem to break compatibility with the TLV codec and no sound cards are detected on boot (although Audio cape is detected).

In order to disable the virtual HDMI cape, you can remove it from the device sheet under /boot/ (dont remember now exactly which file it was). That should stop loading the HDMI drivers and the HDMI audio device disappears upon reboot.

Regards

[Maxim Podbereznyy]

Hey guys!

Can you point precisely what should I disable and where to enable the audio cape? I have the same issue

18.05.2013 0:03 пользователь "David Anders" <dande...@gmail.com> написал:

[Brent]

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,

[gregory....@gmail.com]

Hi,

I modified my uEnv.txt to this and it works now!

optargs=quiet drm.debug=7 capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN,BB-BONE-EMMC-2G capemgr.enable_partno=BB-BONE-AUDI-01

Br,
Gregory

[Bo Ram Kim]

Hi Gregory,

Thank you for your solution.
But it doesn't work for me.
Is it the 'uEnv.txt' under /boot?


Br,
Maria

[gregory....@gmail.com]

uEnv.txt is under the partition which is popup when you plug board over usb

[Technoshaman]

Hello all,

If you need a cheap solution for just audio out, you can try a TDA1543 (a very common and cheap, 16-bit, stereo, I2S DAC @ 9Mhz Max). Couple of days ago I managed to play an mp3 using the command:

ffmpeg -i file_name.mp3  -f alsa "default:CARD=Black" -re -vol 20

Yes, it did sound like crap, for it was on a perf-board, connected with crappy wires, output was cheap passive I/V, and the connections to the BBB was also long and prone to lotsa noise on my desk.

I got the clock signal from pin 31 on P9, and divided it by four, using two D-Flip Flops (both in a 74HCT74, PIN31 provides the clock for the HDMI Framer  Processor, and it's at 24.576MHz). The rest of the signals are at the links below. Recently, I designed a good PCB for the whole thing (using a NE5532 for outputs), and hopefully I'll get better results when I print it.

This page was rather helpful for me:

http://www.element14.com/community/community/knode/single-board_computers/next-gen_beaglebone/blog/2013/05/28/bbb--audio-notes

Regards,
Emrah

[Juan C.]

Plug in your BBB to a host computer using the mini usb data cable.

Go to My Computer>BeagleBone Getting Started> and open uEnv.txt
Copy and paste this command into the .txt file. Make sure to save your changes. (Ctrl+s)

optargs=quiet drm.debug=7 capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN,BB-BONE-EMMC-2G capemgr.enable_partno=BB-BONE-AUDI-01

Safely eject your BBB from your computer and mount the weather cape onto your BBB.

[Juan C.]

Sorry, meant to say mount your 'Audio Cape.'

[filippo....@gmail.com]

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

[filippo....@gmail.com]

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

[greenca...@gmail.com]

Techno:

I don't think pin 31 is a 24.576MHz clock.  The sys ref manual says that the clock is DERIVED from Y4, which is 24.576MHz, but the pin 31 clock is the real I2S synchronous audio clock.
I think using those two FFs to divide that clock by 4 is a mistake.  I think that AP0(SPI1_D0) should be connected directly to WS, AP1(SPI1_CS0) should be connected directly to SD, and ACLK (SPI1_SCLK) should be connected directly to SCK.

The framer pixel clock really comes into the TDA19988 on pin 4 of the chip as LCD_PCLK.

If the clock on pin 31 is faster than 9MHz, you simply need a faster I2S DAC (but I suspect your DAC is just fine).

If your breadboard is still together, you should try bypassing that divider chain and see if the audio improves.  If you report joy, I'm going to order a few DACs!

Don

[greenca...@gmail.com]

Actually, I've looked into this further, and the pin 31 clock *could* be 24.576MHz. I looked at two different I2S DACs...

If the audio sample rate is 48KHz, then the interface looks like it would match up well with a Max5556 I2S DAC.  That particular DAC has internal PLLs and wants an MCLK at a rate of either 256 or 512 times the sample rate.   Edges line up with 16 bit audio, but this chip (and really all I2S DACs) can accept 24bit audio too, even if it is a 16 bit DAC (the LSBs are discarded).  The PLLs must clock things different internally if 24 bit data is sent to the DAC....

OK, so looking at the TDA1543 datasheet, the timing diagram shows that the clock input is expected to be synchronous with the data input (no PLL).  This means that for a (24.576/4) = 6.144MHz clock, if you have two channels of 16 bit data (32 bits), the sampling rate would be 6.144MHz/32 = 192KHz.  So, if the audio sampling rate is 192KHz, your divide-by-four clock is the correct frequency.

However, there is still one more worry.  When you divide a clock down asynchronously like that, the clock-to-data phase relationship after power on or reset will come up in one of four random states.  Only one of those states gives you the optimum timing margin for clocking in your data.  If you are violating some setup and hold times, that could cause messed-up audio.

Don


Don

[Andrew Voelkel]

Hi,

I am about to jump over from an unsuccessful attempt to use Pandaboard and buy a BeagleBone. I'd like to buy a BeagleBone Black, but having read through this thread, I'm a little concerned about audio, especially since audio development will be my main focus (and I need working audio in and out). There are so many posts in this thread that I've kind of lost track of the basic status of compatibility with the audio cape (particularly the audio-only cape). Can someone summarize where we are today with regards to the following questions:

1. Are there Linux versions for BBB which run without issue with the audio only cape (http://circuitco.com/support/index.php?title=BeagleBone_Audio)?
2. For Linux versions for BBB which may require tweaking to get the audio cape to run, can the onboard HDMI still be used for video out?
3. What experience have people had with USB audio boxes. I don't need a cheap USB audio box, I just need it to work. A friend of mine reports success with this approach on BeagleBone White.
4. To what extent do problems with the audio cape and/or USB audio exist on the BeagleBone White. (If they don't exist on the White, I can buy a White and move to the Black later on when the problems are solved).

Thanks for any help! I will help me decide which board to order.

- Andy

[Andrew Voelkel]

Hi,

This is just a test. I tried posting earlier but don't see my post. I'm trying again. You can ignore.

[Gerald Coley]

If you are not a member, all posts are moderated (That means I approve them when I check for them. I cannot guarantee 24/7 coverage).

If you register, then your first post is moderated. (That means I approve them when I check for them. I cannot guarantee 24/7 coverage).

Gerald

--
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/groups/opt_out.
 
 

[Andrew Voelkel]

Hi Gerald,

Am I registered? I added BeagleBoard to my Google Groups. If not, how do I register?

- Andy

[Gerald Coley]

Go to the bottom of the page at http://beagleboard.org/Community/Forums Fill in your email address. Hit subscribe. And no, you are not registered. Gerald

[Daniel Nilsson]

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

[filippo....@gmail.com]

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

[Daniel Nilsson]

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 <wav> 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

[filippo....@gmail.com]

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

[Andrew Voelkel]

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

[Daniel Nilsson]

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

[pe...@lazydogengineering.com]

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)

[Daniel Nilsson]

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 :-) 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 :-)

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
===================================================================
--- git.orig/sound/soc/davinci/davinci-mcasp.c    2013-06-25 20:32:46.168577833 +0200
+++ git/sound/soc/davinci/davinci-mcasp.c    2013-06-25 20:35:05.435122806 +0200
@@ -749,7 +749,7 @@
     if (stream == SNDRV_PCM_STREAM_PLAYBACK) {
         /* bit stream is MSB first  with no delay */
         /* DSP_B mode */
-          mcasp_clr_bits(dev->base + DAVINCI_MCASP_AHCLKXCTL_REG, AHCLKXE);
+          mcasp_set_bits(dev->base + DAVINCI_MCASP_AHCLKXCTL_REG, AHCLKXE);
         mcasp_set_reg(dev->base + DAVINCI_MCASP_TXTDM_REG, mask);
         mcasp_set_bits(dev->base + DAVINCI_MCASP_TXFMT_REG, TXORD);
 
@@ -759,8 +759,6 @@
         else
             printk(KERN_ERR "playback tdm slot %d not supported\n",
                 dev->tdm_slots);
-        mcasp_set_bits(dev->base + DAVINCI_MCASP_TXFMCTL_REG, AFSXE);
-        mcasp_set_bits(dev->base + DAVINCI_MCASP_TXFMCTL_REG, FSXDUR);
     } else {
         /* bit stream is MSB first with no delay */
         /* DSP_B mode */

[Maria]

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

[Don Miller]

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

On Monday, June 24, 2013 3:01:37 PM UTC-4, Daniel Nilsson wrote:

[Daniel Nilsson]

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

> --
> 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/ZJGwxA7BG4E/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to

[filippo....@gmail.com]

Hi Daniel,
nice shot!

[Gerald Coley]

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

Gerald

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.

[PeteNI9N]

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

[Daniel Nilsson]

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

[PeteNI9N]

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 ...

[Daniel Nilsson]

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

[Gerald Coley]

Agreed. Just wanted to make it clear for those that may be reading this 2 months from now.

Gerald

[Martin AA6E]

I am also working on a project that requires high-quality sound in and out.  I'd really like to use the audio cape with the BBB, but not so much that I want to use special OS versions or patches.  So I'm hoping that a mainstream (Debian?) driver solution will be coming that allows the audio cape -- and HDMI video (HDMI audio is nice, but not needed much). 

To get on with my work (software defined radio), I've been using a SoundBlaster 1240 USB card (~$80) that is very good.  Possibly the cheaper SB1095 would be OK, too.  Less expensive USB sound cards are lower quality -- no surprise.

Martin

[n...@bike-nomad.com]

Actually, you can verify that these patches would work (and you might be able to fix a single, long-running application once it's opened the audio device) by poking at memory:

root@beaglebone:~# devmem2 0x480380b4 w 0x8000

/dev/mem opened.

Memory mapped at address 0xb6fce000.

Read at address  0x480380B4 (0xb6fce0b4): 0x00000000

Write at address 0x480380B4 (0xb6fce0b4): 0x00008000, readback 0x00008000

root@beaglebone:~# devmem2 0x480380ac w 0x100

/dev/mem opened.

Memory mapped at address 0xb6fa7000.

Read at address  0x480380AC (0xb6fa70ac): 0x00000112

Write at address 0x480380AC (0xb6fa70ac): 0x00000100, readback 0x00000100

I did this after starting aplay and it fixed the sound completely on my BB-BONE-DVID-02 cape (DVI-D with audio).

I had previously made a .dtbo file for this cape by merging the audio cape with the DVI-D cape .dts files and compiling them.

Then I added the following to my uEnv.txt "optargs" setting:

capemgr.disble_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN capemgr.enable_partno=BB-BONE-DVID-02

Make sure that you've previously set the proper mixer settings also using alsamixer or equivalent.

[Don Miller]

Emrah,

I verified tonight that the MAX5556 DAC appears to work.  I am getting some very low level clicks occasionally, but overall the sound is very good.  I just did a quick and dirty prototype tonight on a solderless breadboard.  The digital lines were kept short, but the grounding was far from ideal for a digital/audio interface.  I will move the setup onto a proto-cape board with a groundplane next and do an eval of the signal integrity of the digital interface with a slope.

In a perfect world, there would be some ground pins near the mcasp pins to take the digital return currents.

Everything I have thrown at mplayer seems to be converted to 48KHz by alsa.  If that is universally true, that would be a good thing(tm) because I think the MAX5556 setup depends on the clock ratios resulting from that scheme.

I've linked a picture.  The MAX chip is on the bottom (made a header assembly out of a 16 pin DIP socket).  The other SO-8 chip (on the top) is a dual op-amp that is unused so far.  I came out of the chip outputs, through 560 ohm series resistors, and straight to earphones.

I did *nothing* to change the pin configuration of the card, so if this doesn't totally mess up the signal integrity of the signals going to the HDMI chip, it MIGHT be possible to have both HDMI and embedded audio at the same time.


http://i.imgur.com/IEsgebH.jpg

Don


On Tuesday, June 18, 2013 7:08:03 AM UTC-4, Technoshaman wrote:

Hello all,

If you need a cheap solution for just audio out, you can try a TDA1543 (a very common and cheap, 16-bit, stereo, I2S DAC @ 9Mhz Max). Couple of days ago I managed to play an mp3 using the command:


[transis...@gmail.com]

It's been a month since it was mentioned that the audio cape compatibility problem was being looked at by "Darren". In addition, there have been no updates since 6-20 for the flasher (BBB-eMMC-flasher-2013.06.20.img.xz). Has there been any progress on the BBB lately? Thanks.

[Gerald Coley]

Audio cape still does not work from what I can see. Darren never was working on it. He is working on HDMI issues

I suggest you contact sup...@beagleboardtoys.com direct for help with their product.

Gerald

On Sat, Jul 27, 2013 at 5:55 PM, <transis...@gmail.com> wrote:

It's been a month since it was mentioned that the audio cape compatibility problem was being looked at by "Darren". In addition, there have been no updates since 6-20 for the flasher (BBB-eMMC-flasher-2013.06.20.img.xz). Has there been any progress on the BBB lately? Thanks.

[Daniel Nilsson]

Hi,

Darren has been working on restoring support for the audio cape, this
is done by reworking the HDMI support patch. There is nothing wrong
with the audio cape or the support for it in mainline 3.8, it is the
patch that adds support for HDMI on the beaglebone black that was
implemented in a way that didn't take other audio peripherals into
account. Darren has reworked this and sent an updated HDMI patch that
restored audio support, but he wanted to do some more work on it
before considering it done. Haven't heard since then, I'll ping him
and check if he is still working on it.

Regards
Daniel

> 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/ZJGwxA7BG4E/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to

[transis...@gmail.com]

Excellent. I did send BeagleBoardToys an email asking about any progress but I don't expect a response till the weekend is over. I'm glad to hear from Daniel that there is indeed work still being done and that it seems to be going well. Thanks for your reply Daniel, and thanks to Gerald for providing so much support on the lists here. It's greatly appreciated.

-Seth

[transis...@gmail.com]

The email I received from BeagleBoardToys said that Circuitco is not currently working on making the Audio cape compatible with the BBB and that they are waiting for some patches for the 3.11 kernel release. This seems to correspond with what Daniel mentioned here. The email didn't give an estimate as to when they were expecting the patches to be released. However, since previous BBB image updates have been posted three or four times a month in the recent past I can only assume it shouldn't take too much longer. I was initially trying to decide whether to attempt the patch Daniel posted above or if I should instead wait for a 'proper fix'. I guess for now I'll just wait a bit longer.

-Seth

[happyh...@gmail.com]

Carl, so that Syba USB C-Media provides audio for BBB out of the box? the only other out-of-the-box audio i've seen is that chipsee 7inch LCD which has onboard audio jacks

HHNET

On Friday, May 3, 2013 4:34:28 PM UTC-7, Carl Johnson wrote:

I have an audio cape that worked well with the original BeagleBone, although I'm struggling to get it to work with the BeagleBone Black.  I'm running the latest 3.8.11 Angstrom release, and the logs show that it loads the device tree OK but for some reason it isn't recognized as an alsa device.  I'll post an update if I get it working.

I'm also using this audio dongle on the BeagleBone Black, which works quite well in alsa.  It only has a mono microphone input though.

[Carl Johnson]

I may have had to use opkg to add a few alsa related packages, but otherwise it was very easy to get the Syba dongle working with the BBB.  I don't recall having to add any USB related kernel modules.  Let me know if it doesn't work for you.

[Daniel Nilsson]

Hi,

I actually haven't heard back from TI and the progress on the HDMI rework they were working on that would supposedly restore audio cape support on the BBB with the 3.8 kernel. However, I did see a larger merge of HDMI related changes that went in to the 3.8 kernel some 2 weeks ago;

https://github.com/beagleboard/kernel/commit/fba875a9d8855812ae743098fe269848c01a5c35

Now, as far as i can tell this shouldn't really resolve the issue as I knew it at the time when I debugged this in detail. Regardless, I attempted to build and boot the bone26 version of the kernel with HDMI disabled (optargs=capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN) and to my surprise this actually produces a working audio setup! In my case I'm testing with my custom audio cape which also contains an speaker amplifier, however the actual codec is the same as the Circuitco audio cape uses. This makes me think that the Circuitco cape should work as well now. Did anyone else who is attempting to use the audio cape on the BBB try this kernel? For testing I used Roberts instructions here;

http://www.eewiki.net/display/linuxonarm/BeagleBone+Black

Regards

Daniel

[eric...@embedian.com]

Filippo,

I had the same distortion and noise problems when using the audio cape. My kernel version is 3.8.13. Sometimes, it plays quite well, but most of time, I heard lots of noises. Is there any workaround so far?

-Eric

filippo....@gmail.com於 2013年6月19日星期三UTC+8上午12時58分21秒寫道：

[astra...@gmail.com]

W dniu niedziela, 1 września 2013 13:28:20 UTC+2 użytkownik eric...@embedian.com napisał:

Filippo,

I had the same distortion and noise problems when using the audio cape. My kernel version is 3.8.13. Sometimes, it plays quite well, but most of time, I heard lots of noises. Is there any workaround so far?

I'm also highly interested in the answer... This might be something kernel-related, the old 3.2.x worked well.

Radek

[filippo....@gmail.com]

Hi,
as Daniel Nilsson (25 GIU) brilliantly posted on this thread, the workaround is to recompile kernel with an update which break hdmi support.
Ned Konz (2 LUG) provided a faster way to implement a workaround.
Both workarounds work.
I suggest to read the whole thread.
Regards
Filippo

[eric...@embedian.com]

Radek,

Filippo is right. Both Daniel Nilsson (25 GIU) and Ned Konz (2 LUG) workarounds work well for me. 

-Eric

astra...@gmail.com於 2013年9月15日星期日UTC+8下午7時03分05秒寫道：

[Radoslaw Szkodzinski]

Ah, but the workarounds do not help - this is BeagleBone original, not
Black. It doesn't have the HDMI cape.
Sorry about hijacking the thread.

For some reason, the sound works intermittently. Sometimes it's noise,
sometimes it's similar to what should be playing, sometimes it's
clean. Any ideas?

[Radoslaw Szkodzinski]

Daniel's patch still works.
The latest 3.8 branch is still broken, however - one would think that
to have been fixed a long time ago...

--
Radosław Szkodziński

[Koen Kooi]

Op 16 sep. 2013, om 02:57 heeft Radoslaw Szkodzinski <astra...@gmail.com> het volgende geschreven:

> Daniel's patch still works.
> The latest 3.8 branch is still broken, however - one would think that
> to have been fixed a long time ago...

If noone sends a patch for it, it will remain broken. So fire up git, fix https://github.com/beagleboard/kernel/tree/3.8 and send a pull request.

[Daniel Nilsson]

Not quite that simple, what I have provided is not a real patch but a workaround that restores audio support for the audio cape at the expense of breaking audio over HDMI. The root cause of the broken audio cape support is the HDMI patches for the BBB and the proper fix is to rework this HDMI support. TI has worked on this over the summer, and Koen merged the initial set;

https://github.com/beagleboard/kernel/commit/fba875a9d8855812ae743098fe269848c01a5c35

However, TI did also "fix" the broken audio cape as part of reworking HDMI support (like I have mentioned a couple of times in this thread). Due to lack of testing though, those patches were not part of the above merge. I have tested them myself on an older kernel, but _only_ to see that the audio cape support is restored. Whether or not HDMI audio still works is unknown, and I don't have a way to test that reliably.

So what is needed is that someone with the proper test setups can test the HDMI audio related patches from TI, if someone is willing to sign up for this I can forward the patches to the mailing list.

Regards

Daniel

 

[lukasz.jan...@zylia.pl]

Hello to everyone!

I am new here, but I was working with BBB for a couple of weeks and was interested in these BBB audio issues as well - I am building some kind of audio sensor based on BBB and AudioCape. At this moment my setup is BBB with debian wheezy with the most up-to-date kerel v3.8.13-bone28. Disabling hdmi allows BBB to detect AudioCape, but, as it was mentioned here, the playback is very noisy, it works fine 1 time per 5. 

Now I am going to apply patch provided by Daniel and rebuild the kernel. Can anyone confirm that this change will make the playback/capture work without distortion?

Daniel,

if you have some new patches that need testing I can sign up for this - I really need the AudioCape to work fine.

Regards,

Lucas

[eze_rg]

Hi Lucas,

I have a BBB with the Cudio Cape working fine without distortion in recording/playback.

Here is what i did:

uEnv.txt:

change this line
optargs=quiet capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN,BB-BONE-EMMC-2G capemgr.enable_partno=BB-BONE-AUDI-01

for this one:

optargs=quiet capemgr.disable_partno=BB-BONELT-HDMI, capemgr.enable_partno=BB-BONE-AUDI-01

patch.sh (this file is in linux-dev directory)

Delete all lines that applies HDMI patches.

(then you must build the kernel)

I did this on Ubuntu 13.04 kernel version 3.8.13-bone24.

I hope it helped

Regards

Ezequiel

[Łukasz Januszkiewicz]

Thank you Ezequiel!

I will try this solution next week, and give you a feedback.

Regards,

Lucas

2013/10/18 eze_rg <rg.ez...@gmail.com>

[lukasz.jan...@zylia.pl]

Hi,

I can confirm that it is possible to achive great audio quality on your BBB with AudioCape. Building kernel without using HDMI patches makes AudioCape works very well. The kernel version I used was 3.8.13-bone28. I belive it is not necessary to disable all of HDMI patches, what excludes HDMI permanently for this kernel. But when somebody doesn't need HDMI at all, this solution is very easy to apply.

Thanks for your help.

Regards,

Lucas

W dniu piątek, 18 października 2013 17:29:11 UTC+2 użytkownik Łukasz Januszkiewicz napisał:

Thank you Ezequiel!

I will try this solution next week, and give you a feedback.

Regards,

Lucas

2013/10/18 eze_rg

Hi Lucas,

I have a BBB with the Cudio Cape working fine without distortion in recording/playback.

Here is what i did:

uEnv.txt:

change this line
optargs=quiet capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN,BB-BONE-EMMC-2G capemgr.enable_partno=BB-BONE-AUDI-01

for this one:

optargs=quiet capemgr.disable_partno=BB-BONELT-HDMI, capemgr.enable_partno=BB-BONE-AUDI-01

patch.sh (this file is in linux-dev directory)

Delete all lines that applies HDMI patches.

(then you must build the kernel)

I did this on Ubuntu 13.04 kernel version 3.8.13-bone24.

I hope it helped

Regards

Ezequiel

--
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/ZJGwxA7BG4E/unsubscribe.

To unsubscribe from this group and all its topics, send an email to beagleboard+unsubscribe@googlegroups.com.

[Yasir K]

Hello All,

 

Been trying to get the cape to work on the BBB, however each time I edit the UEnv.txt file, the BBB refuses to boot afterwards with one light flashing in a constant pattern on both the cape and the board. I'm using this line in the uEnv.txt file:

 

optargs=quiet drm.debug=7 capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN,BB-BONE-EMMC-2G capemgr.enable_partno=BB-BONE-AUDI-01

 

I've tried the above on two different boards and both don't work.

Any help would be highly appreciated!

[Yasir K]

**Update**

 

Have managed to get the audio cape running by editing the uenv.txt file but only if I boot off an SD card, when I edit the uenv.txt file on the eMMC, the board does not boot.

 

Audio playback has a lot of hiss and only works once every few times. Still need help in troubleshooting... 

[Martin Ewing]

I'm not an expert on this, but it seems that you've disabled eMMC.  So you shouldn't expect to boot from eMMC!  Try eliminating BB-BONE-EMMC-2G from the disable list in uEnv.

Martin

--

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/ZJGwxA7BG4E/unsubscribe.

To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

--
Martin Ewing
Branford, Connecticut
martin....@gmail.com

[Yasir K]

It worked!! Well, I guess I didn't even know what I was staring at for 3 days, just removed the EMMC disable part and it works! Here is my uEnv.txt file now:

 

optargs=quiet drm.debug=7 capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN capemgr.enable_partno=BB-BONE-AUDI-01

 

Thanks so much Martin!

 

However, I still have really poor quality audio playback from the cape using mplayer and an mp3 file. Where should I start to try and fix the audio quality issue? Also, it only works once very 2-3 tries. Any pointers to help me fix this issue would be much appreciated.

[eze_rg]

Did you re-recompile the kernel without the HDMI patches??

I did that and my Audio Cape worked very well, i measured almost 84 dBA of SNR.

[lukasz.jan...@zylia.pl]

For those who have some problems with building new kernel, I'd recommend to use this great tutorial by Derek Molloy: http://derekmolloy.ie/beaglebone/beaglebone-adding-usb-wi-fi-building-a-linux-kernel/. When you get to the stage with running build_kernel.sh script, first edit the patch.sh file and disable all HDMI patches and then build the kernel. When you deploy new kernel on your BBB the AudioCape will work without any noise. Remember that you still need to disable HDMI virtual capes in uEnv.txt file as it was written before.

BR,

Lucas

[Walter Schilling]

I'm having difficulty with this setup.  I have a BBBone Black running the stock OS image from Angstrom, attached to an LCD7 display, and the Sound Cape.  I've modified my uEnv.txt file to match that which is listed below.  However, whenever my part starts to boot, the display blinks twice and it then goes back like it is "rebooting".  Is there something else I need to do to make this work with the LCD cape that I am missing?

[Walter Schilling]

Daniel:

I'm curious as to whether you can shed any additional light on BBB compatibility with the audio cape.  I'm trying to prepare for a course that will run in the spring, and we're looking to use audio, lcd screen, and camera cape.  I'd like to go with the black for cost reasons, but I'm not sure of the support for the devices.

Walt

[Cody Lacey]

If anyone is having a problem with their audio cape quality try applying this patch to your 3.8 kernel and let me know if it solves your problem.  I have tested it and it seems to do the job for me but I would like to get input from others.

[Cody Lacey]

I am not sure about the other capes but the Audio Cape was working well until a fix was made for HDMI.  After that it seems that the audio quality degraded.  The solution for some was to not include the HDMI patches in their kernel build.  The patch above will allow for the inclusion of the HDMI patches in the kernel build and fix audio quality from the cape.

[Yasir K]

Cody,

Noob question but how did you apply to the patch to the kernel? I'm following Derek Molloy's bitbake method to compile the BB kernel but haven't found an easy way to insert the patch file to it. I gave up trying to solve the static/noise issue on the cape, it only works 1/10th of the time with clean audio from my BB A5C.

YSK

[John Syne]

From: Yasir K <yas...@gmail.com>
Reply-To: <beagl...@googlegroups.com>
Date: Saturday, November 30, 2013 at 3:31 PM
To: <beagl...@googlegroups.com>
Subject: Re: [beagleboard] Re: Audio Cape with Beaglebone Black

Cody,

Noob question but how did you apply to the patch to the kernel? I'm following Derek Molloy's bitbake method to compile the BB kernel but haven't found an easy way to insert the patch file to it. I gave up trying to solve the static/noise issue on the cape, it only works 1/10th of the time with clean audio from my BB A5C.

YSK


On Wednesday, November 13, 2013 7:42:50 PM UTC+1, cody wrote:

I am not sure about the other capes but the Audio Cape was working well until a fix was made for HDMI.  After that it seems that the audio quality degraded.  The solution for some was to not include the HDMI patches in their kernel build.  The patch above will allow for the inclusion of the HDMI patches in the kernel build and fix audio quality from the cape.

My guess is you are building the V3.8 kernel. You will find the recipe in 

<oe source folder>/sources/meta-beagleboard/common-bsp/recipes-kernel/linux/

The kernel recipe is called "linux-mainline_3.8.bb”

Simply add your patch file to the list (don’t forget to include the trailing \) and then add your patch file to the appropriate folder. 

BTW, it is probably easier to use Robert Nelson’s linux-dev (http://github.com/RobertCNelson/linux-dev). You simply add your patch to the patch.sh file and then place your patch in the appropriate patches folder.

Regards,

John

[Yasir K]

Thanks John,

Iḿ building RCNelsonś linux-dev as we speak with the patch applied in the right folder. However, for the bitBake method, i was bit-baking the cloud9 image which is under meta-ti. What recipe should i edit for the patch file in that case? Would it be one of the kernel recipes under meta-ti or does it still use the mainline_3.8 recipe? Thanks for the tip.

YSK

[Yasir K]

So, while trying to build ubuntu from RCNelsonś 3.12 branch on linux-dev, i get the following error when i run build_kernel.sh

error: patch failed: sound/soc/davinci/davinci-evm.c:380
error: sound/soc/davinci/davinci-evm.c: patch does not apply
error: patch failed: sound/soc/davinci/davinci-mcasp.c:498
error: sound/soc/davinci/davinci-mcasp.c: patch does not apply
Patch failed at 0001 Make the McASP code generic again, remove all hardcoding
When you have resolved this problem run "git am --resolved".
If you would prefer to skip this patch, instead run "git am --skip".

Any ideas?

[Robert Nelson]

On Sun, Dec 1, 2013 at 7:13 AM, Yasir K <yas...@gmail.com> wrote:
> So, while trying to build ubuntu from RCNelsonś 3.12 branch on linux-dev, i
> get the following error when i run build_kernel.sh
>
> error: patch failed: sound/soc/davinci/davinci-evm.c:380
> error: sound/soc/davinci/davinci-evm.c: patch does not apply
> error: patch failed: sound/soc/davinci/davinci-mcasp.c:498
> error: sound/soc/davinci/davinci-mcasp.c: patch does not apply
> Patch failed at 0001 Make the McASP code generic again, remove all
> hardcoding
> When you have resolved this problem run "git am --resolved".
> If you would prefer to skip this patch, instead run "git am --skip".
>
> Any ideas?

Yeap... What did you change.. What's the top commit in the 3.12
branch, what git version, what host os?

As it work here..

Regards,

--
Robert Nelson
http://www.rcn-ee.com/

[Yasir K]

Hi Robert,

Here are the steps i took:

1. Edited the patch.sh file manually and made the following change:

general_fixes () {
    echo "dir: general-fixes"
    ${git} "${DIR}/patches/general-fixes/0001-add-PM-firmware.patch"
    #Nak! use zImage + dtb file...
    #${git} "${DIR}/patches/general-fixes/0002-ARM-CUSTOM-Build-a-uImage-with-dtb-already-appended.patch"
    ${git} "${DIR}/patches/general-fixes/0003-defconfig-add-for-mainline-on-the-beaglebone.patch"
    ${git} "${DIR}/patches/general-fixes/0001-Make-the-McASP-code-generic-again-remove-all-hardcod.patch"


}
2. Copied the patch file to the general-fixes directory

3. Run build_kernel.sh

the git log output is:

v-am33x-v3.12$ git log
commit 125488871b2b08c25b8b53fc6f546374a5b150e4
Author: Robert Nelson <robertsemaileditedout>
Date:   Wed Nov 6 16:26:56 2013 -0600

My host OS is ubuntu , 3.8.0-33-generic and the git version is 1.7.9.5

[Robert Nelson]

On Sun, Dec 1, 2013 at 10:31 AM, Yasir K <yas...@gmail.com> wrote:
> Hi Robert,
>
> Here are the steps i took:
>
> 1. Edited the patch.sh file manually and made the following change:
>
> general_fixes () {
> echo "dir: general-fixes"
> ${git} "${DIR}/patches/general-fixes/0001-add-PM-firmware.patch"
> #Nak! use zImage + dtb file...
> #${git}
> "${DIR}/patches/general-fixes/0002-ARM-CUSTOM-Build-a-uImage-with-dtb-already-appended.patch"
> ${git}
> "${DIR}/patches/general-fixes/0003-defconfig-add-for-mainline-on-the-beaglebone.patch"
> ${git}
> "${DIR}/patches/general-fixes/0001-Make-the-McASP-code-generic-again-remove-all-hardcod.patch"
>
>
> }
> 2. Copied the patch file to the general-fixes directory
>
> 3. Run build_kernel.sh

So.. I'm confused.. You randomly added a patch to patch.sh without
making sure it patched "cleanly" and now it's my script's fault??

Clean up your patch..

[Yasir K]

Hi Robert,

no fault of patch.sh or your script, my OP was for cody who posted a patch for the audio issues on BBB, iḿ trying to figure out a way to get that patch installed /working--and thats where iḿ stuck

[Robert Nelson]

On Sun, Dec 1, 2013 at 11:44 AM, Yasir K <yas...@gmail.com> wrote:
> Hi Robert,
>

> no fault of patch.sh or your script, my OP was for cody who posted a patch
> for the audio issues on BBB, iḿ trying to figure out a way to get that patch
> installed /working--and thats where iḿ stuck

run ./build_kernel.sh without patch..

cd KERNEL
patch -p1 < xyz
fixup *.rej, meld/gedit/etc..

git commit -a -m 'somethign' -s
git format-patch -1
mv to end of patch.sh script..

[Yasir K]

Thanks Robert for helping out, the patch provided by cody fails, i wonder if anyone else has got it working and specifically under what conditions?

patch -p1 < /home/yasirk/Angstrom/0001-Make-the-McASP-code-generic-again-remove-all-hardcod.patch
patching file sound/soc/davinci/davinci-evm.c
Hunk #1 succeeded at 129 (offset -17 lines).
Hunk #2 FAILED at 406.
Hunk #3 FAILED at 424.
Hunk #4 FAILED at 447.
Hunk #5 FAILED at 486.
Hunk #6 FAILED at 509.
5 out of 6 hunks FAILED -- saving rejects to file sound/soc/davinci/davinci-evm.c.rej
patching file sound/soc/davinci/davinci-mcasp.c
Hunk #1 succeeded at 485 (offset 1 line).
Hunk #2 FAILED at 502.
Hunk #3 FAILED at 753.
Hunk #4 FAILED at 763.
3 out of 4 hunks FAILED -- saving rejects to file sound/soc/davinci/davinci-mcasp.c.rej

[Robert Nelson]

On Sun, Dec 1, 2013 at 5:43 PM, Yasir K <yas...@gmail.com> wrote:
> Thanks Robert for helping out, the patch provided by cody fails, i wonder if
> anyone else has got it working and specifically under what conditions?
>
> patch -p1 <
> /home/yasirk/Angstrom/0001-Make-the-McASP-code-generic-again-remove-all-hardcod.patch
> patching file sound/soc/davinci/davinci-evm.c
> Hunk #1 succeeded at 129 (offset -17 lines).
> Hunk #2 FAILED at 406.
> Hunk #3 FAILED at 424.
> Hunk #4 FAILED at 447.
> Hunk #5 FAILED at 486.
> Hunk #6 FAILED at 509.
> 5 out of 6 hunks FAILED -- saving rejects to file
> sound/soc/davinci/davinci-evm.c.rej
> patching file sound/soc/davinci/davinci-mcasp.c
> Hunk #1 succeeded at 485 (offset 1 line).
> Hunk #2 FAILED at 502.
> Hunk #3 FAILED at 753.
> Hunk #4 FAILED at 763.
> 3 out of 4 hunks FAILED -- saving rejects to file
> sound/soc/davinci/davinci-mcasp.c.rej

This is normal kernel patch backporting.. First compare
sound/soc/davinci/davinci-evm.c & sound/soc/davinci/davinci-evm.c.rej
and fix it up..

[Daniel Nilsson]

On Mon, Dec 2, 2013 at 12:43 AM, Yasir K <yas...@gmail.com> wrote:

Thanks Robert for helping out, the patch provided by cody fails, i wonder if anyone else has got it working and specifically under what conditions?

Yes, I have used it and it works under the conditions that Cody stated it should be used under (the 3.8 kernel). Seems like you are trying to apply it on the 3.12 kernel, which would require some work on your side.

Regards
Daniel

[Daniel Nilsson]

On Mon, Dec 2, 2013 at 12:45 AM, Robert Nelson <robert...@gmail.com> wrote:

On Sun, Dec 1, 2013 at 5:43 PM, Yasir K <yas...@gmail.com> wrote:
> Thanks Robert for helping out, the patch provided by cody fails, i wonder if
> anyone else has got it working and specifically under what conditions?

This is normal kernel patch backporting.. First compare
sound/soc/davinci/davinci-evm.c & sound/soc/davinci/davinci-evm.c.rej
and fix it up..

Robert,

It seems like you have already added the patch from Cody to your tree (patches/hdmi/0028-Make-the-McASP-code-generic-again-remove-all-hardcod.patch) that I believe Yasir is trying to apply. This seems to have been the only change from 3.8.13-bone29 to 3.8.13-bone30. So people that would like to try the audio patch from Cody should only have to compile your v3.8 branch and nothing else, correct?

Regards

Daniel

[Yasir K]

Daniel,

Thanks for the pointer, i was able to bitbake the 3.8 kernel (using Derekś tutorial) with the patch applied to the Angstrom / cloud9 recipe. The sound is clear and consistent! Thank you all for the help. I will continue to try to get this working on uBuntu using Robertś scripts...

its been weeks in the doing, finally made it. :)

YSK

[lukasz.jan...@zylia.pl]

Hello,

I run AudioCape with 3.8.13-bone31 kernel without any modification of patches and it works fine now, so I can confirm the problem of audio quality seems to be resolved.

BR,

Lukasz

[kevind]

I can run the AudioCape with 3.8.13-bone32 kernel booting from the uSD card, and the audio works fine (image file BBB-ubuntu-13.10-2013-12-17-4gb.img.xz).

 

However, using same kernel booting from the internal eMMC, the audio doesn't work (image file BBB-eMMC-flasher-ubuntu-13.10-2013-12-17-2gb.img.xz).  It acts like it should be working, but no sound comes out.  Doesn't make sense but that's what I'm seeing.

 

-Kevin

[kevind]

My mistake, it works when booting from eMMC also.  I had to crank up the "HP DAC" setting in alsamixer to get any sound to come out.

[r...@igong.co]

For anybody like me, vaguely understanding what's going on, and ending up here: I built 3.8.13-bone39 from Robert Nelsons github site. A slightly modified version of cody's patch above is already applied. All you need to do is enable the audiocape in uEnv.txt (my cape is Rev 1A), by adding this line (or adjusting your optargs line, of course):

optargs=capemgr.enable_partno=BB-BONE-AUDI-01

HDMI audio is automatically switched off (no need to disable HDMIN) when the cape is detected. The display continues to work.

Nice, and big thanks to all who made this work! 

Now I'll have to find out why ethernet doesn't work if a usb-keyboard is attached, why lsmod doesn't produce any output, and if I can attach a usb sounddevice ;)

Best

.r.

On Thursday, 2 May 2013 05:46:47 UTC+1, Robert Twomey wrote:

Hi, 

I'm looking for a dependable stereo audio in / out solution for the Beaglebone Black. 

I see in this thread the suggestion of using a cheap USB soundcard. However, I've had little luck with cheapo usb audio cards on the raspberry pi. I'm worried that it won't work with this system. 

With the rPi I've been using a C-Media chipset USB audio cards from amazon (http://www.amazon.com/Syba-SD-CM-UAUD-Adapter-C-Media-Chipset/dp/B001MSS6CS/ref=sr_1_1?ie=UTF8&qid=1367469801).

I hope maybe the Audio Cape is a better option for me...

I see the DVI-D Audio cape is listed as "incompatible": http://circuitco.com/support/index.php?title=BeagleBone_Black_Accessories#Capes

Has anyone tried the Audio Cape with the BBB? 

If not, can you recommend a make or model of USB sound card that worked for both input and output?

Thanks very much!

Robert

[sns]

does using this audio dongle allow to record sound with microphone without biasing?

On Saturday, May 4, 2013 at 5:04:28 AM UTC+5:30, Carl Johnson wrote:

I have an audio cape that worked well with the original BeagleBone, although I'm struggling to get it to work with the BeagleBone Black.  I'm running the latest 3.8.11 Angstrom release, and the logs show that it loads the device tree OK but for some reason it isn't recognized as an alsa device.  I'll post an update if I get it working.

I'm also using this audio dongle on the BeagleBone Black, which works quite well in alsa.  It only has a mono microphone input though.

[Carl Johnson]

I used a MAX9812 amplifier chip and an electret condenser microphone.  Works really well.

--
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/ZJGwxA7BG4E/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Zainab S.V]

But, do we have to manually solder this amplifier and mic?I mean, is there any prebuilt device that amplifies the mic-recorded signals?

[Carl Johnson]

I did a quick google search and nothing obvious jumped out. You might be better off using a USB microphone, which are cheap and readily available.

[Zainab S.V]

How to use max9812 amp with mic (one in the headset)?

[Carl Johnson]

Why not try a USB headset?  These are also inexpensive.

[Zainab S.V]

Does connecting a usb headset to beaglebone  support audio recording and playback via HDMI audio interface? I think it only supports audio out. Is it so?

[Jesse Cobra]

USB audio and HDMI audio are separate things entirely...

USB in and out

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.

[sns]

For recording voice, does usb headset's mic work well?Does it have the appropriate pre amp to amplify the voice signals?