- Alsa-devel - mailman.alsa-project.org

[alsa-devel] HD-audio dynamic configuration
by Takashi Iwai 07 Mar '08

07 Mar '08

Hi, time passed since the last discussion about where the HD-audio driver development to go to. I checked and tried to rework a bit the user-space configuration tool, and found out that it's really hard to keep it up to date. One of the big obstacles is that the HD-audio codecs often behave unexpectedly, in most cases, due to hardware bugs. For example, some codecs need the override of AMP caps and some needs rewrite of pin caps, etc. This is hard to catch with a sole generic code. It means, we need more or less codec-specific workarounds. Consequently, I believe it's easier to keep a little amount of codec-specific parser codes in the hda driver. This is of course hard-coded in the kernel. Then the goal is to reduce the amount of "patches" we have now for each specific device type. For this purpose, I've implemented a new feature -- allow hd-audio driver to reconfigure dynamically with additional hints. The hd-audio driver would have sysfs entries that can read/write the information dynamically and trigger the re-configuration of the parser. Right now, it's created as sysfs entries of each hwdep device, so that it can be bound to each codec chip. For example, suppose the card0 has codec#2. It corresponds to hwC0D2 device. /sys/class/sound/hwC0D2/ has the following new entries: 1. vendor_id, subsystem_id, revision_id, afg, mfg, 2. name, modelname 3. init-verbs, hints 4. reconfig, clear The files in 1 are the codec information that can be obtained from the codec chip. These are digits, and can be read *and* written. The write means the specific value will be overridden, and the driver handles as if the codec returns so. For example, if you have a new, unsupported codec chip that is compatible with others, you can change vendor_id value on the fly. The files in 2 are the strings that appear in the mixer, etc. The modelname is the model module option. This can be changed dynamically as well. The init-verbs and hints are write-only. You can pass the additional init verbs (e.g. for reprogramming the pincfg) and pass hints to the codec parser code. The hints are simply strings. Then you can write (any value) to "reconfig" to trigger the reconfiguration of the codec parser. Then all existing PCMs and mixer elements of this codec will be once removed and re-generated again with new init-verbs and hints. The "clear" is to clear the existing PCMs, mixer elements and init-verbs/hints entries. Now, the big missing piece is more clever codec parser code. Especially, the generic parser could be greatly improved with hints. A lot of works ahead, though :) For people who are interested, I put preliminary patches on my git tree here: git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-unstable-2.6.git For building the external modules, you'd need this build stub tree: git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/alsa-driver-build-unsta… and run utils/setup-alsa-kernel script once (see INSTALL). The alsa-driver tarball snapshots are available at: http://ftp.kernel.org/pub/linux/kernel/people/tiwai/snapshot/ These experimental patches are in alsa-driver-unstable-snapshot tarball. Any comments appreciated. thanks, Takashi

1 0

Re: [alsa-devel] What recommended performance for ALSA(ASoC)?
by Jin-Young Park 07 Mar '08

07 Mar '08

Thanks for your reply. Your advises are very important information for me. Because explained your target system is very similar my target system. > I would like to say ALSA will perfectly runs on your target SOC clock. > I am running it on 192MHz ARM926 core along with H.264 video decoder!!!. > BogoMIPS = 95.84. > Even I had the same glitch problem before. Following debugging tips are very helpful. I have questions about debugging tips. > Few debug steps here: > 1. Check the DMA Configuration. (Transfer size, buffer size and number of Transfers) > 2. Does your period,period bytes ,buffer size of Ringbuffer matcheswith the DMA buffer? What is your ALSA driver setting that buffer bytes, period bytes, periods? Current my driver setting values are buffer bytes(4KBytes), period bytes(2KBytes), periods(2). >Check the correct re-initilization of "period" once the buffer is full. What does meannig? I don't understand. And what is proper function for checking buffer and period? prepare,trigger,irq handler, pointer... > 3. Check the current DMA postion at the point of "pointer" callback.This should be equal to number of samples send to the PCM middle layer. > 4. As Jaroslav says disc read speed should be > (44100*2*16) for 44.1K 16bit stereo. Or else read from NFSBOOT if your SOC support Ethernet. > 5. Always test with a "sinewave" for glitchs, not with your favoritesong J Tell me recommended music for audio test. Thanks.

1 0

[alsa-devel] OSS4 X-Fi driver port to ALSA
by William Pitcock 07 Mar '08

07 Mar '08

Hi, On Feburary 1, 4Front released their XFi driver to the public. Is anyone looking into porting this? If not, I will give it a try soon enough. It seems to not require any firmware at all too. William

5 13

[alsa-devel] [PATCH] Fix for alsa-lib cross-compilation problems with ALSA_CONFIG_DIR and ALSA_PLUGIN_DIR
by Pawel MOLL 07 Mar '08

