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

[alsa-devel] [PATCH] Add SSID for Dell XPS400 to stac922x_cfg_tbl[]
by Daniel T. Chen 08 Jun '07

08 Jun '07

Hi, Attached please find an hg changeset against current alsa-kernel tip adding a quirk entry for a Dell XPS400. Thanks, Daniel Chen

2 1

[alsa-devel] Testing/forcing XRUN
by Eliot Blennerhassett 08 Jun '07

08 Jun '07

Hi, I want to test my driver behaviour when an xrun happens. I have tried using aplay/arecord, and suspending (ctrl-Z) them while playing/recording but this doesn't have the desired effect. (I don't see my driver code detecting an xrun). Instead I see a trigger-stop command to the driver. The apps do report an overrun when they are restarted though. Can anyone answer these: 1) Is this a valid way to simulate an xrun due to application not keeping up? 1.1) If not, what is? Do I have to write an app that deliberately starves the streams? 2) Where is the xrun being detected if my driver doesnt see it? Where does the trigger-stop command come from when I suspend the app? thanks Eliot Blennerhassett AudioScience Inc.

2 1

[alsa-devel] Audio driver for omap 24xx.
by Pharaoh . 07 Jun '07

07 Jun '07

Hi I am referring the EAC driver for omap 24xx which is used by n800 board. The EAC 24xx driver doesn't look complete since it has only hardware init sequences and very basic ALSA related functionalities i.e. register the sound card etc. Is omap 24xx eac driver still in intermediate stage?Or it is complete but not yet integrated in to omap git tree? In later case, where can I find the complete eac driver? Also, omap 24xx driver doesn't seem to follow the framework/structure of other omap alsa drivers in sound/arm/omap/ , any particular reason? Please enlighten. I know this might be little off topic here, but there are only two places where I can ask this question, so I am trying both. -pharaoh.

2 1

[alsa-devel] Surround sound problem with CS46xx
by Vasilis Manwlopoulos 06 Jun '07

06 Jun '07

