You are not logged in.
My situation is that I am using an Olinuxino Maxi (i.MX233 processor) with the latest Arch Linux ARM SD card image specifically for this board. It is running a VOIP application that I have developed for it, using the Linphone library.
With the latest ALARM build working on the board, I then switched to the mainline kernel (3.12+) by installing the package linux-armv5, which replaced default linux-olinuxino kernel (in accordance with a note on the download page). By doing this, I then have support for the onboard i.MX233 audio, which I believe has only recently gone into the mainline kernel.
Although audio works and I can make Linphone calls and record / play audio, a significant problem is that there is a periodic clicking noise on audio sampled from the line input on the board, except for the first time the line input is used since boot. To clarify what I mean, if I reboot the board and then use arecord to make three recordings, the first recording is clean and all subsequent recordings contain the clicking noise. Similarly, if I reboot and then make Linphone VOIP calls, only the first call is 'clean'; for subsequent calls, transmitted audio has the noise (although it manifests itself more as a nasty 'chopping' noise over the VOIP calls).
For example:
- Reboot the board.
- Use arecord to record audio to test1.wav.
- Use arecord to record audio to test2.wav.
- aplay test1.wav. The audio is clean.
- aplay test2.wav. The audio is noisy with fast cyclic clicking.
- Any subsequent recordings are noisy. The only way to create another clean recording is to reboot.
I have tried all sorts of experimentation with alsamixer settings without success. Attempting to make the audio input go 'clean' again by using alsactl to reset and initialise the audio simply has no effect. Once the first 'clean' arecord or Linphone call has finished since boot, the line-in goes 'dirty' and nothing I can do will revert it.
Any ideas please?
Last edited by TrevorPage (2014-02-17 22:34:17)
Offline
One dirty fix would be to force a continues stream to play just after sound card initialization (/dev/null > /dev/snd). Seems like a driver issue though - a unclean exit/release of resources. Most sound issues, like the one you describe, are correlated to sample rate (changes).
Also Arch Linux ARM Forum may be more suited for your questions.
Last edited by emeres (2014-02-17 22:50:42)
Offline
Many thanks for your reply, emeres. It's really appreciated.
It does seem that it's only the line input that is affected, as the audio output always remains clean.
Would you have any idea if there is anything I could try to do from within my C application? I've never before written anything to talk to ALSA drivers / APIs, but I just wondered if there's any kind of forced re-initialisation or something I could perform. The very first Linphone call is clean, but after that, all calls have dirty audio on the line-in. So, if only there was *something* I could to to reset the driver after each Linphone call ends - then such a dirty work-around would at least ensure every call would be clean. But unfortunately so far I can't see how I can restore the driver to initial conditions. As said, using alsactl doesn't have any effect.
How would I be best reporting this bug to have it fixed?
Offline
You could try adding a few buffers of zero stream data after sound file was played (in the same procedure). Make sure you have done alsa API handling by the book before posting any bug report though. Maybe these guys can help you, if not try official alsa devel mailing list. It should not be necessary to reinitialize SOC every time you want to play something.
Offline