2009-03-02 08:08:23     Alsa configuration

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

2009-03-02 08:08:23     Alsa configuration

Rob Maris (GERMANY)

Message: 70216   

 

I need some useful pointers to information of how to get my AD73311 'soundcard' operating as a proper ALSA device. On a low level, all is functioning properly (using examples from the AD73322 docs page, e.g. 'arecord -D plughw:0,0 -d 5 a.wav', but running without plughw specification yields errors.

 

When I run

 

amixer -c 0 scontrols

 

Nothing is responded (contrary to my linux host system).

 

 

 

My configuration is set up with static device nodes, sound devices configured as built in to kernel (*) and FDPIC.

 

Speaker test with plughw device is OK, but:

 

root:  /> speaker-test -r8000

 

speaker-test 1.0.12

 

Playback device is default

Stream parameters are 8000Hz, S16_LE, 1 channels

Using 16 octaves of pink noise

ALSA lib ../../../alsa-lib-1.0.18/src/pcm/pcm_mmap.c:369:(snd_pcm_mmap) mmap failed: No such device

ALSA lib ../../../alsa-lib-1.0.18/src/pcm/pcm_direct.c:975:(snd1_pcm_direct_initialize_slave) unable to install hw params

ALSA lib ../../../alsa-lib-1.0.18/src/pcm/pcm_dmix.c:1020:(snd_pcm_dmix_open) unable to initialize slave

 

Note: this result is gained after having added a new group audio using the command:

 

addgroup audio

 

 

QuoteReplyEditDelete

 

 

2009-03-02 12:58:25     Re: Alsa configuration

Mike Frysinger (UNITED STATES)

Message: 70228   

 

what version of software exactly are you using ?

 

did you enable the mmap() emulation in the kernel ?  the alsa config file needs to match the mmap emulation status ...

QuoteReplyEditDelete

 

 

2009-03-02 16:20:12     Re: Alsa configuration

Rob Maris (GERMANY)

Message: 70231   

 

According to a bit investigation, the mmap is hidden behind an AC97 selection point. This is outlined in the docs page for AD1980, not in the corresponding page for AD73311. I considered AC97 as to keep deselected (only for SPORT in slot 16 mode)

 

My settings are now changed as follows (svn trunk):

 

  <*> SoC I2S Audio for the ADI BF5xx chip │ │

  │ │ < > SoC SSM2602 Audio support for BF52x ezkit │ │

  │ │ <*> SoC AD73311 Audio support for Blackfin │ │

  │ │ (7) PF pin for AD73311L Chip Select │ │

  │ │ <*> SoC AC97 Audio for the ADI BF5xx chip │ │

  │ │ [*] Enable MMAP Support │ │

  │ │ [ ] Enable Multichannel Support │ │

  │ │ < > SoC AD1980/1 Audio support for BF5xx │ │

  │ │ (0) Set a SPORT for Sound chip │ │

  │ │ [ ] BOARD has COLD Reset GPIO │ │

  │ │ < > Build all ASoC CODEC drivers 

 

 

The following build error is the result:

 

sound/built-in.o: In function `bf5xx_mmap_copy': sound/soc/blackfin/bf5xx-ac97-pcm.c:(.text+0x1ae7c): undefined reference to `bf5xx_pcm_to_ac97'

sound/soc/blackfin/bf5xx-ac97-pcm.c:(.text+0x1aeba): undefined reference to `bf5xx_ac97_to_pcm'

 

When MMAP is selected as Module:

 

ERROR: "bf5xx_pcm_to_ac97" [sound/soc/blackfin/snd-bf5xx-ac97.ko] undefined!

ERROR: "bf5xx_ac97_to_pcm" [sound/soc/blackfin/snd-bf5xx-ac97.ko] undefined!

 

Please advice...

QuoteReplyEditDelete

 

 

2009-03-02 19:12:20     Re: Alsa configuration

Rob Maris (GERMANY)

Message: 70234   

 

It WORKS!!!

 

But at the same time I'm quite confused. I was attracted by the posting "RootFS in 2008R1.5", because from the beginning of my project with a Bluetechnix board I was wondering why they used uImage.ext2 as standard output result, instead of STAMPs initramfs. Now I knew the way how to disable ext2. After compiling, alsa configuration was OK. E.g. speaker-test runs without additional arguments.

 

Since I was not sure whether returning kernel configuration into the previous state without mmap and the errors reported above could have left any strange things over, I decided to make clean and start make from scratch: Speaker-test runs, linphone runs, i.e. regardless if make clean has been performed or not. When I have time, I'll set back to ext2 again (was not succeeding in this attempt just now), and see the result.

 

The remaining problem is still the lack of stdin response from within the linphonec application (as is still pending in a separate thread).

 

(This intermediate result comes right in time prior to a customer meeting today)

QuoteReplyEditDelete

 

 

2009-04-15 21:02:12     Re: Alsa configuration

Rob Maris (GERMANY)

Message: 72710   

 

QUOTE: "When I have time, I'll set back to ext2 again (was not succeeding in this attempt just now), and see the result. "

 

Well, with a new PC and latest trunk, I've taken the opportunity to investigate. Definitely, when the major option MTD support is switched off, and then later on again, suboptions are reset. That's why I did not succeed in returning to uimage.ext2. There is exactly one suboption which 1) makes trouble with sound device mapping and 2) makes the difference, whether uImage is generated as initramfs or ext2. It is MTD_UCLINUX. When this option is activated, the trouble as described in this thread arises (again). Together with creating an ext2 image it can be found that the list of devices in /dev is much longer: many devices with name pf0, pf1, pf10 etc. exist. Why?

 

BTW: an option "enable MMAP support" must definitely not be set in order to get proper audio mapping.

 

All these investigations are performed while actually doing u-boot tftp&bootm cycles.

QuoteReplyEditDelete

 

 

2009-04-15 22:44:45     Re: Alsa configuration

Cliff Cai (CHINA)

Message: 72712   

 

1."enable MMAP support" is not needed by AD73311.

 

speaker-test works for me without this option.BTW,mixer doesn't work for AD73311.

 

2.you should update your toolchain to solve the linphone problem.

 

  blackfin.uclinux.org/gf/project/toolchain/frs/?action=FrsReleaseBrowse&frs_package_id=74

 

download :1.blackfin-toolchain-uclibc-default-09r1-5.i386.rpm

 

                     2.blackfin-toolchain-09r1-5.i386.rpm

 

 

 

Cliff

QuoteReplyEditDelete

 

 

2009-04-16 03:37:09     Re: Alsa configuration

Rob Maris (GERMANY)

Message: 72727   

 

Thanks, Cliff,

 

for clarifying things (MMAP, mixer).

 

Regarding the linphone problem: that had already been solved due to "Linphone does not respond to stdin" (thread 32710)". Actually, I'm using the latest toolchain. Just to get clear about it: The patch in readline that solved the "stdin" problem is not necessary with the actual configuration installed on my new host system. Mike said the fix went into uClibc, and this is in the toolchain - correct?

 

I looked in "Index of /trunk/uClibc" on the gnu toolchain page. I don't know which entry is the one related to this original problem.

 

Recalling the ext2-related audio problems: Of course these are not related to ext2. But the fact that a minor configuration change with respect to MTD has this great impact on sound devices to being correctly handled is strange. For me it sounds like a bug.

 

Rob

QuoteReplyEditDelete

 

 

2009-04-16 05:03:19     Re: Alsa configuration

Yi Li (CHINA)

Message: 72739   

 

Rob,

 

For the linphone issue, this is a problem of select(). It can be worked around in readline library (please refer to:   blackfin.uclinux.org/gf/project/uclinux-dist/tracker/?action=TrackerItemEdit&tracker_item_id=4789), OR, it can be fixed in uclibc. Mike has finally fixed select() in uclibc, that is why you need latest toolchain to make linphone work.

 

For the MTD issue, I don't have a clear answer for now.

 

-Yi

QuoteReplyEditDelete

 

 

2009-04-20 10:35:02     Re: Alsa configuration

Mike Frysinger (UNITED STATES)

Message: 72888   

 

/dev population depends entirely on the Makefile you're using for your board.  you can look at how it's done in vendors/<vendor>/<board>/Makefile.  often times they should simply be referring to the targets in vendors/<vendor>/vendor.mak, but not everyone does.

QuoteReplyEditDelete

 

 

2009-04-20 11:44:58     Re: Alsa configuration

Rob Maris (GERMANY)

Message: 72896   

 

Mike, a quick check showed that the Bluetechnix makefile has some differences with respect to the Analog Devices' one, but it refers to the same vendor.mak. When an ext2 target does not populate some devices correctly, this may well be caused by details of Makefile. At a later time, I'll do some experiments.

Attachments

    Outcomes