Hi all.

I've just tried SAM9G15-EK's Audio CODEC. Android, plays an mp3 file good.(from SD) But there is also noisy beep. And its periodicly like 1200mSec.

Any Idea?

Thanks
Babur

9g15 boards was not tested yet. Try 9x5,see if it still exists.

I am already using 9x5 codes.
Compiled or prebuilt no difference. It's impossible to listen music clearly. Also i noticed that there is same noise on Volume Page(on Settings->Sound)

This problem is serious for us.
Please advice

Okida

According to our tests,the target board BOM Rev.003 play Music with a little noise,the other 2 boards BOM Rev.001 and BOM Rev.002 is quite OK.

Yes. I have R003.
AlSo i asked Atmel Support for this problem. They said that they'd never experienced any problem like this.

However, I tried to make my resolve and i use a scope for inspect the problem. When i touch the BCLK pin (Pin 3 on WM8731) the noise went out So i added a capacitor from Pin3 to GND and result is okay. Songs are very clear

But i think this is a layout problem so capacitor or resistor is not important. If i add any conductuve thing for this pin this resolve the problm.
I confused but anyway.

Now board is working good.

Many thanks

Babur
Okıda Inc.

We have experienced persistent “tick” "tick" "tick" noises with audio playback of the G25, G35, and A5D3x boards too. It may be a “little noise”, but it is too frequent to be ignored.

We recently acquired a SAM9G25-EK (BOM 003) and a SAM9G35-EK (same BOM 003) to evaluate for an embedded audio project… and to our disappointment, the music playback is full of audible “ticks” (similar to the mouse-down click made by a mouse).

If “m” were a second of clean music and the tick ( ` ) were an audible noise ‘click’, this is what you would hear when playing an mp3 with either mplayer or madplay in these boards:

mmmm`mmmm`mmmm`mm`m`mmmmmmmmm`mmmm`mmm …

Just yesterday we got a brand new SAMA5D31-EK (Rev. C) on the mail, flashed the Linux demo binaries, tried mplayer… and guest what? It also has audible “ticks” (although less frequent that those heard in the above SAM9x5-EK boards, but are irritating enough to make you want to throw the board out the window)! Also tried the Android build to play music and the sound quality was nothing more that disappointing. *sighs*

My base to judge these boards above is a SAM9n12-EK (BOM 001) I got last year, which have a clear and very clean audio playback capability, a pleasure to develop embedded audio apps.

Personally, I’m not very thrill about the SAM9x5-EK and A5D3x boards for doing embedded multimedia development.

There seems to be a trend of lack of attention-to-detail by Embest in these recent boards.

Atmel you should take notice.

***Update***

Okida, THANK YOU so much for posting your findings. You helped us to save our boards!

We walked in your footsteps and solder a 22pf capacitor from the WM8731 pin 3 (BCLK) to ground and now we have crystal clear audio in both of our SAM9x5-EKs BOM 003.

Kudos to you okida.



As for the SAMA5D3x (Rev. C), from time to time sounds like an old vinyl record when the needle run over speckles of dust in the tracks; and sometimes the sound is clean. It comes and goes. Keeping the alsamixer volumes (either Headphone or Digital) below 40% seems to improve the noise problem. This codec is a WM8904 in a tiny QFN which is harder to debug.

Hi,

I'm having two boards lying on my table - SAMA5D31 and SAMA5D35 (MB Rev C). While evaulating them I've discovered some little problems too with audio recording (hardware one) - bit after contacting Atmel - resolved them in less than day - you need to resolder R232 to 1kOm to be able to record the audio streams with correct sample rate.
About the audio playing : it is clear until you are using the correct number of the channels and audio sample format that is only supported by onboard WM8904 codec and its driver - you have to use S16/24/32_LE samples and stereo only. Though the ALSA plughw subsystem have to handle this (as it is handles usb-audio on the same board) - there is definitely some bugs in WM8904 driver that prevents alsa virtual plughw driver from adopting the formats and channels number for different streams. Try to convert the file you are currently expect the problems with sox:

sox <input.wav> -e signed-integer -c 2 <output.wav>

And play - you will see no artifacts and hear the clear sound. Sure there exists other slight problems with audio on this boards - but they are definitely not the showstoppers and can be easily resolved.

Rus

------------
SfinxSoft
http://sfinxsoft.com