This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TLV320AIC34: Runtime sampling rate change issue

Part Number: TLV320AIC34

Tool/software:

Hello team,

  We are using TLV320AIC34: codec in one of our embedded device, which runs yocto linux. Now we are facing an issue related to run time sample rate changing.

ex. suppose the codec is running with 48k sampling rate, then my application needs at that moment tries to configure to 8k sample rate that time errors are coming.

so like this on run time we want to configure codec to 48k to 8k or vice versa .. is it possible?

we have tried to give soft reset using reg no 0 and reg 1 but it is not happeneing .

presently codec running in 48k sample rate and i want to change it to 8k I use

arecord -D hw:1,0 -c 1 -r 8000 -f S16_LE | aplay -D hw:1,0 -c 1 -r 8000 -f S16_LE

 

Error : unmatched rate symmetry soc_pcm_params_symmetry :8000

ASOC soc_pcm_hw_params() failed (-22)

read write error

To change the sampling rate we need to reboot the device that time it will take. but we want runtime change of sampling rate frequency.

is there any way to reset the codec? or can we change like this runtime is it allowed? kindly guide us

  • Hi,

    Are you able to run I2C commands in your system? I2C commands can be sent during runtime. If you want to only change between 48k and 8k, you could use page 0 register 2, which divides the current reference sample rate by up to 6 to get a new ADC or DAC sample rate. You could divide 48k by 6 to give a new sample rate of 8k before you record at 8k. 

    Let me know if this doesn't help, we can try other methods.

    Best,
    Mir

  • i2cset -y -f 2 0x1a 0x0 0x0 -->page 0 select

    i2cset -y -f 2 0x1a 0x02 0xAA -->> for 8k sample rate

    then with i2cget we had read it back.yes reg values changing but no effect...

    then tried

    device is already in 48k sampling rate after that we are attempting to change to 8k

    arecord -D hw:1,0 -c 1 -r 8000 -f S16_LE | aplay -D hw:1,0 -c 1 -r 8000 -f S16_LE

    RecordingWAVE 'stdin:

    signed 16 bit Little Endian Rate 8000 Hz Stereo --> for recording no error but next when aplay is in pipe that time error

    Playing WAVE 'stdin' : tlv320aic3x-hifi:

    then also error is there from aplay side... aplay is referring older sampling rate only

    ASoC : unmatched rate sysmmetry: xxx.sai2:48000 - soc_pcm_params_systmmetry:8000

    signed 16 bit Little Endian Rate  ::8000 Hz streao

    tlv320aic3x-hifi: ASoC :  soc_pcm_params () failed (-22)

    aplay : set _params: unable to install hw params:

    ACCESS : RW_INTERLEAVED

    FORMAT: S16_LE

    SUBFORMAT: STD

    SAMPLE_BITS: 16

    FRAME_BITS : 32

    CHANNELS : 2

    RATE: 8000

    PERIOD_TIME: 67500

    PERIOD_SIZE: 540

    PERIOD_BYTES:7560

    TICK_TIME: 0

    Looks like aplay has not taken new sampling rate 8k it is still in 48k

  • Hi,

    I will get back to you tomorrow about this. Sorry about the delay.

    Best,
    Mir

  • Hi,

    What happens when you run "aplay -L"? This will list your input and output channels. It seems like with your error that the driver is not being registered for the hardware channel you selected (hw 1,0), or maybe ALSA is getting stuck on a different process in the computer. Following this thread: https://bbs.archlinux.org/viewtopic.php?id=259785 they found that if they installed pulseaudio and pulseaudio-alsa and then updated the packages in their system, it worked... maybe this will help? Your issue does not seem like an issue with the codec itself and instead an issue with your ALSA setup. One more issue might be that your audio file that you are trying to play is not a multiple of 8k sampling rate. Let me know what you figure out and what happens when you list your ALSA audio devices. 

    Best,
    Mir

  • It has listed... tlv as card 1

    ----------------------------------------------------------------------------------------------------------------------

    root@evk:-# aplay -L

    null

    Discard all samples (playback) or generate zero samples (capture)

    pulse

    PulseAudio Sound Server

    sysdefault:CARD=D30030000saisnd

    30030000.sai-snd-soc-dummy-dai, 30030000.sai-snd-soc-dummy-dai snd-soc-dummy-dai-0

    Default Audio Device

    sysdefault:CARD-tlv320audio

    tlv320-audio, 30020000.sa12-tlv320a1c3x-hifi tlv320a1c3x-hifi-0

    Default Audio Device

    root@evk:-# aplay -l

    *List of PLAYBACK Hardware Devices **.

    card 0: D30030000saisnd [30030000.sai-snd-soc-dummy-dai), device 0: 30030000.sai-snd-soc-dummy-dai snd-soc-dummy-dai-0 [30030000.sal-sm

    Subdevices: 1/1

    Subdevice #9: subdevice #0

    card 1: tlv320audio [tlv320-audio], device 0: 30020000.sai2-tlv320a1c3x-hifi tlv320a1c3x-hifi-0 [30020000.sa12-tlv320a1c3x-hifi tlv3208.

    Subdevices: 1/1

    Subdevice #9: subdevice #0

    ------------------------------------------------------------------------------------------------------------------------

    if I use one fixed single sampling rate 48k or 8k there is no issue at all..

    For my application there is a requirement to change sampling rate on demand at run time from 48k to 8k or vice versa.

     

  • Hi,

    Thanks for this. I wonder what happens if you keep the I2C commands to change to 8k sample rate but in the aplay command you keep it at 48k? It seems like the driver does not support changing the sample rate at runtime. So, aplay does not notify the device to run at a different sample rate and maybe the clocks don't work as you expect. But, if the I2C command works, then the codec will only expect clocks 6x slower than 48k, but maybe it will still work to record but only will get every 6 samples... you may end up needing to edit the files and throw out 5 of every 6 samples. Let me know what you figure out with this. 

    Best,
    Mir

  • Sorry, I didn't understand you, is it possible to change at run time or not? but on Ubuntu if I try the same commands (irrespective of any codec) it works seamlessly 48k to 8k and vice versa. there are no such errors....

    regarding I2C commands I have already tried, it is posted in previous posts

    i2cset -y -f 2 0x1a 0x0 0x0 -->page 0 select

    i2cset -y -f 2 0x1a 0x02 0xAA -->> for 8k sample rate

    using i2cget we had read it back. reg values are changing but no effect...

    when Device is already @ 48k sampling rate after that, if we try to change to 8k

    arecord -D hw:1,0 -c 1 -r 8000 -f S16_LE | aplay -D hw:1,0 -c 1 -r 8000 -f S16_LE

    RecordingWAVE 'stdin:

    signed 16 bit Little Endian Rate 8000 Hz Stereo --> for recording no error but next when aplay is in pipe that time error

    Playing WAVE 'stdin' : tlv320aic3x-hifi:

    then also error is there from aplay side... aplay is referring older sampling rate only

    ASoC : unmatched rate sysmmetry: xxx.sai2:48000 - soc_pcm_params_systmmetry:8000

    signed 16 bit Little Endian Rate  ::8000 Hz streao

    tlv320aic3x-hifi: ASoC :  soc_pcm_params () failed (-22)

    aplay : set _params: unable to install hw params:

    ACCESS : RW_INTERLEAVED

    FORMAT: S16_LE

    SUBFORMAT: STD

    SAMPLE_BITS: 16

    FRAME_BITS : 32

    CHANNELS : 2

    RATE: 8000

    PERIOD_TIME: 67500

    PERIOD_SIZE: 540

    PERIOD_BYTES:7560

    TICK_TIME: 0

    Looks like aplay has not taken new sampling rate 8k,  it is still in 48k

  • Hi,

    I found (this forum post) and discovered that you can change the default/alternate sample rates that pulse audio uses in the pulse/daemon.conf file. I was able to open it on my Raspberry Pi Linux system and saw the default sample rate and alternate sample rate that you may be able to change if you want to go just between 8k and 48k, as well as some resampling methods that pulseaudio would use like "resample-method", "avoid-resampling', etc. If you don't have pulseaudio installed, you should install it, and this may help a lot with the resampling issue. You're saying you have issues with your Yocto system but not Ubuntu, right? 

    Also, this other post adds in ffmpeg as the resampling option, which may help you as well.

    Let me know what you figure out with this.

    Best,
    Mir

  • One more thing - I found that your error "unmatched rate symmetry soc_pcm_params_symmetry :8000" may be because there is another active stream with a different sample rate going on at the same time with the same DAI - did you properly shut down the previous playbacks of audio at 48k? You may want to use the snd_pcm_close() function, described a little here.

    -Mir

  • On boot,

    arecord -D hw:1,0 -c 1 -r 48000 -f S16_LE | aplay -D hw:1,0 -c 1 -r 48000 -f S16_LE -- >plays without any error

    But 

    Then I press ctrl+c or ctrl+d ^interrupt Signal like that it comes and we get the terminal back... is this not sufficient to try it on command line first??

    arecord -D hw:1,0 -c 1 -r 8000 -f S16_LE | aplay -D hw:1,0 -c 1 -r 8000 -f S16_LE

    --> here it gives unmatched rate symmetry error...

  • Do you have an issue when you run your command to do 8k sample rate on boot, before any other commands are run? Can you try using snd_pcm_close()?

  • On boot, whatever sample rate we give, codec takes (48k or 8k) no issue here, because codec gets reset...

    issue is only when we try to change @ runtime.

  • Hi Prasanna,

    There is a chance that the codec does not support sample rate changes at runtime. Can you try snd_pcm_close()? What about editing pulse daemon.conf file (more info here: https://linux.die.net/man/5/pulse-daemon.conf) to make the secondary audio sample rate 8k?

    Best,
    Mir

  • editing  pulse-daemon.conf didn't solve the issue

    default-sample-rate = 48000
    alternate-sample-rate = 8000

    again same error unmatched symmetry... I don't know in yocto this pulse plays any role

  • Did you try to run snd_pcm_close() before changing the sample rate? Again, I'm not sure if we will end up getting this working without a reset... you will just need to look into ways to reset the audio system via software instead of hardware to try to get around this.

  • soft reset means via I2C

    i2cset -y -f 2 0x1a 0x0 0x0 -->page 0 select

    i2cset -y -f 2 0x1a 0x02 0xAA -->> for 8k sample rate

    mentioned already which didin't work. 

    snd_pcm_drian()

    snd_pcm_close()

    Tried... but no change...

    Hardware reset gpio is given to driver which is not available to user space... 

    what is your suggestion next?

  • Hi,

    I'll look more into this on Monday. I'm not sure if you can solve this issue with this device, but maybe if you asked on your embedded Linux device's forum (or yocto forum?) they can help more with finding the root of the issue. It may even involve a driver edit but I'm not sure.

    -Mir