Hi to everybody, I am kind of new in linux and to alsa and I am facing a problem with the setup for 5.1 surround sound with my sound card Hercules Fortissimo III, recognized having the chip cs46xx. I have managed to enable surround sound by creating a .asounrc file with the followings pcm.!default { type plug slave.pcm "surround51" slave.channels 6 route_policy duplicate } The problem is that I am facing weird cpu load spikes (sometimes isn't just spikes, but just 99% usage for a long time!) even when just playing a normal mp3 file at 128Kbps. This is happening when playing with various players (totem,rhythbox,vlc). Also the sound has cracklings or there is a delay between the front and the rear speakers. i have send this email to alsa-users too, but since there wasn't anyone to propose a workaround I was adviced to also send it to alsa-devel. I am using the distro ubuntu 7.04 with the default alsa libraries version 1.0.13ubuntu5. So, if anyone has any idea plz give me a hint, cause I am stuck with it about two weeks now, without having any clue to proceed with!!! PS. If any other information or command output is necessary to help me, tell me so.

1 0

[alsa-devel] [ASoC]Changing the order of trigger in soc_pcm_trigger
by Nobin Mathew 06 Jun '07

06 Jun '07

Liam, I have one suggestion. Can we use this if (rtd->codec_dai->ops.trigger) { ret = rtd->codec_dai->ops.trigger(substream, cmd); if (ret < 0) return ret; } if (rtd->cpu_dai->ops.trigger) { ret = rtd->cpu_dai->ops.trigger(substream, cmd); if (ret < 0) return ret; } if (platform->pcm_ops->trigger) { ret = platform->pcm_ops->trigger(substream, cmd); if (ret < 0) return ret; } Instead of if (rtd->codec_dai->ops.trigger) { ret = rtd->codec_dai->ops.trigger(substream, cmd); if (ret < 0) return ret; } if (platform->pcm_ops->trigger) { ret = platform->pcm_ops->trigger(substream, cmd); if (ret < 0) return ret; } if (rtd->cpu_dai->ops.trigger) { ret = rtd->cpu_dai->ops.trigger(substream, cmd); if (ret < 0) return ret; } That means trigger the Cpu before pcm. Because most of the controllers needs to be initialized and triggered before external DMA is triggered. Correct me if i am going wrong. This was causing so many problems in my hardware. Nobin Mathew

2 2

[alsa-devel] Realtek 268
by Steven Zakulec 06 Jun '07

06 Jun '07

Hello ALSA developers, I have one of the Intel HDA cards that is not supported currently: Realtek 268. It was previously mentioned in May (http://mailman.alsa-project.org/pipermail/alsa-devel/2007-May/000828.html). The post seemed to imply it was not a terribly difficult task to add support for the card, but was very vague on details. If it is in fact just a matter of copying an existing preset and changing the values, I would probably try to do it myself. If it is any more difficult than that, I'd like to formally ask the developers if they could add any support for the card. The lspci and /proc/asound/codec info is identical to that in the posting I mentioned. If you need anymore information, I would be happy to provide it. Thank you!

2 1

[alsa-devel] Connecting two USB-Soundcard to JACK
by Carsten Beth 06 Jun '07

06 Jun '07

Hello! We want to connect two USB soundcards to one multichannel device at the alsa layer and to use that virtual device with JACK. But we don't find a way to do so. The USB soundcard is self-made. It woks as a high speed USB device with sample rates of up to 96 KHz, has four capture and two playback cannels. The clocks of two cards can be synchronized at hardware level. Using one card by its own works perfectly both, at the alsa and at the JACK level, also as a duplex device. All is done with alsalib 1.0.13, jackd 0.101.1 and qjackctl 0.2.21. Now I'm trying to build a virtual device with 8 capture and 4 playback channels at the alsa level. But, as it can be read at several locations, this only works for capture only or playback. It has been reported, that duplex operation is possible after patching pcm_multi.c. I have applyed the patch, but this has not changed anything. Now I want to ask you for support, to get the device running. I made some experiments with different configurations of alsa/jackd and had some strange results. You can read about the results and used the asoundrc below. Questions, that I can't answer are - Why do I see just the channels of one card when using the multi plugin in try 2), 5) and 7)? - Why is the processor load so high with playback only in try 2) and 3) but not in duplex operation? - Why are there lots non-adible xruns with playback only in try 2) and 3)? 1) playback only with p_multi ALSA: mmap-based access is not possible for the playback stream of this audio interface 2) playback only with p_multi_plug Playback of just the 1st cards two channel. Lot of processor load: Both cores of the Core Duo 2GHz system are at about 90% load. Lot of XRUNs: 08:01:35.514 XRUN callback (48501 skipped). 08:01:37.517 XRUN callback (80633 skipped). 08:01:39.519 XRUN callback (70612 skipped). but XRUNS can't be heard. Sometimes jackd terminates after a while: ALSA: could not complete playback of 256 frames: error = -32 cycle execution failure, exiting DRIVER NT: could not run driver cycle jack main caught signal 12 [...] zombified - calling shutdown handler [...] 08:01:40.926 Post-shutdown script terminated with exit status=256. 3) playback only with p_multi_route Number of channels as expected (4 channels, two from each card). Lot of processor load, like 2) Lot of non-adible XRUNS, like 2). Sometimes jackd terminates after a while with the same message as in 2). 4) capture only with c_multi ALSA: mmap-based access is not possible for the capture stream of this audio interface 5) capture only with c_multi_plug Captures just two channel from the 1st card Low processor load (near 0%) No XRUNS. 6) capture only with c_multi_route Number of channels as expected (8 channels, four from each card). Low load and no XRUNS, like 5) 7) duplex with p_multi_plug and c_multi_plug Playback and capture works just for the 1st card (two playback and 4 capture channels). Low processor load, like 2) Lot of XRUNs, but less the 2) (and now the XRUNS can be heard). Here is a snip: **** alsa_pcm: xrun of at least 0.010 msecs 11:34:00.013 XRUN callback (9 skipped). **** alsa_pcm: xrun of at least 0.014 msecs 11:34:02.037 XRUN callback (11 skipped). **** alsa_pcm: xrun of at least 0.018 msecs **** alsa_pcm: xrun of at least 0.016 msecs 11:34:04.069 XRUN callback (11 skipped). **** alsa_pcm: xrun of at least 0.016 msecs 11:34:06.099 XRUN callback (11 skipped). **** alsa_pcm: xrun of at least 0.018 msecs **** alsa_pcm: xrun of at least 0.013 msecs 11:34:08.116 XRUN callback (12 skipped). Sometimes jackd terminates after a while with the same message as in 2). 8) duplex with p_multi_route and c_multi_route Exactly the same as in 7) expect for the number of channels. Now all channels are available (four playback and four capture channels) Here the used asoundrc: ##################################### # 1st USB card ##################################### pcm.usb0 { type hw card 1 } ctl.usb0 { type hw card 1 } ##################################### # 2nd USB card ##################################### pcm.usb1 { type hw card 2 } ctl.usb1 { type hw card 2 } pcm.p_multi { type multi; slaves.a.pcm "usb0"; slaves.a.channels 2; slaves.b.pcm "usb1"; slaves.b.channels 2; bindings.0.slave a; bindings.0.channel 0; bindings.1.slave a; bindings.1.channel 1; bindings.2.slave b; bindings.2.channel 0; bindings.3.slave b; bindings.3.channel 1; } ctl.p_multi { type hw; card 1; } pcm.c_multi { type multi; slaves.a.pcm "usb0"; slaves.a.channels 4; slaves.b.pcm "usb1"; slaves.b.channels 4; bindings.0.slave a; bindings.0.channel 0; bindings.1.slave a; bindings.1.channel 1; bindings.2.slave a; bindings.2.channel 2; bindings.3.slave a; bindings.3.channel 3; bindings.4.slave b; bindings.4.channel 0; bindings.5.slave b; bindings.5.channel 1; bindings.6.slave b; bindings.6.channel 2; bindings.7.slave b; bindings.7.channel 3; } ctl.c_multi { type hw; card 1; } pcm.p_multi_plug { type plug; slave.pcm "p_multi"; ttable.0.0 1; ttable.1.1 1; ttable.2.2 1; ttable.3.3 1; } ctl.p_multi_plug { type hw; card 1; } pcm.c_multi_plug { type plug; slave.pcm "c_multi"; ttable.0.0 1; ttable.1.1 1; ttable.2.2 1; ttable.3.3 1; ttable.4.4 1; ttable.5.5 1; ttable.6.6 1; ttable.7.7 1; } ctl.c_multi_plug { type hw; card 1; } pcm.p_multi_route { type route; slave.pcm "p_multi"; ttable.0.0 1; ttable.1.1 1; ttable.2.2 1; ttable.3.3 1; } ctl.p_multi_route { type hw; card 1; } pcm.c_multi_route { type route; slave.pcm "c_multi"; ttable.0.0 1; ttable.1.1 1; ttable.2.2 1; ttable.3.3 1; ttable.4.4 1; ttable.5.5 1; ttable.6.6 1; ttable.7.7 1; } ctl.c_multi_route { type hw; card 1; } Thank you Carsten Beth -- Dipl.-Inform. Carsten Beth OFFIS - Institute for Information technology R&D Division Embedded Hardware-/Software-Systems Escherweg 2 - 26121 Oldenburg - Germany - http://www.offis.de/ Phone: +49-441-9722-241 - Fax: +49-441-9722-282

