• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 98 subscribers
  • Views 1855 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

How to access two TLV320AIC3x codecs with ALSA on AM335x

Craig Leeds
Intellectual 330 points
Other Parts Discussed in Thread: TLV320AIC3104

I have a Beaglebone black with two modified Circuitco audio Rev B capes on it.  They have been modified so that one uses I2C1 and McASP0 and the other uses I2CS and McASP1.  I want to be able to access both capes with ALSA.  I am running Debian Wheezy beaglebone 3.8.13-bone73.  Both capes have a TLV320AIC3104 which has a fixed i2c address of 0x18, but since they are on separate I2C busses, they should not conflict.  I have created 2 new dts files based on the kernel's BB-BONE-AUDI-02-00A0.dts.  They are attached in this post.  I compiled them and put the .dtbo files on /lib/firmware.  I have added them to /etc/default/capemgr as follows:

   CAPE=BB-BONE-AUDI-03,BB-BONE-AUDI-04

When I reboot, I do see that the pingroups for both capes is correct using:

    cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pingroups

But when I look at the devices that ALSA sees via "aplay -l" or "aplay -L", I only see the one from the first cape defined in /etc/default/capemgr.  When I run aplay, I do successfully play the sound on the cape defined by BB-BONE-AUDI-03.dts.  And I can adjust the volume with  alsamixer, proving the I2C connection is working properly.  If I reverse the order of the capes in /etc/default/capemgr like this:

     CAPE=BB-BONE-AUDI-04,BB-BONE-AUDI-03

then ALSA only sees the cape defined by BB-BONE-AUDI-04.dts.  Again, I can play music on that cape and adjust the volume with alsamixer.  So that means that the different McASP connections and I2C connections are working.  I just can't get them both to work in tandem.  If I plug in a SoundBlaster USB sound card, ALSA does see an AIC3104 codec plus the SoundBlaster.  And I can access both of those together.  But I can't yet get ALSA to see both AIC3104 codecs.

I have been looking at the customer support sites, and I have seen descriptions of how to handle multiple USB sound cards.  But I've seen nothing about how to handle multiple on-chip peripherals.  We are in the process of building a board with the AM335x with two TLV320AIC3014 codecs, and I need to be sure that I can access both of them with ALSA.

Any advice would be much appreciated.  I don't mind having to modify the kernel.  I've already had to make a couple of small changes to it.

Thank you.  Craig

3021.multipleAIC3104codecDtsFiles.zip

  • 0
    TI__Guru**** 393215 points
    Hi,

    I will forward this to the SW team.
  • 0
    TI__Guru**** 161600 points
    Hi Craig,

    Could you please share how do you call both dts files at the same time?

    Have you tried, to change the numbering of the fragment dts nodes & call both of these dts files(?), i.e. include them in your top level dts:
    #include "BB-BONE-AUDI-03-00A0.dts"
    #include "BB-BONE-AUDI-04-00A0.dts"

    This should tell your kernel to register both audio codecs.

    Best Regards,
    Yordan
  • 0 in reply to Yordan Kovachev
    Intellectual 330 points

    Yordan,


    Thank you for looking into this.  With the debian wheezy since at least 3.8.13-bone70, dtbo files are included in the kernel in a different way.  So I added BB-BONE-AUDI-03-00A0.dts and BB-BONE-AUDI-04-00A0.dtbo to  KERNEL/lib/firmware/Makefile just after BB-BONE-AUDI-02-00A0.dtbo.  They were successfully built into the kernel.

    Then in /boot/uEnv.txt, I editted it as follows:

    cape_disable=capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN

    cape_enable=capemgr.enable_partno=BB-UART1,BB-BONE_AUDI-03,BB-BONE-AUDI-04

    If I cat /sys/devices/bone_capemgr.9/slots, then I see that BB-BONELT-HDMI and BB-BONELT-HDMIN have been removed, and that BB-UART1, BB-BONE-AUDI-03, and BB-BONE-AUDI-04 have been added. 

    Also, if I cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pingroups, then I see that all the pins in the added dts files were successfully added.

    But if I type "aplay -L" or "aplay -l", then I only see the device from BB-BONE-AUDI-04.  And when I use aplay to play a file, that's where it comes out.  If I reverse the order BB-BONE-AUDI-04 and BB-BONE-AUDI-03 in the cape_enable of uEnv.txt, then aplay -L and aplay -l only see the device from BB-BONE-AUDI-03.  And when I use aplay to play a wav file, it comes out on the device defined by BB-BONE-AUDI-03.  I have also checked alsamixer in both cases, and I can control the volume when I play a file using it, which means the I2C pins are correctly configured.


    There is one anomaly that makes the reversal of order of capes not orthogonal, though I think that it's a red herring.  It's when I run "aplay -l" when BB-BONE-AUDI-04 is last.  Here is the log:

    root@beaglebone:~# aplay -L

    null

        Discard all samples (playback) or generate zero samples (capture)

    default:CARD=AIC31042

        AIC3104_2,

        Default Audio Device

    sysdefault:CARD=AIC31042

        AIC3104_2,

        Default Audio Device

    root@beaglebone:~# aplay -l

    **** List of PLAYBACK Hardware Devices ****

    card 0: AIC31042 [AIC3104_2], device 0: AIC3104_1 tlv320aic3x-hifi-0 []

      Subdevices: 1/1

      Subdevice #0: subdevice #0

    Notice how device 0 is "AIC3104_1" instead of "AIC3104_2".  The wave file still plays out on AIC3104_2 and it uses the I2C pins for AIC3104_2.  But there does seem to be some conflicting values within ALSA.

    At this point, I don't know if I need to modify the kernel, modify ALSA, or if there is some simpler way to get ALSA to recognize that there really are two audio devices like are defined in the slots.

    Again, thank you for your help.

    Craig

  • 0 in reply to Craig Leeds
    Intellectual 330 points
    I have found the solution with the help of Jason Reeder in his post in e2e.ti.com/.../1651392

    I modified the two dts files so that the sound fragments no longer conflict:

    One sound fragment now starts like this:

    fragment@3 {
    target = <&ocp>;
    __overlay__ {
    sound0: sound@0 {

    And the other sound fragment starts like this:

    fragment@3 {
    target = <&ocp>;
    __overlay__ {
    sound1: sound@1 {

    The solution was easy, but I never was able to find any documentation on the device tree for an ocp sound fragment.

    I now can access both codecs with alsa.

    Craig