Capture channels in amixer

[thmsmlt]

I've made great progress :)

My custom hardware gets recognised, but the amixer command yields some surprising settings.

How are the capture channels configured? I'm getting two ADC's as expected, but they seem to be configured as playback channels and the four DAC channels seem to be configured as both playback and capture channels.

Is this normal?

Also, all inputs and outputs seem to be permanently off, I've tried changing this with numid cset ... but my commands seem to be ignored... What is the regular way to make these work? Might be a fault in my hardware too ;)

[henrix]

Yes, that's a bit strange of alsamixer, but you can ignore it. You can unmute the single ADCs and DACs with amixer (e.g. amixer -c 0 sset DAC1 on).

[thmsmlt]

So should I ignore the playback/capture labels or the ADC1 and ADC2 labels and record using the DAC capture thingies?

[thmsmlt]

Also do you recognise this error:

arecord: pcm_read:2031: read error: Input/output error when trying to record...

• When I try to activate an ADC or a DAC, my command is processed, my terminal shows that the switch is on, but when I run amixer again, it's already back off again... Has this happened to you at some point?

[henrix]

Ignore the playback/capture labels. The names are correct (e.g. ADC1 corresponds to the first hardware ADC). Maybe you have some SPI issues. You can check the kernel logs (my driver logs the register contents of the codec) for verification.

[thmsmlt]

I am indeed having SPI connection issues, I hooked the board up to an oscilloscope and the SPI lines are all high (except the Cout one, which is 0), but no commands are executed, no matter which command I run, the lines stay high. Are there additional steps to be taken to activate the SPI-connection? Something with pin modes? I'm pretty new to Linux and Beaglebone... I'll take a look at those kernel logs.

[henrix]

No, the pin modes are configured with the device tree overlay. Do you use the hardware SPI interface or software spi (spi-gpio)? If you playback or capture something, there should be something happening on the SPI interface (e.g. speaker-test).

[thmsmlt]

My SPI wires are connected to pins 17, 18, 21 and 22, so I guess I'm using hardware SPI. (Right?) I'm trying to write to the SPI port now using Adafruit_BBIO, just to see if I can connect to the codec.

[thmsmlt]

The kernel log did reveal some errors...

[henrix]

Have a look in the pin connections table. You are using the hardware SPI interface, so you have to use the BB-CTAG-FACE-8CH overlay.

[thmsmlt]

Right! And I'm trying to load the SW-overlay. Well that wouldn't work indeed.

Well, I just tried changing that, but when running

sudo sh -c "echo 'BB-CTAG-FACE-8CH' > /sys/devices/platform/bone_capemgr/slots"

This error comes up:

sh: echo: I/O error

Or am I doing that wrong? When I rebooted, the BB still tried to load the SW-overlay.

Or should I just change the pin configuration I'm using to the other one? In that case, what is the difference between spi4 and spi5?

[thmsmlt]

Oh, I fixed the error, I had to remove the SW-overlay first in capemgr:

sudo sh -c "echo '-4' > /sys/devices/platform/bone_capemgr/slots"

Unfortunately, the Beaglebone still stried to load the SW-overlay, the slots directory is the same when rebooting even when having deleted entry -4 as indicated above...

[henrix]

I think there is any issue in the Cape manager. If you are using my image, you should disable the automatic loading of the SW SPI overlay and load the BB-CTAG-FACE-8CH instead.

[thmsmlt]

I've tried to do so, but my changes seem to be reversed immediately... Is my code in the previous messages correct?

[henrix]

You remove overlays from the Cape manager with your code above. Have a look in /etc/rc.local and change BB-CTAG-SW-8CH to BB-CTAG-FACE-8CH.

[thmsmlt]

Well, I did those things now, the good news is: when running cat /sys/devices/platform/bone_capemgr/slots, BB-CTAG-SW-8CH is no longer loaded at boot.

The bad news is: BB-CTAG-FACE-8CH doesn't load in int's place and in the kernel logs, the errors remain the same

[henrix]

Ok, can you please show your kernel logs regarding the sound drivers?

[thmsmlt]

It works!

It was a hardware thing. I was searching around in the lab and found that the PCB track connected to the PD/RST pin was broken. I fixed it and now the interface works :)

Many thanks for the help!

But before closing the subject entirely, I'm recording, I turned on the ADC's but the recorded file is still empty, it must be something small, I measured my codec's inputs and I'm putting a 440 Hz wave on there...

Also when recording with 4 channels, hundreds of files are created, all silent, but 5 seconds long..

[thmsmlt]

This is the kern.log file for my last bootup

log.txt

[henrix]

The issue with the several files is regarded to alsalib. Have a look here to avoid this.