PCM2912A: aplay error

Hi,

What sample rate are you intending to record at? Are you able to see the device in i2cdetect? Can you give a register dump, and can you provide the DTS file? These errors could mean a number of issues but I would expect it means that the device may be being used by another process on the system, and checking if you can see the device in i2cdetect (without the UU as the address) would give a hint there. Have you been able to run this command before with no issue? 

Best,
Mir

Thanks for your reply ！

We are not using the microphone function but simply using the PCM2912A as an audio decoding device to drive speakers. Since the PCM2912A is a USB bus device, why check the connection status of the I2C bus? Regarding your statement about "the device may be being used by another process on the system," we simulated this scenario, and the output from the `aplay` process showed either "device busy" or "device not found," rather than “input/output errors”.

Ok, I see it is USB only so there is no I2C and no measurable I2S clocks. Can you attach a schematic and your DTS file? I wonder if the device is not getting the required input clock.

Best,
Mir

This is the circuit schematic diagram of the sound card circuit! Our device uses an x86 hardware platform and does not have a device tree file.

Hi,

Looks good. Maybe the issue is that your computer is not set to the correct sample rate - can you check to make sure that you are recording at one of these supported sample rates, at 16 bits?

You would set this in your aplay command, and if you are running Linux with a GUI on the OS you could check in the audio settings to make sure that the rate is 44.1kHz or 48kHz, and 16 bits.

Best,
Mir

Hi，

The audio file we need to play is a fixed file. By using the soxi command to check the file's properties, we confirmed that it is 16-bit, has a sampling rate of 44100Hz, and has 2 channels. When we use the aplay command, we do not specify the sampling rate; instead, the system automatically identifies it. Should this not cause any additional issues?

Hi,

Can you run aplay -f S16_LE -r 44100 ?

Also, can you run aplay -l to list the hardware devices? Let's make sure it is being identified correctly.

Best,
Mir

Hi，

Hi,

The issue happening at random intervals until rebooted sounds more like it may be a power issue. I looked closer at your schematic and I have a few notes, if you change these things I hope this issue will stop:

- make sure that if you are separating analog and digital grounds that they are connected at a central point, for example under the chip
- VIN should not be connected to VCCA, this is the analog input for a microphone signal
- change the VCOM1 decoupling capacitor to 10uF and VCOM2 decoupling capacitor to .1uF 

Let me know what happens when you change this.

Best,
Mir

Hi,

Thanks for your suggestions! I'll give them a try later and let you know the results.

Hello,

regarding the several suggestions you mentioned earlier, I have a few questions: Firstly, are the issues I reported related to the suggestions you mentioned? Secondly, although this problem has occurred multiple times on the client side, we have consistently failed to reproduce it internally. If we make the proposed changes but still cannot reproduce the problem, this will not help us locate and analyze the true cause of the issue.

Hello,

regarding the several suggestions you mentioned earlier, I have a few questions: Firstly, are the issues I reported related to the suggestions you mentioned? Secondly, although this problem has occurred multiple times on the client side, we have consistently failed to reproduce it internally. If we make the proposed changes but still cannot reproduce the problem, this will not help us locate and analyze the true cause of the issue.

Hello,

regarding the suggestions you mentioned earlier, I have a few questions: First, is the issue I reported actually related to your suggestions? Second, although this problem has occurred multiple times on the client side, we have been consistently unable to reproduce it internally.

If we implement the changes but still cannot replicate the issue, this would not help us pinpoint and analyze the true root cause of the problem.

Hi Yang,

Today is a holiday for our team in the U.S. We will follow up with you on Tuesday, Dallas time.

Best regards and thank you for your patience,
Jeff McPherson

Hi,

I was suggesting these changes in case it is a power issue - sometimes if there is a spike or dip in the power supply then there may be an issue with the chip, so I was suggesting decoupling capacitor changes for this. But, after some further research, I found maybe there there is an issue with the default card when you are having this issue - was the screenshot of aplay from when the device is erroring when you try to play? If the HDMI audio card, or any other connection to the Linux system with audio, becomes card 0, then it will have priority and maybe it will try to play on that card. When the issue is happening, can you specify which card is being used, and what cards are available on the computer? Check this post for some tips: https://askubuntu.com/questions/638978/unable-to-install-hw-params-usb-xmos-and-alsa

Best,
Mir

Hi，

On my device, there are indeed two sound card devices. One is card 0: HDA Intel PCH, and the other is card 1: USB audio CODEC. To ensure that the system always uses card 1 for audio playback, I added an asound.conf configuration file. The contents of this file are as follows:

When the issue first occurred, I checked the sound card devices using the aplay -l command and found no abnormalities.

Have you seen other forum posts about this as a Linux audio issue? I wonder if it is some Linux audio specific problem, if some other program is trying to run at the same time as ALSA or otherwise... https://forums.gentoo.org/viewtopic-p-3870230.html This is an interesting forum post I found, somebody said they uninstalled oss which helped, but there were many OSS modules present so it took them a while to narrow it down. Maybe you can try this, or see if you have other audio systems than just ALSA on your computer? Typically this sort of issue that you have been having is because your clocks were interrupted or the I2C line for the device is busy, but with this being a USB only device, the clocks will be more lower level with the computer rather than an external MCLK/BCLK/WCLK. So, it may be some other software/firmware level computer issue where some other program or IO line is trying to have priority over the USB audio line.

Best,
Mir

Hi，

I have searched a lot of web resources and indeed seen many feedbacks about similar issues, but the vast majority of them did not yield any positive results. On one hand, this problem is relatively rare and not considered a major issue; on the other hand, due to frequent updates of the Ubuntu system, many problems in older systems do not receive technical support. I have also come across the theory that other audio systems might be interfering with ALSA, with PulseAudio being mentioned quite often. However, I was unable to test this successfully, and on my device, the PulseAudio service is not started by default.

I wonder if you can list the running processes and kill them one by one until you don't have the unable to install hw params error. Or if you can try to plug into the device directly, no USB hub or any other USB devices. I am thinking it is either a hardware clocking or process busy issue. Let me know if you are able to try any of this if it works for you.

Best,
Mir

hi，

Thanks for your advice! I'll give it a try provided that I can reproduce the fault phenomenon!

Hi，you previously mentioned that "VIN should not be connected to VCCA, as this serves as the analog input for a microphone signal." I would like to inquire: if we are not utilizing the microphone function in practice, how should VIN be handled? Should it be left floating or grounded?

Hi,

You can leave it floating or grounded, grounded may be slightly better to help avoid any crosstalk or coupling into the device if the ADC is left on. If you turn off the ADC with I2C, it doesn't matter either way.

Let me know if you have any more questions! Did you get the aplay working more reliably?

Best,
Mir