Amixer control with Verdin IMX8M-Plus

[vix]

Hi everyone,
I’m facing an issue playing audio with my verdin imx8m-plus.
Currently I have the following setup:
I have an application running on a container
(in the dockerfile I install alsa-utils libasound2 libasound2-plugins)

and copying the following asound.conf file in /etc/asound.conf

pcm.dmix0 {
  type dmix
  ipc_key 1024
  slave {
    pcm "hw:0,0"
    period_time 0
    period_size 1024
    buffer_size 8192
    rate 44100
  }
  bindings {
    0 0
    1 1
  }
}

pcm.!default {
  type plug
  slave.pcm "dmix0"
}

then I run the container passing
ALSA_CARD: audiohdmi
and play audio via
aplay ./path/to/file.wav
This works but if I run the same audio (for example) one time per second, the volume is unstable (sometimes is high, sometime is low).

I’m trying to control the volume of the sound card using amixer.
I’m not able to control the volume of the sound card.

running amixer scontrols and amixer scontents gives me empty output.
running alsamixer -c 0 gives me the following:

How can i control the volume of the sound card? Or, more in general, how can make my audio volume stable?

Thanks

[ToradexAI]

Hi, I’m the Toradex AI Assistant. The Toradex Support team will follow up with you shortly!

Did you like my answer?

---

Based on the context provided, here are some steps you can take to address the issue of unstable audio volume and the inability to control the volume using amixer on the Verdin iMX8M Plus:

1. Verify ALSA Configuration:

   • Double-check your asound.conf file to ensure it is correctly configured for your specific audio hardware. The dmix plugin is used for mixing multiple audio streams, but ensure that it is properly set up for your use case.

2. Audio Card Recognition:

   • The empty outputs from amixer suggest that the sound card might not be properly recognized. Ensure that the ALSA_CARD environment variable is correctly set to the appropriate audio card. You might need to verify the actual card name or number using aplay -l to list all sound cards and devices.

3. Driver Compatibility:

   • Check if the necessary audio drivers are installed and loaded correctly for the Verdin iMX8M Plus. There might be a compatibility issue with the drivers that could affect volume control.

4. Test Outside Container:

   • Try running the audio playback and volume control commands outside of the Docker container to see if the issue persists. This can help determine if the problem is related to the container environment.

5. Alternative Audio Management Tools:

   • Consider using other audio management tools or libraries that might offer better control over audio playback and volume stabilization. For example, PulseAudio or PipeWire might provide more robust solutions for managing audio in a containerized environment.

6. Hardware and Software Updates:

   • Ensure that your system is up to date with the latest firmware and software updates from Toradex, as these might include fixes or improvements for audio handling on the Verdin iMX8M Plus.

By following these steps, you should be able to better diagnose and potentially resolve the issue with unstable audio volume and lack of volume control.

Please, also check if these links can help you solve your problem:

Audio with Yocto and the iMX8M Mini

Hello, I have a Verdin iMX8M Mini on a Dahlia Carrier Board Rev 1.1. I use Yocto and I have been trying to play and record audio following this: Audio (Linux) | Toradex Developer Center Using the Easy Installer, I used the Multimedia Reference Image and tried some of the steps, but nothing seems to work properly: root@verdin-imx8mm-06898530:/# aplay -L null Discard all samples (playback) or generate zero samples (capture) sysdefault:CARD=imx8mmnau8822 imx8mm-nau8822, Default Audio…

TI AM62 Computer on Module - Verdin AM62.

[vix]

Is there any feedback here?

[henrique.tx]

Hi @vix !

Sorry for the delay.

I didn’t have time to check this and, to be honest I will need more time to be able to check.

Are you using Torizon OS? Or it not Torizon OS? Which specific version of Torizon OS/BSP are you using?

And how urgent is this for you?

Best regards,

[vix]

Hi @henrique.tx ,
Thanks for the response.
Of course I’m using Torizon OS, sorry for missing it.
“6.8.0” quarterly build-number: “22”

It’s quite urgent to be transparent…

thanks

[bruno.tx]

Hello @vix,

I tested this here and got to the following conclusions:

• The HDMI audio does not provide a volume interface for alsamixer. This is likely due to the fact that digital audio is being transmitted and the volume control is expected on the display.
• The audio from the display was at a consistent volume when playing the same file repeatedly.

How are you playing the audio one time per second?
Maybe we are doing something slightly different here.

Best Regards,
Bruno

[bruno.tx]

Hello @vix,

While the variation in output between runs you see is still concerning, you can also add a software volume control with alsa.

Please try it with the following asound.conf:

pcm.dmix0 {
  type dmix
  ipc_key 1024
  slave {
    pcm "hw:0,0"
    period_time 0
    period_size 1024
    buffer_size 8192
    rate 44100
  }
  bindings {
    0 0
    1 1
  }
}

# Adding softvol
pcm.softvol {
  type softvol
  slave.pcm "dmix0"
  control {
    name "Master"
    card 0
  }
}

pcm.!default {
  type plug
  slave.pcm "softvol"
}

You should see the new control on alsamixer:

Best Regards,
Bruno

[vix]

Hello @bruno.tx
I confirm that with your asound.conf I can see the control on alsamixer as in your picture.
I’m able to change the volume with both the alsamixer UI and amixer set Master 100% command.
So, basically, the volume can be controlled.
I try to describe with different words what is the issue, with a simple scenario:

• if you play a sound, everything is ok (the volume is what it should be)
• if you use a script to play the same short sound 3 times every 1" (1 second), the volume is wrong. Most of the time the volume of the first sound is higher (or lower) than the others.

And this is frustrating.
This is the bash script to play the spound (from a container with alsa installed inside):

for i in {1..3}
do
    aplay ./public/sounds/ding.wav &  
    sleep 1                           
done

And this is the file

with the sound to be played.

Are you able to reproduce the issue in this way?

[bruno.tx]

Hello @vix,

I was able to reproduce a similar issue.
The first time the audio is played, it seems that the HDMI audio has not initialized yet, so the beginning of the file gets cut.
This makes it seem that the sound is quieter, but we are just getting the quieter part of the audio.

The cause here is not clear, and seems to be present in other systems.
It may be worth testing with pulseaudio as well.

A workaround that I tested was to play a silent audio file before playing the actual file:

aplay -d 1 silence_10s.wav && aplay ding.wav

Adding a silent part at the start of the file should also do the trick.

Best Regards,
Bruno

[vix]

Hi @bruno.tx
thank you.
Do you know how long the silent audio should be?

[bruno.tx]

Hi @vix,

My test above uses 1 second.
But my impression is that 0.5 seconds should be enough, but testing this precisely would be recommended.

Best Regards,
Bruno