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

[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

Re: [alsa-devel] [2/5] 2.6.22-rc4: known regressions
by Michal Piotrowski 05 Jun '07

05 Jun '07

Hi all, Here is a list of some known regressions in 2.6.22-rc4. Feel free to add new regressions/remove fixed etc. http://kernelnewbies.org/known_regressions ACPI Subject : ACPI_CPUFREQ fails to load - HP ML110 G4 Xeon 3040 References : http://bugzilla.kernel.org/show_bug.cgi?id=8570 Submitter : Marc Tuerschmann <marc(a)tuerschmann.de> Status : Unknown (possible hardware issues) Subject : unable to shutdown on kernel 2.6.22-rc2 References : http://bugzilla.kernel.org/show_bug.cgi?id=8516 Submitter : Thierry Volpiatto <tvolpiatt(a)neuf.fr> Status : Unknown ALSA Subject : snd-aoa causes badness in lib/kref.c:33 References : http://bugzilla.kernel.org/show_bug.cgi?id=8513 Submitter : Ben Collins <bcollins(a)ubuntu.com> Status : Unknown File systems Subject : OOPS (NULL pointer dereference) in v2.6.22-rc3 References : http://lkml.org/lkml/2007/6/1/389 Submitter : Alex Riesen <raa.lkml(a)gmail.com> Status : Unknown Regards, Michal -- "Najbardziej brakowało mi twojego milczenia." -- Andrzej Sapkowski "Coś więcej"

1 0

[alsa-devel] Alsa-OSS Duplex bug (revisited)
by Alan Horstmann 05 Jun '07

05 Jun '07

About a year ago I posted an explaination of the cause of non-functioning with Alsa-OSS in duplex, together with a workaround patch. After some discussion the thread ended. However since then there has been a steady trickle of downloads of the patches from my host (it can also be found elsewhere) and some reports of great success,eg http://audacityteam.org/forum/thread/1388 (2nd page especially) In attempting to tidy up some loose ends, I hope you can bear with me revisiting this and making the case for it's acceptance. I am aware the Alsa-OSS is not of much interest to developers, and it might be said 'use native Alsa'; however that is not possible or desirable in all applications, and anyway, why provide an OSS emulation that cannot be made to work properly? To summarise the problem first: OSS provides a single SNDCTL_DSP_CHANNELS ioctl; where a device is duplex the number of capture and playback channels cannot be set separately. With original OSS this was not a problem AFAIK because separate devices are created for capture and playback, ie they are not used duplex. However Alsa-OSS in most cases creates a single combined device, which only operates correctly when an equal number of capture and playback channels are used. The Workaround: The workaround I proposed and now use constantly is like a secret trapdoor. Where the existing interface is adequate (ie captue channels == playback channels, or non-duplex) nothing changes, and SNDCTL_DSP_CHANNELS is set with a number between 0 and 128. It is fully compatible with apps that don't know of the secret door -the front door is used! However, if an app needs to set capture channels != playback channels, in duplex, at present the stream will malfunction every time. But with this patch applied, if the app knows the workaround, then it can simply set SNDCTL_DSP_CHANNELS as playback + 256*capture channels, and this will be interpreted correctly in the patched Alsa-OSS and the stream functions correctly. As I say, there is therefore no loss of compatibility in either direction. Providing the app only uses the special formula when necessary rather than always, it is only providing a way to fix something that is broken. It would seem to me of value to add the patch to Alsa so that the workaround can be effected by changes to the app only, without also having to patch and compile a replacement Alsa. Whilst it is by no means ideal, it does overcome the underlying problem successfully. Details of the workaround could be added to the OSS-Emulation.html document. Patch for 1.0.14rc4 is attached for consideration, together with example portaudio patch. Regards Alan

3 15

[alsa-devel] ALSA 1.0.14 release
by Jaroslav Kysela 04 Jun '07

04 Jun '07

Hi all, finally, ALSA 1.0.14 is out. For list of changes, please, check: http://www.alsa-project.org/changes/v1-0-13--v1-0-14.txt http://www.alsa-project.org/changes/v1-0-14rc4--v1-0-14.txt Jaroslav ----- Jaroslav Kysela <perex(a)suse.cz> Linux Kernel Sound Maintainer ALSA Project, SUSE Labs

2 1