07 Mar '08

Fix for alsa-lib cross-compilation problems with ALSA_CONFIG_DIR and ALSA_PLUGIN_DIR "./configure" options for selecting ALSA configuration (default /usr/share/alsa) and plugin (/usr/lib/alsa-lib) directories introduced by alsa-hg/alsa-lib changeset 2284 cause problems with cross-compilation and packaging - there is no way to redefine them in runtime, during installation phase. This patch adds a level of indirection between constants and their usage - alsaconfigdir for ALSA_CONFIG_DIR and alsaplugindir for ALSA_PLUGIN_DIR - which can be redefined during "make install" stage. Signed-off-by: Pawel MOLL <pawel.moll(a)st.com> --- Index: alsa-lib-1.0.16/modules/mixer/simple/Makefile.am =================================================================== --- alsa-lib-1.0.16.orig/modules/mixer/simple/Makefile.am +++ alsa-lib-1.0.16/modules/mixer/simple/Makefile.am @@ -1,4 +1,5 @@ -pkglibdir = @ALSA_PLUGIN_DIR@/smixer +alsaplugindir = @ALSA_PLUGIN_DIR@ +pkglibdir = $(alsaplugindir)/smixer pythonlibs = @PYTHON_LIBS@ pythonincludes = @PYTHON_INCLUDES@ Index: alsa-lib-1.0.16/src/conf/Makefile.am =================================================================== --- alsa-lib-1.0.16.orig/src/conf/Makefile.am +++ alsa-lib-1.0.16/src/conf/Makefile.am @@ -10,5 +10,6 @@ endif EXTRA_DIST = $(cfg_files) -alsadir = @ALSA_CONFIG_DIR@ +alsaconfigdir = @ALSA_CONFIG_DIR@ +alsadir = $(alsaconfigdir) alsa_DATA = $(cfg_files) Index: alsa-lib-1.0.16/src/conf/cards/Makefile.am =================================================================== --- alsa-lib-1.0.16.orig/src/conf/cards/Makefile.am +++ alsa-lib-1.0.16/src/conf/cards/Makefile.am @@ -1,4 +1,5 @@ -alsadir = @ALSA_CONFIG_DIR@/cards +alsaconfigdir = @ALSA_CONFIG_DIR@ +alsadir = $(alsaconfigdir)/cards cfg_files = aliases.conf \ AACI.conf \ ATIIXP.conf \ @@ -58,7 +59,7 @@ endif alsa_DATA = $(cfg_files) if BUILD_ALISP -SI7018dir = @ALSA_CONFIG_DIR@/cards/SI7018 +SI7018dir = $(alsaconfigdir)/cards/SI7018 SI7018_files = \ SI7018/sndoc-mixer.alisp \ SI7018/sndop-mixer.alisp Index: alsa-lib-1.0.16/src/conf/pcm/Makefile.am =================================================================== --- alsa-lib-1.0.16.orig/src/conf/pcm/Makefile.am +++ alsa-lib-1.0.16/src/conf/pcm/Makefile.am @@ -7,5 +7,6 @@ cfg_files = default.conf front.conf rear EXTRA_DIST = $(cfg_files) -alsadir = @ALSA_CONFIG_DIR@/pcm +alsaconfigdir = @ALSA_CONFIG_DIR@ +alsadir = $(alsaconfigdir)/pcm alsa_DATA = $(cfg_files)

2 1

Re: [alsa-devel] ALSACTL wrong restore on ARM9
by Liam Girdwood 07 Mar '08

07 Mar '08

On Fri, 2008-03-07 at 16:11 +0100, Alexandre BOUIN wrote: > Hi list, > > I'm using an intern AT91SAM92620-EK board with a WM8900 codec. > ALSACTL restores bad values to controls after doing this : > > $ rm /var/lib/alsa/asound.state > $ alsactl store > $ alsactl restore > > Anyone has seen this issue before ? > Any ideas to solve it ? (I don't know much these utils neither alsa API) > Could it come from our ASoC codec driver ? > Can you describe 'bad values' in a little more detail. Liam

2 1

[alsa-devel] ALSACTL wrong restore on ARM9
by Alexandre BOUIN 07 Mar '08

07 Mar '08

Hi list, I'm using an intern AT91SAM92620-EK board with a WM8900 codec. ALSACTL restores bad values to controls after doing this : $ rm /var/lib/alsa/asound.state $ alsactl store $ alsactl restore Anyone has seen this issue before ? Any ideas to solve it ? (I don't know much these utils neither alsa API) Could it come from our ASoC codec driver ? Thanks in advance. Regards, Alex.

1 0

[alsa-devel] M-Audio Delta Audiophile 192 again
by Computer AG im FSK 07 Mar '08