1 0

Re: [alsa-devel] Power management state flow in ALSA
by Nobin Mathew 06 Jun '07

06 Jun '07

Liam, In soc_resume() we should do this snd_power_change_state(codec->card, SNDRV_CTL_POWER_D0); instead of snd_power_change_state(codec->card, SNDRV_CTL_POWER_D3hot); Because snd_pcm_resume in pcm_native.c expects the card to be in SNDRV_CTL_POWER_D0 state. Other ioctl will wait forever. static int snd_pcm_resume(struct snd_pcm_substream *substream) { struct snd_card *card = substream->pcm->card; int res; snd_power_lock(card); if ((res = snd_power_wait(card, SNDRV_CTL_POWER_D0)) >= 0) res = snd_pcm_action_lock_irq(&snd_pcm_action_resume, substream, 0); snd_power_unlock(card); return res; } One more thing why we are using snd_power_change_state(codec->card, SNDRV_CTL_POWER_D3cold); every other driver is doing snd_power_change_state(card, SNDRV_CTL_POWER_D3hot); SNDRV_CTL_POWER_D3cold is true for deep sleep where power to the controller is switched off . In sleep, only clock to the controller is switched off. Nobin Mathew On 6/4/07, Nobin Mathew <nobin.mathew(a)gmail.com> wrote: > Liam > > I will get back, i need to set up the board > > On 6/1/07, Liam Girdwood <lg(a)opensource.wolfsonmicro.com> wrote: > > Nobin, > > > > Can you try the following patch :- > > > > http://opensource.wolfsonmicro.com/cgi-bin/gitweb/gitweb.cgi?p=linux-2.6-as… > > > > This will notify pcm's of their suspend state. > > > > Liam > > > > On Wed, 2007-05-30 at 12:58 +0200, Takashi Iwai wrote: > > > At Wed, 30 May 2007 16:06:54 +0530, > > > Nobin Mathew wrote: > > > > > > > > I am writing an ASoC driver, where i can place these calls > > > > > > > > snd_power_change_state(card, SNDRV_CTL_POWER_D3hot); > > > > snd_pcm_suspend_all(chip->pcm[i]); > > > > > > > > and snd_power_change_state(card, SNDRV_CTL_POWER_D0); > > > > > > > > > > > > In soc-core.c ? > > > > > > I suppose so. > > > In soc_suspend() and soc_resume(), you can get the card instance from > > > codec->card, at least. > > > > > > But currently SoC doesn't keep the PCM instances, so it cannot be > > > implemented as it is... Liam, any plan or known issue regarding this? > > > > > > > > > Takashi > > > > >

