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

[vix]

Hi @bruno.tx
based on my tests I can say that playing a silent sound has an impact on solving the issue.
But the situation is not 100% clear.
I need some further investigation, but it sounds strange to me that Ubuntu suffer of such a weird behavior.
But it seems so.

[bruno.tx]

Hello @vix,

This seems to be an Alsa issue.
Here you can see a similar problem with a desktop application.
It is possible that the problem can be avoided by using pulseaudio instead.

Best Regards,
Bruno

[vix]

@bruno.tx

It is possible that the problem can be avoided by using pulseaudio instead.

Can you point me to doc describing how to do this in Torizon?
As the final step, I need that the sound plays from a chromium container

[bruno.tx]

Hello @vix,

From some limited testing, using pulseaudio with chromium does not appear to be the simplest thing to do, at least when starting from our chromium container.

Do you also have this audio playback issue when playing audios from Chromium?
If yes, we can look into the possibility of using pulseaudio as an alternative.

Best Regards,
Bruno

[vix]

@bruno.tx

Do you also have this audio playback issue when playing audios from Chromium?

Yes, I saw the issue in Chromium.
Then I started to test the OS itself to narrow down if the issue comes from the OS or from the container.

[bruno.tx]

Hello @vix,

Noted, I will look into this topic then.
Once there are updates, I will send them here.

Best Regards,
Bruno

[bruno.tx]

Hello @vix,

Upon further investigation the chromium package we provide is built with a hard dependency to alsa.
Using it with pulseaudio will require chromium to be rebuilt with support for pulseaudio.
Therefore, I would recommend that you use the silent audio workaround if possible.

Best Regards,
Bruno

[vix]

@bruno.tx

I would recommend that you use the silent audio workaround if possible.

An acceptable workaround is to play a silent sound (at least 150 ms long) before the sound.
This can be done in two different ways:

1. running aplay -d 1 silence_150ms.wav && aplay ding.wav
2. playing a file ding.wav that starts with 150 ms of silence

[bruno.tx]

Hello @vix,

Thanks for the update.

Best Regards,
Bruno