alsamixer issue with 2013.07.31 image

Alsamixer worked fine with the previous image. I just upgraded to the 2013.07.31 image and now alsamixer isn’t working properly. It used to have a colored display, and now it’s all just white. While I can get past that aesthetic issue, the main problem is that no Function keys work anymore. Any time I press an ‘F’ key to access menu functions in alsamixer, it just closes and echos the code of the key. For example, pressing F3 echos “13~” at the terminal. This is a brand new image upgrade using the steps on this page which is the same process I always have used successfully in the past. I’m using the same FTDI cable and the same PuTTY profile as I always have. The only thing I did after the re-flashing process was to change the uEnv file.

Additional details:
The LCD4 cape is attached. An audio cape equivalent cape (no eeprom) is attached. My uEnv:

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

I have to disable the LCD4 for now because (as mentioned in this thread) it has a pin conflict that causes the audio cape to not be loaded.

I have a USB audio dongle (PCM2902E chipset) plugged in and arecord -l shows:

**** List of CAPTURE Hardware Devices ****
card 0: EVM [DA830 EVM], device 0: AIC3X tlv320aic3x-hifi-0 []
Subdevices: 1/1
Subdevice #0: subdevice #0
card 1: CODEC [USB Audio CODEC], device 0: USB Audio [USB Audio]
Subdevices: 1/1
Subdevice #0: subdevice #0

Is anyone else having this issue?

Also slightly related: Is it possible to create a ‘pin overlay’ (dts) file format where one can specify which pins can be successfully shared (like LED or I2C pins) without aborting the entire cape driver loading process? I haven’t really looked into that at all, but by the looks of things that would be very helpful for compatibility when using more than one cape.

Can someone with a 2013.07.31 image on a BBB type “alsamixer” at a terminal prompt and reply back here with the results of pressing a Function key (F1, F2, etc.) after the program starts? Does it [quit] or [work properly]? Since I was using a brand new reflash I assume it will be bugged for everyone. If not I guess I’ll just try re-flashing again.

Just reflashed with the 2013.09.04 image and have the same problem. Steps to reproduce:

  1. Using an “A5A” BeagleBone Black. Using PuTTY on a Windows 7, 64 bit PC with a USB-serial FTDI cable, (PuTTY settings: 115200 baud, others default).
  2. Reflash the eMMC with (the most recent image as of this writing) using the instructions on
  3. After flash, power down and SD card removal, plug in 5v DC power source to DC jack (only the DC power source and the serial debug cable are plugged in) and allow to boot to Angstrom prompt.
  4. Type “root” to log in.
  5. Type “alsamixer” to run the alsamixer application.
  6. Press “F1” to get to the “help” menu.
  7. The application will exit and “11~” will be written to the terminal prompt instead of the Help menu. This problem also occurs with any of the Function “F” keys.

Is there an official place where I can submit this bug report where it will be found by the correct people who have the ability to fix the problem?

It is found on the Support Wiki.



Are you referring to I have posted the bug report there. However, after looking more closely it doesn’t seem as though anyone is actively working on those issues. There have only been two closed issues, and both were solved by the same person who submitted them in the first place. Am I looking in the wrong place? Thanks.

No, that is the official place.