Post Go back to editing

there is no sound(speaker is silent) from speaker when aplay it, but play the same fie with other codec chip & play it on PC is ok. some *.wav file the volume is very low. the other *.wav file is OK.

Hi ADI:

mount -t debugfs none /sys/kernel/debug/
echo -n "file soc-core.c +p" >/sys/kernel/debug/dynamic_debug/control

insmod /lib/modules/3.10.65/snd-soc-ssm4567.ko
insmod /lib/modules/3.10.65/snd-soc-ssm4567-i2c.ko

tinymix  -D 1 3 1
tinymix  -D 1 4 1
tinymix  -D 1 8 hub_enable

aplay  /mnt/ring03.wav -f S16_LE -Dplughw:1,0 -r 44100   //is silent.
aplay  /mnt/notify.wav -f S16_LE -Dplughw:1,0 -r 44100    //is ok
aplay  /mnt/music.wav  -f S32_LE -Dplughw:1,0 -r 44100  //volume very low.

How to debug these issues?

 Thanks very much!

BRs

  • ring03.wav has no sound.

    notify.wav is fine.

  • The two uploaded files have different sample rates and if you specify -r 44100 for ring03.wav is wrong. So please resample ring03.wav with a tool like audacity.

    ❯ file Ring03.wav
    Ring03.wav: RIFF (little-endian) data, WAVE audio, Microsoft PCM, 16 bit, stereo 22050 Hz
    
    ❯ file notify.wav
    notify.wav: RIFF (little-endian) data, WAVE audio, Microsoft PCM, 16 bit, stereo 44100 Hz

    On full alsa library even if I try to specify -r 44100 on Ring03.wav it will ignore it and will still play it at 22050Hz.

    I think tinyalsa is dummier and allows you to play a wav file at the wrong sample rate and ignore what was read from the file header.

  • Hi Btogorean:

        using aplay  /mnt/ring03.wav -f S16_LE -Dplughw:1,0 -r 22050, still has no voice. how to debug it ?

  • Hi ADI

      Are there any update for this?

  • Hi,

    is out of office, he will reply as soon as he returns.

    -Michael

  • OK

    It's urgent issue for us, could you support the issue ASAP? Thanks

  • Hi, I would first check with oscilloscope or logic analyzer that the I2S signals look OK and the LRCLK and BCLK are corresponding for the new 22050 rate and also check the DAC CONTROL REGISTER (0x02) and especially the DAC_FS bits. They should be set to 001.

    You can check the register using the debugfs regmap interface.

  • Hello Sardo,

    To add what btogorean said, What is the exact format? 

    Is it actual standard I2S which is stereo with 32 bits per channel slot?

    If this is true then the problem is the bitclock rate. 

    22,050fs x 64 bits = 1,411,200Hz. 

    The ADAU4567 uses the bitclock for driving the internal filters so it needs to be a minimum of 2MHz. Here is where it is mentioned in the datasheet:

    A BCLK signal must be provided to the SSM4567 for correct operation. The BCLK signal must have a minimum frequency of 2 MHz.

    One solution would be to operate the part in TDM4 more which would bring the bitclock rate back up to ~2.8MHz. However, I am expecting this might be difficult to do with the Linux driver. Perhaps it is easier to use a sample at a higher rate? There are other possible solutions but I do not have all the hardware details.

    Dave T

  • Hi Dave:

      Thanks for you reply,  which wav file we could using to play? < 22050 sample rate * 32bit mono?

  • Hello sarvdo,

    The bit clock rate has to do with the sampling rate, the number of bits in the channel slot and the number of channels in each sample period. This is the serial communications that it would be setup to use. The file size and bit depth is not the only factor here. 

    First of all, none of the serial formats are mono. So if you are sending out a mono sound file it will either be only on one channel of a stereo serial format or be repeated onto both channels. No big difference just a detail. 

    The bit depth of the signal is not super important. If you have the sound file at a 16 bit depth then you can transmit it out inside of a 32 bit wide slot with no problems. Most of the serial formats these days are left justified so the bit depth does not make a difference when you go to play it. 

    You can setup a TDM-2 signal with only 16 bits for each channel. This keeps the bit clock rate low but in this case that is the issue, it is too low. Let me do a bit of math:

    22050 fs x 16 bits x 2 ( for two 16 bit wide slots = 705.600Hz for the bit clock. This clock clocks in each individual bit. 

    So going to 32 bit wide slot size, which is what standard I2S uses, you get:

    22050 fs x 64 bits in each sample period ( two 32 bit channels ) = 1,411,200Hz which is still less than the 2MHz minimum frequency. 

    So standard I2S will not do it at that sample rate. To get a 2MHz minimum bit clock rate with I2S the sample rate would have to be:

    2MHz bit clock / 64 = 31,250Hz fs. This is the minimum sample rate you can do using I2S.

    So if you up-sample your sound file to be 32kHz at 16 bits then you would meet the requirements when using standard I2S which uses 32 bit wide channel slots. 

    If you need to keep the size of the sound file small then if you are able to configure the Linux driver for TDM-4 then this is what you would get?

    22050 x 16 x 4 = 1,411,200 which is still too low, So you would have to use 32 bit wide slots and four slots per sample period so you get this:

    22050 x 32 x 4 = 2,822,400Hz for a bit clock and that would work. You just need to use one of the left justified data formats and then the 16 bit data is no problem. You are using four channels to transmit one but that is no huge deal. The two left justified formats are Left justified and Left Justified Delayed by One bit clock. Either would work, it just has to be set the same on both sides of the transmission, the sender and receiver. 

    So there are your options to get the bitclock up past the 2MHz min. I am just not sure of what the capabilities of the Linux driver is since that is not my world of expertise. 

    Dave T