07 Mar '08

Hi, we didn't recieve an reply on our last email, so once again we are asking for support. Of course we know that everybody's time is small... We would like to know if someone will work on the bug https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3313 We repeat our offer of lending one card to someone who would like to fix it, like the reporter of the bug did. The GPL Version of the Open Sound System get this card working, so I hope it will not be that much work compared to other bugs ? If nobody will find time to fix it, a definetive answer would be nice so we can sell our 4 cards. But the probable loss of selling 4 card and buying 4 new ones could better be a donation for the alsa project ;) So please please help us out, we would be more than glad to give the money to the project than to loose it buying 4 new cards. Greetings, Toast

1 0

[alsa-devel] HDA Codecs: add support for Toshiba Equium L30
by Tobin Davis 07 Mar '08

07 Mar '08

This patch adds support for the Toshiba Equium L30 laptop and renames the mixer controls to match Laptop usages. Signed off by Tobin Davis <tdavis(a)dsl-only.net>

2 1

[alsa-devel] What recommended performance for ALSA(ASoC)?
by Jinyoung Park 07 Mar '08

07 Mar '08

Hello, I tred developing new ALSA(ASoC) driver for our company's embedded processor. Our processor supported I2S and DMA. So, my ALSA drvier implementation using DMA. I was tested my ALSA driver. When I play wav file(sample rate 44100) using aplay( aplay -M -D hw:0,0 test.wav), sometimes occured breaks. Also, play mp3 file(sample rate 44100Hz) using madplay and mpg123, sometimes occured noises. So, I was tested wav file and mp3 file that down sampling 44100 -> 22050. They was not occurring break and decreasing noises. I tried improving my ALSA driver, optimize souce code and change variety buffer size and period size. But It doesn't improve much. In my guess, my target system is not enough performance because ALSA is heavy. Target system' processor(ARM9) clock is 200MHz and BogoMIPS is 99.6(cat /proc/cpuinfo). Linux kernel version is 2.6.24.1. What recommended performance for ALSA(ASoC)? If my target system is enough performance, shall I do that solve problem? Thanks.

3 2

[alsa-devel] [RFC] add a "private" field to the ac97 struct
by Sebastian Siewior 06 Mar '08

06 Mar '08

I have a PowerPC board with an AC97 controller and that one has an UCB1400 attached. Currently the UCB1400 driver discovers the interrupt via probing. This doesn't really work here. The resources are read from the device tree. I haven't found any other driver besides ucb1400_ts that uses the ac97_bus_type so I can't check where others get their HW information from. My proposal is to introduce a new field in struct snd_ac97 where the AC97 driver can leave the required HW info regarding the attached (in my case the interrupt for the ucb1400) before calling snd_card_register(). I attached just a single int field since I am not aware if multiple devices / resource are realistic / possible. In that case maybe a void * or struct platform_device would be a better choice. Signed-off-by: Sebastian Siewior <sebastian(a)breakpoint.cc> --- drivers/input/touchscreen/ucb1400_ts.c | 13 ++++++++----- include/sound/ac97_codec.h | 2 ++ 2 files changed, 10 insertions(+), 5 deletions(-) diff --git a/drivers/input/touchscreen/ucb1400_ts.c b/drivers/input/touchscreen/ucb1400_ts.c index 607f993..95d1fea 100644 --- a/drivers/input/touchscreen/ucb1400_ts.c +++ b/drivers/input/touchscreen/ucb1400_ts.c @@ -492,11 +492,14 @@ static int ucb1400_ts_probe(struct device *dev) goto err_free_devs; } - error = ucb1400_detect_irq(ucb); - if (error) { - printk(KERN_ERR "UCB1400: IRQ probe failed\n"); - goto err_free_devs; - } + if (!ucb->ac97->device_irq) { + error = ucb1400_detect_irq(ucb); + if (error) { + printk(KERN_ERR "UCB1400: IRQ probe failed\n"); + goto err_free_devs; + } + } else + ucb->irq = ucb->ac97->device_irq; error = request_irq(ucb->irq, ucb1400_hard_irq, IRQF_TRIGGER_RISING, "UCB1400", ucb); diff --git a/include/sound/ac97_codec.h b/include/sound/ac97_codec.h index 0148058..bf920a2 100644 --- a/include/sound/ac97_codec.h +++ b/include/sound/ac97_codec.h @@ -474,6 +474,8 @@ struct snd_ac97 { struct snd_ac97_build_ops * build_ops; void *private_data; void (*private_free) (struct snd_ac97 *ac97); + /* device attached to the AC97 bus */ + int device_irq; /* --- */ struct snd_ac97_bus *bus; struct pci_dev *pci; /* assigned PCI device - used for quirks */ -- 1.5.3.5

3 3