1 0

[alsa-devel] Problem restarting alsa: can't set buffer size
by Juan Manuel Lopez Baio 06 Jun '07

06 Jun '07

Hello. I'm developing an application that records input from ALSA and process it. To do so I user the API starting with snd_pcm_open and follow with the parameters settings and so on, and once the app is done and exits, it closes with snd_pcm_hw_params_free and snd_pcm_close. The problem is that afterwards, if I restart the application, I can't set up ALSA, becausea continuous calls to snd_pcm_hw_params_set_buffer_size always fail (I start with a buffer size of 8192 and keep dividing it by 2). I finally have to restart the system in order to get it to work again. I'm on a Mandriva box with gcc 4.1.2 ¿Any thoughts on this? Thanks in advance! juan

2 1

[alsa-devel] using 'type softvol' in a card conf file in /usr/share/alsa/cards, am i doing this right?
by John L. Utz III 05 Jun '07

05 Jun '07

Hello; I am working with an CMEDIA 8738-MC6 and i am trying to gain control of the second DAC by way of softvolume. but i seem to not be succeeding because my application cant find my 'Rear' control, am i doing this correctly? the original /usr/share/alsa/cards/CMI8738-MC6.conf CMI8738-MC6.pcm.rear.0 { @args [ CARD ] @args.CARD { type string } type hw card $CARD device 1 } i have modified it to look thusly: notice that the type is now softvol and the original hardware description is encapsulated in slave.pcm # 2nd DAC CMI8738-MC6.pcm.rear.0 { @args [ CARD ] @args.CARD { type string } type softvol slave.pcm { type hw card $CARD device 1 } control { name "Rear Playback Volume" card $CARD } } Shouldnt i now be able to see 'Rear Playback Volume' in the output of amixer controls ?? as it stands right now, i can not. what am i doing incorrectly? tnx! johnu

2 2