[#4393] ALSA w/ AD1836 issues

Document created by Aaronwu Employee on Aug 29, 2013
Version 1Show Document
  • View in full screen mode

[#4393] ALSA w/ AD1836 issues

Submitted By: Jason Hennigar

Open Date

2008-08-27 14:17:51     Close Date

2009-04-03 03:43:36

Priority:

Medium High     Assignee:

Cliff Cai

Status:

Closed     Fixed In Release:

N/A

Found In Release:

2008R1.5-RC3     Release:

trunk SVN revision 7031

Category:

Audio     Board:

STAMP

Processor:

BF537     Silicon Revision:

Is this bug repeatable?:

Yes     Resolution:

Fixed

Uboot version or rev.:

1.1.6     Toolchain version or rev.:

2008R1.5-RC3

App binary format:

N/A     

Summary: ALSA w/ AD1836 issues

Details:

 

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.

 

Cheers!

Jason

 

Follow-ups

 

--- Cliff Cai                                                2008-09-04 04:57:54

Hi Jason,

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

 

--- 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

 

Cliff 

 

--- Jason Hennigar                                           2008-09-04 11:39:49

Hi Cliff,

 

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.

 

Cheers!

Jason

 

--- Jason Hennigar                                           2008-09-04 23:46:58

Hi Cliff,

 

arecord|aplay work correctly with the 2007R1.1 release. I ran the following

tests.

arecord -r 48000 -f S32_LE | aplay -r 48000 -f S32_LE

arecord -r 8000 -f S32_LE | aplay -r 8000 -f S32_LE

arecord -r 8000 -f S16_LE | aplay -r 8000 -f S16_LE

arecord -c 2 -r 48000 -f S16_LE | aplay -c 2 -r 48000 -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.

 

Cheers!

Jason

 

--- 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.

 

Cliff

 

--- Jason Hennigar                                           2008-09-05 20:33:24

Hi Cliff,

 

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

same problem.

 

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

--period-size=160 -v

 

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.

 

Cheers!

Jason

 

--- Cliff Cai                                                2008-09-08 06:16:15

Hi Jason,

 

I think I've fixed this problem,Would you please update the driver and have a

try.

 

Thanks

 

Cliff

 

--- Jason Hennigar                                           2008-09-08 11:50:55

Hi Cliff,

 

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

5_1_no_audio_conf.txt.

 

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

 

Cheers!

Jason

 

--- Cliff Cai                                                2008-09-08 22:56:39

Hi Jason,

 

AD1836 only support up to 4 channels record,so, setting "-c 6" to

arecord is not allowed.

 

Cliff

 

--- Cliff Cai                                                2008-09-09 06:34:18

Hi Jason,

 

I've got a more reasonable solution for bad quality problem.Now you can set

exact

period size as you like:)

 

Cliff

 

--- Robin Getz                                               2008-09-09 06:57:05

Cliff:

 

>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:

  www.analog.com/static/imported-files/data_sheets/AD1836A.pdf

==================

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

Hi Cliff,

 

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

channels.

 

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

threshold.

 

Cheers!

Jason

 

--- Cliff Cai                                                2008-09-09 23:25:48

Hi Jason,

 

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.

 

Cliff

 

--- Jason Hennigar                                           2008-09-10 20:31:15

Hi Cliff,

 

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

capture.

 

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

 

Cheers!

Jason

 

--- Jason Hennigar                                           2008-09-11 15:55:07

Hi Cliff,

 

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:

|1|2|3|4|1|2|3|4|1|2|3|4|1|2|3|4|1|2|3|4|

 

What I received was:

|1|2|1|2|1|2|1|2|1|2|1|2|1|2|1|2|1|2|1|2|

with silence or nothing at the end of the buffer to make up for the missing two

channels.

 

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.

 

Cheers!

Jason

 

--- Cliff Cai                                                2008-09-11 23:59:47

Hi Jason,

 

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 

 

--- Cliff Cai                                                2008-09-12 04:43:48

Hi Jason,

 

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:

 

input     output

blue ---> lime

pink ---> orange

 

Cliff

 

 

--- Jason Hennigar                                           2008-09-26 15:52:13

Hi Cliff,

 

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.

 

Cheers!

Jason

 

--- Jason Hennigar                                           2008-09-26 15:57:23

Hi Cliff,

 

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.

 

Cheers!

Jason

 

--- Cliff Cai                                                2008-10-06 03:08:43

Hi Jason,

 

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

be

>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

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.

 

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

exclusive.

 

Cliff

 

--- Cliff Cai                                                2008-10-06 03:53:19

Hi Jason,

 

I think the doc about setting the audio mixer for ad1836 in wiki is not clear

enough,I also modified it now.

 

Cliff

 

 

 

    Files

    Changes

    Commits

    Dependencies

    Duplicates

    Associations

    Tags

 

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

Outcomes