[#4393] ALSA w/ AD1836 issues
Submitted By: Jason Hennigar
2008-08-27 14:17:51 Close Date
Medium High Assignee:
Closed Fixed In Release:
Found In Release:
trunk SVN revision 7031
BF537 Silicon Revision:
Is this bug repeatable?:
Uboot version or rev.:
1.1.6 Toolchain version or rev.:
App binary format:
Summary: ALSA w/ AD1836 issues
A test application that receives audio from ADC2 and transmits this audio out DAC1 is attached which can be used to reproduce the following problems:
-> either the snd_pcm_readn is receiving samples a bit faster then the set rate or snd_pcm_writen is transmitting samples a bit slower then the set rate. This is deduced from the queue between the Rx and Tx threads overflowing and the Tx audio being a bit scratchy. In a 1 second interval between 3 and 4 messages overflow which means there is a difference in rate between the read and write of 480 to 640 samples (60 - 80ms). This can be reproduced by running the attached application and waiting a bit for the queue to overflow.
-> snd_pcm_mmap_begin returns with a bad file descriptor and areas is NULL. This can be reproduced by setting the #if to 1 in order to compile the second tx_audio function.
-> of less importance are snd_pcm_bytes_to_frames and snd_pcm_frames_to_bytes returning incorrect values.
When using the application no audio file is required, you just need to play music or something into the ADC2 (Mic input) and it will be sent out DAC1. Silence is sent to the other outputs when configured for 5.1 surround. If you want to test in stereo mode just set NUM_TX_CHNLS to 2 and I believe it will work the same. Note that Posix queues have to be enabled. The problems have been highlighted with a FIXME in the code.
--- Cliff Cai 2008-09-04 04:57:54
1.Commonly, I use arecord|aplay to test this talkthrough.I've test it on AD1836
which is configured for 5.1 surround,and haven't found apparent problem.
If you want to modify something like sample rate and format,you should also
modify the config file(AD1836.conf) for the sound card. In source tree,The file
is located in lib/alsa-lib/alsa-lib-1.0.12/src/conf/cards/ on board,the file is
located in usr/share/alsa/cards/.
2.currently mmap is not support by AD1836 driver.
--- Cliff Cai 2008-09-04 05:41:31
I only got endless "rx_audio qsend error" when I ran you application.
one more thing,the driver has limitation on period_bytes_min,you can try to
change it if you have problem to set the period size in your application
--- Jason Hennigar 2008-09-04 11:39:49
Thanks for the information regarding the AD1836.conf file. I'll modify that to
match the format and period size. I'll also modify snd_ad1836_capture_hw and
snd_ad1836_playback_hw in the driver to match.
Using both the 2008R1 release and the latest svn the error that I get when
running the application is "rx_audio transmit queue full". This occurs
when the queue between the Rx and Tx threads overflows. The only reason why this
queue would overflow is if there is a difference in the period size of the
capture and playback. Do you have 'kernel-> General -> Posix queues'
enabled in the configuration?
I tried running the following applications using the 2008R1 release last night
and using my Mark1 ear it sounds samples are being dropped.
vrec -w | vplay
vrec -wS | vplay -S
vrec -wS -s 48000 | vplay -S -s 48000
vrec -rS | vplay -S
vrec -rS -s 8000 | vplay -S -s 8000
vrec -rS -s 16000 | vplay -S -s 16000
arecord -r 48000 | aplay -r 48000
arecord -r 48000 -f S32_LE | aplay -r 48000 -f S32_LE
arecord -c 2 -r 48000 -f S16_LE | aplay -c 2 -r 48000 -f S16_LE
I would have tested against the latest svn version but I wasn't able to unmute
the Mic using amixer.
--- Jason Hennigar 2008-09-04 23:46:58
arecord|aplay work correctly with the 2007R1.1 release. I ran the following
arecord -r 8000 -f S32_LE | aplay -r 8000 -f S32_LE
arecord -r 8000 -f S16_LE | aplay -r 8000 -f S16_LE
The main difference between these applications and the one that I wrote is the
number of channels and the access type, non-interleaved instead of interleaved.
So I modified my application to use interleaved but the problem is still
occurring. I've also tried using FIFO instead of round robin scheduling of the
threads, various thread priorities and 1 Rx and 1 Tx channel.
--- Cliff Cai 2008-09-05 04:13:38
something about amixer:
mute/unmute keywords are parsed only for playback
you can mute or unmute capture by following cmds:
amixer sset Master nocap (unmute)
amixer sset Master cap (mute)
quite strange,they seem upside-down.
--- Jason Hennigar 2008-09-05 20:33:24
I have been comparing the ALSA configuration generated by arecord|aplay and the
application that I wrote. There where differences between the two so I thought
that I would try to get arecord|aplay to have the same configuration. When
arecord|aplay has the same ALSA configuration as my application it exhibits the
The following command has good quality audio:
arecord -r 8000 -f S16_LE | aplay -r 8000 -f S16_LE -v
This command ends up with the same configuration and poor quality audio:
arecord -r 8000 -f S16_LE --period-size=160 | aplay -r 8000 -f S16_LE
This testing was done using the 2007R1.1 release.
The reason that I chose a period of 160 samples was to be able to make use of
Speex. The last time I checked it was not possible to adjust the Speex sample
rate from 160.
In order to get the working configuration I had to set the period time near
42666 and modify the start threshold.
--- Cliff Cai 2008-09-08 06:16:15
I think I've fixed this problem,Would you please update the driver and have a
--- Jason Hennigar 2008-09-08 11:50:55
I moved back to the latest SVN Revision 7051 using the 2008R1.5 toolchain and
when using a stereo pair the audio quality is better then it was in the 2007R1.1
when using a short (10ms) delay (threshold). Less under runs occur and in
general the audio sounds better in the latest SVN version.
Setting the exact period size does not work, it looks like set near has to be
used . With a stereo pair set to 8000 samples/sec. the period size will be 170
and the period time 21333. At 16000 samples/sec. the period size is 341 and the
period time 21333. I can deal with this by buffering in my application so that
Speex gets the 20ms window of audio that it wants.
There is a problem opening up the 6 playback channels (i.e. 5.1) at 16000
samples/sec using the set period size near 341. The playback period size
actually gets set to 85, the period time to 5333 and there is no audio. 2
capture channels are opened along with the 6 playback where silence is sent on
last 4 playback channels. I've attached this ALSA configuration as
The same ALSA configuration is produced by the following command.
arecord -c 6 -r 16000 -f S16_LE | aplay -c 6 -r 16000 -f S16_LE -v
--- Cliff Cai 2008-09-08 22:56:39
AD1836 only support up to 4 channels record,so, setting "-c 6" to
arecord is not allowed.
--- Cliff Cai 2008-09-09 06:34:18
I've got a more reasonable solution for bad quality problem.Now you can set
period size as you like:)
--- Robin Getz 2008-09-09 06:57:05
>AD1836 only support up to 4 channels record,
Actually - no. the part can support up to 6 channels of record. On the red
audio card, there are 2 stereo analog channels, and a stereo SPDIF input (total
of 6 channels of input).
From the datasheet:
A special “auxiliary mode” is provided to allow two external
stereo ADCs and one external stereo DAC to be interfaced with
the AD1836A to provide 8 in/8 out operation.
Have a look at the AUX Mode Timing - figure 9.
The SPDIF transceiver is connected in this mode.
--- Jason Hennigar 2008-09-09 13:03:09
The 6 capture channels were used to generate the same playback configuration as
my application. Originally I tried opening 2 capture and 6 playback but aplay
was smart enough to realize it only had to open 2 channels.
I do realize that there are normally just 4 input channels and 6 output
Thanks for submitting the fix! I am now able to set the exact period size for a
stereo capture/playback pair. However there is still a problem with setting the
exact period size for 5.1 surround.
I've also updated the alsa_test application so that it sets the start
--- Cliff Cai 2008-09-09 23:25:48
The setting exact period_size problem for 5.1 surround has been fixed now.
I was able to run: arecord -c 6 -r 8000 -f S16_LE --period-size=160 | aplay -c
6 -r 8000 -f S16_LE --period-size=160 -v
and arecord -c 6 -r 16000 -f S16_LE --period-size=320 | aplay -c 6 -r 16000 -f
S16_LE --period-size=320 -v.
and saw the right ALSA configuration.
--- Jason Hennigar 2008-09-10 20:31:15
The latest version works great! I'm able to open up 2 capture and 6 playback
channels and the audio quality is great.
I'm running into a problem when using 4 capture and 4 or 6 playback, but the
following command works correctly. More then likely there is a bug in my
application that doesn't occur when using 2 capture but does when it's 4
arecord -c 4 -r 16000 -f S16_LE --period-size=320 -v | aplay -c 4 -r 160
00 -f S16_LE --period-size=320 -v
--- Jason Hennigar 2008-09-11 15:55:07
I investigated the problem with using 4 capture channels further and have found
that only 2 channels are really opened. When testing this with my application
the audio was motor boating on the 4 output channels however I could hear a bit
of the audio at the correct rate. So I modified the code to open up 4 capture
channels but to handle the audio as though only 2 capture channels are open. Now
the audio on 2 playback channels is correct. I proved this using interleaved
audio but I believe that the same problem is occurring with non-interleaved.
With 4 interleaved capture channels I expected the audio buffer to be:
What I received was:
with silence or nothing at the end of the buffer to make up for the missing two
At first listen the arecord/aplay appears to work but it plays the same audio
out channels 3 and 4 as it plays out channels 1 and 2. So it must handling this
and making a copy of the audio for the 3rd and 4th playback channels.
--- Cliff Cai 2008-09-11 23:59:47
I'm sure that "arecord -c 4 -r 16000 -f S16_LE --period-size=320 -v |
aplay -c 4 -r 16000 -f S16_LE --period-size=320 -v" does record 4 channel
of inputs and play them out to 4 channel of outputs,if you can find some
2-channel stereo musics that has obvious difference between right and left
channel as input sources you will see it.
I recommand you to a song named "california dreaming" if you can't
find it I can
send you the mp3 file.
--- Cliff Cai 2008-09-12 04:43:48
I modified the driver to correct the order of captured data stream.
so if you run 4-channel capture and 4/6-channel playback as above,audio will
come out form the lime and orange Jacks.the map is as following:
blue ---> lime
pink ---> orange
--- Jason Hennigar 2008-09-26 15:52:13
Now that I have streaming audio working I am able to go back to working on the
4 input channels. It still sounds like a motor boat and I've found the reason.
In the ad1836.h snd_ad1836_capture_copy() function the mask is not being
correctly set for 4 input channels. It ends up being set to 0x22 which is
correct for 2 input channels but not for 4 input channels. The mask should be
0x33 for 4 input channels.
The macro snd_pcm_substream_chip in linux-2.6.x/include/sound/pcm.h is where
the mask is being set. Therefore the substream->private_data has the
incorrect mask. substream->runtime->channels has the correct number of
channels. Modifying the snd_ad1836_mux_put() function per the attached diff
solves the problem.
--- Jason Hennigar 2008-09-26 15:57:23
The next problem that I am running into with getting all 4 input channels to
work at the same time is that Line and Mic capture is mutually exclusive. When
the Line is unmuted the Mic is muted and vis-versa.
--- Cliff Cai 2008-10-06 03:08:43
Sorry for late response!I'm just back from my vacation.
>In the ad1836.h snd_ad1836_capture_copy() function the mask is not being
>correctly set for 4 input channels. It ends up being set to 0x22 which is
>correct for 2 input channels but not for 4 input channels. The mask should
>0x33 for 4 input channels.
I've correct this misorder in my latest checkin,see above.
>The next problem that I am running into with getting all 4 input channels
>work at the same time is that Line and Mic capture is mutually exclusive.
>the Line is unmuted the Mic is muted and vis-versa.
By default,Mic and Line can work together,so we are able to get 4 channels of
input at the same time.I don't think we need to modify
"snd_ad1836_mux_put()",this function is called when running
"mixer +rec line/mic",that command means we want they to be mutually
--- Cliff Cai 2008-10-06 03:53:19
I think the doc about setting the audio mixer for ad1836 in wiki is not clear
enough,I also modified it now.
File Name File Type File Size Posted By
poor_audio_conf.txt text/plain 2023 Jason Hennigar
ad1836.diff.txt text/plain 2235 Jason Hennigar
good_audio_conf.txt text/plain 1992 Jason Hennigar
alsa_test.tar.gz application/x-gzip 14864 Jason Hennigar
5_1_no_audio_conf.txt text/plain 2380 Jason Hennigar