[alsa-devel] Bug? Sound support for at91sam9x5-wm8731 based boards
When playing stereo sound on the Atmel at91sam9x5-ek board the left and right channel would get swapped about 1 in 6 tries.
2013/11/19 Zhong Li zql@glomationinc.com:
When playing stereo sound on the Atmel at91sam9x5-ek board the left and right channel would get swapped about 1 in 6 tries.
Can you give a little more background ? : - What kernel ? - Command line to reproduce ?
Richard.
Can you give a little more background ? :
- What kernel ?
- Command line to reproduce ?
Richard.
One of the testing hardware is the Atmel at91sam9g25-ek (the CPU module and the carrier board). We tried both the 2.6.39 patched with the Atmel patches and the mainline 3.12-rc. The command to test the sound is just the simple aplay <sound-test-file>. The wav file is available here, https://drive.google.com/file/d/0B3TSFX4Mq9PoeTdJOGVaZk5rTWM/edit?usp=sharin....
Thanks
[added Nicolas Ferre and Bo Shen ]
2013/11/19 Zhong Li zql@glomationinc.com:
Can you give a little more background ? :
- What kernel ?
- Command line to reproduce ?
Richard.
One of the testing hardware is the Atmel at91sam9g25-ek (the CPU module and the carrier board). We tried both the 2.6.39 patched with the Atmel patches and the mainline 3.12-rc. The command to test the sound is just the simple aplay <sound-test-file>. The wav file is available here, https://drive.google.com/file/d/0B3TSFX4Mq9PoeTdJOGVaZk5rTWM/edit?usp=sharin....
Thanks
Ok, I reproduce the bug on g35-ek with a v3.11.7+(sam9x5 sound patches) kernel
So, *sometimes*, the left and right channel are swapped. ( I found also the ratio 1 out of 6 (but once it has happened, it seems to be more often)) I tested that with the file given by Zhong Li, and with a file I created with audacity (440Hz only on right channel). I could see at the scope that the channels are swapped before the w8731 codec (the data on the TD line are sometime on the low edge of TF, instead of always being on the high edge (I2S mode)). There's, in both cases, a clock period (TK) between the rising/falling edge of TF and the 1st data bit on TD, so the mode is always I2S, and the channel data are swapped.
I'll try to have a look (but I don't have much time right now)
If someone could test that on a sam9g20 or a WM8904 based board, since they share the same DAI format, they may have the same problem.
Thanks ! Richard
2013/11/20 Richard Genoud richard.genoud@gmail.com:
[added Nicolas Ferre and Bo Shen ]
2013/11/19 Zhong Li zql@glomationinc.com:
One of the testing hardware is the Atmel at91sam9g25-ek (the CPU module and the carrier board). We tried both the 2.6.39 patched with the Atmel patches and the mainline 3.12-rc. The command to test the sound is just the simple aplay <sound-test-file>. The wav file is available here, https://drive.google.com/file/d/0B3TSFX4Mq9PoeTdJOGVaZk5rTWM/edit?usp=sharin....
Thanks
Ok, I reproduce the bug on g35-ek with a v3.11.7+(sam9x5 sound patches) kernel
So, *sometimes*, the left and right channel are swapped. ( I found also the ratio 1 out of 6 (but once it has happened, it seems to be more often)) I tested that with the file given by Zhong Li, and with a file I created with audacity (440Hz only on right channel). I could see at the scope that the channels are swapped before the w8731 codec (the data on the TD line are sometime on the low edge of TF, instead of always being on the high edge (I2S mode)). There's, in both cases, a clock period (TK) between the rising/falling edge of TF and the 1st data bit on TD, so the mode is always I2S, and the channel data are swapped.
I'll try to have a look (but I don't have much time right now)
If someone could test that on a sam9g20 or a WM8904 based board, since they share the same DAI format, they may have the same problem.
After reading the sources (mainly sound/soc/atmel/atmel_ssc_dai.c), I don't understand how the right and left channel are synchronized. (which one will be on TF rising edge, and which one on TF falling edge ?) In the SSC_TCMR register, the start event is TF_FALLING when there only one channel (i.e. mono source always on left channel) With a stereo source, it's TF_EDGE (Detection of any edge on TF signal) ; so the samples are transferred on rising and falling edge. I didn't see anything in the SSC what could synchronize the first sample with a TF falling edge. Or I missed something ?
Nicolas, Bo, any idea ?
Richard.
After reading the sources (mainly sound/soc/atmel/atmel_ssc_dai.c), I don't understand how the right and left channel are synchronized. (which one will be on TF rising edge, and which one on TF falling edge ?) In the SSC_TCMR register, the start event is TF_FALLING when there only one channel (i.e. mono source always on left channel) With a stereo source, it's TF_EDGE (Detection of any edge on TF signal) ; so the samples are transferred on rising and falling edge. I didn't see anything in the SSC what could synchronize the first sample with a TF falling edge. Or I missed something ?
The codec seems to be set to I2S mode based on the parameter name. And the FSOS field in the TFMR is set to be negative pulse. So it matches the I2S mode diagram (Figure 27 of WM8731 datasheet). The high to low on DACLRC (TF line aka PA25 pin) indicate start of the left channel data. Looks like the TF signal is automatically generated by the SSC controller according to the TFMR settings.
2013/11/20 Zhong Li zql@glomationinc.com:
After reading the sources (mainly sound/soc/atmel/atmel_ssc_dai.c), I don't understand how the right and left channel are synchronized. (which one will be on TF rising edge, and which one on TF falling edge ?) In the SSC_TCMR register, the start event is TF_FALLING when there only one channel (i.e. mono source always on left channel) With a stereo source, it's TF_EDGE (Detection of any edge on TF signal) ; so the samples are transferred on rising and falling edge. I didn't see anything in the SSC what could synchronize the first sample with a TF falling edge. Or I missed something ?
The codec seems to be set to I2S mode based on the parameter name. And the FSOS field in the TFMR is set to be negative pulse. So it matches the I2S mode diagram (Figure 27 of WM8731 datasheet). The high to low on DACLRC (TF line aka PA25 pin) indicate start of the left channel data. Looks like the TF signal is automatically generated by the SSC controller according to the TFMR settings.
Yes, we use the I2S mode as in wm8731-figure27. But the WM8731 is in master mode (wm8731-figure3). So it provides BCLK (TK) and frame clock (DACLRC (TF)). That's set in sam9x5_wm8731.c : dai->dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF | SND_SOC_DAIFMT_CBM_CFM; DAIFMT_I2S : I2S mode obviously (wm8731 reg 7 bit 0:1 = 2) DAIFMT_NB_NF : clock frames phasing (wm8731 reg7 bit4=0, bit7=0 : Left channel when DAC is low and BCKL not inverted) DAIFMT_CBM_CFM : master mode (wm8731 reg7 bit6=1 )
And I think you read the wrong value for the FSOS field of TFMR register : in the I2S + CBM_CFM case, it's set to 0 because TF pin is an input for the SSC.
So yes, the wm8731 generates the TK and TF signals and the SSC is configured to send 16bits data on every TF edge (SSC_START_EDGE_RF). The SSC_FSEDGE_POSITIVE flag will trigger the TXSYN interrupt on a TF positive edge. That's a way to get the sync between right/left channel I think : If we set SSC_FSEDGE_POSITIVE, and enable the TXSYN interrupt, at the first interrupt received we could start the DMA transfer (and disable the interrupt). The SSC will then send the 1st data (left data) on the next TF edge which will be a negative edge (left channel).
Richard
participants (2)
-
Richard Genoud -
Zhong Li