• CTAG-ALSA
  • CTAG face support in Linux 5.x kernel

giuliomoro looking at your overlay, is there a delay of 1 for the McASP controller and another 1 for the interface (making a total delay of 2?). It does seem that the overlay would be the way to make this work. Reviewing the driver kernel code in the BB and TI kernels there’s not much difference (I notice the _priv struct is slightly different).

My approach is based (following in parallel what you’ve been doing) on using buildroot to create a very small firmware for my project, removing all the unessary items/modules etc as I only need Ethernet and CTAG and GSTreamer plus ALSA.

Ideally I’d have the CTAG driver compiled in not as a module.

    siraaris ooking at your overlay, is there a delay of 1 for the McASP controller and another 1 for the interface (making a total delay of 2?).

    As mentioned, I think many of the entries in the dtb are ignored. I could not manage to generate any difference on the McASP side (i.e.: observable changes in the delay between frame clock and data) or on the codec side (i.e.: observable changes in the registers set by the driver (as printed or changes in the analog signal generated by the DAC) when changing any of ti,audio-codec-bit-delay-dac or ti,audio-codec-bit-delay-dac = <1>. Inspecting the driver's source I don't see where those would be read anyhow and - interestingly - inspecting the commit log (-p) of the relevant files doesn't show me these have ever been used anywhere (as far as I can tell).

    siraaris Ideally I’d have the CTAG driver compiled in not as a module.

    Even when it is, you should still be able to bind/unbind it if needed, i.e.::

    echo  "ocp:bone_sound" | sudo tee /sys/bus/platform/drivers/snd_ctag_face_2_4/unbind
    echo  "ocp:bone_sound" | sudo tee /sys/bus/platform/drivers/snd_ctag_face_2_4/bind

    (I think). But sure it would be best to just fix the driver so it doesn't require this step.

    17 days later

    Just a quick note, I spent some time getting a Yocto setup working with 5.10-ctag-hacks. Had to combine the CTAG overlay into the device tree am335x-boneblack.dts as I couldn't get loading of DTBO's working.

    Did a very quick test, and confirm driver loading, and aplay/arecord seem to behave as expected on initial inspection.

    I think that I'll be able to progress with the POC and get a better sense and actual listening of the project during the end of year break - thank you.

      siraaris I couldn't get loading of DTBO's working.

      That's normally done in uboot.

      a year later

      I've been trying to follow along. I've compiled new kernel modules for the BBB bullseye release 11.7 with the 5.10-ctag-hacks and the API changes.
      If I don't include the DTBO overlay in the eEnv.txt then the sound card shows up in ALSA but its not really working.
      If I actively enable the DTBO overlay the in uEnv.txt the sound card doesn't show up at all in ALSA.

      @siraaris It seems you got things working. I understand you integrated the CTAG overlay into the device tree am335x-boneblack.dts, correct? Is there any way you could share you merged device tree file?
      Did you have to make further changes to the driver/codes as proposed by giuliomoro ?

        amessner If I don't include the DTBO overlay in the eEnv.txt then the sound card shows up in ALSA but its not really working.
        If I actively enable the DTBO overlay the in uEnv.txt the sound card doesn't show up at all in ALSA.

        can you show the content of uEnv.txt in either cases?

          giuliomoro
          I've attached the uEnv.txt where I see a sound card in ALSA but it doesn't actually use the device tree overlay for the CTAG face -> uEnv_original.txt
          I can run "speaker-test -D hw:0 -c 2 -r 48000 -t sine -f 1000" (please note channel count 2). If I try any higher channel count it doesn't work. And even with 2 channels I don't hear anything on any of the CTAG outputs.

          I've tried multiple configurations, the last one I tried is actually taken from one of your earlier posts. With this uEnv.txt I don't see a sound card in ALSA at all -> uEnv.txt.

          I found that adding the device tree overlay for CTAG to the uEnv.txt OR disabling any of the overlays for video, audio, etc will cause the sound card to disappear

          uenv.txt
          2kB
          uenv-original.txt
          2kB

          .

          OK I managed to have a look at this. You need this branch in /opt/sources/dtb-5.10-ti and then do make && sudo make install to put the update base device tree and overlay in place. At that point those will be loaded OK, but no soundcard will appear because the driver is not there and so you need to build and install the driver, as you can tell because modprobe snd-soc-ad193x snd-soc-ad193x-spi snd-soc-davinci-ctag-face-2-4 fails. I have not repeated the build and install procedure because it should be the same as previously and also I don't have machine to build it on with me right now, but hopefully you can.

          Thank you @giuliomoro.

          @amessner based on the above activity I dug out my BBB/CTAG and am going to attempt to rekindle where I got to previously - might be a week or so.

          Ok I made some progress.

          I used the latest Bullseye Image for the BBB (kernel 5.10.168-ti-r72) as a base.
          Then patched (https://github.com/anbraten/beagle-bone-builder/tree/master/resources/ctag-2.4) and compiled the drivers for snd-soc-ad193x, snd-soc-ad193x-spi and snd-soc-davinci-ctag-face-2-4, copied them over and confirmed that they load.

          Then I updated the uEnv.txt (see uEnv.txt of my last post)

          Now I can play sounds on 2 channels, but not on the other 6.
          If I try recording something it also doesn't "really" work. Sometimes I get a very noisy file, sometimes nothing.

          Did anyone get as far as to record something successfully? Or did you just test by playing back a test wav file?

          @giuliomoro if I try to use your device tree branch then the image won't even boot anymore.

            I won't be able to have another look until some point next week.

            amessner if I try to use your device tree branch then the image won't even boot anymore

            to troubleshoot that you'd need to get a serial log from the UART0 port on the BBB.