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

[alsa-devel] hda-codec - Add HP Pavillion quirk to Realtek code.
by Tobin Davis 12 Jun '07

12 Jun '07

This patch adds the HP Pavillion a1589L desktop system to the ALC883 configuration table. Signed off by Tobin Davis <tdavis(a)dsl-only.net> Resent from the correct email address. Ignore previous email.

2 1

[alsa-devel] snd_pcm_lib_malloc_pages()
by Timur Tabi 12 Jun '07

12 Jun '07

Liam Why do none of the ASoC drivers use snd_pcm_lib_malloc_pages()? They all allocate their DMA buffers by hand. -- Timur Tabi Linux Kernel Developer @ Freescale

2 1

[alsa-devel] [ASoC] machine driver and channel configuration
by Matthieu CASTET 12 Jun '07

12 Jun '07

Hi, If the platform/cpu_dai driver and codec support capture and playback channels. But on the board only the playback link is connected. In this configuration, the codec and platform/cpu_dai driver shouldn't try to use the capture path (and the resource associated to this). Is there a way to do something like that ? Thanks Matthieu

3 3

[alsa-devel] Questions on usb audio development
by LCID Fire 12 Jun '07

12 Jun '07

Hi. I know there is quite some documentation how to develop a pci driver for alsa - but since I'll try to get a usb device working I was wondering how to write a usb driver? Is it just the same? How to interface the various aspects of the device with regards to descriptor reading, ...

4 11

[alsa-devel] hda-codec - Add HP Pavillion quirk to Realtek code.
by Tobin Davis 11 Jun '07

11 Jun '07

This patch adds the HP Pavillion a1589L desktop system to the ALC883 configuration table. Signed off by Tobin Davis <tdavis(a)dsl-only.net>

1 0

[alsa-devel] Patch - Revo7.1 PCM Playback Switch
by dustin＠seznam.cz 11 Jun '07

11 Jun '07

Hello Takashi, I have attached a patch to support mute for front channels of M-Audio Revolution 7.1 (the DAC AK4381 features a mute bit). Signed-off-by: Pavel Hofman <dustin at seznam.cz> Please could I ask you for your opinion on the following issue (so far no response): I am working together with Ctirad on supporting more capture channels in E-MU1212. So far we have managed to increase the number of channels from the default of 8 to 16 (A_FXWC2 = 0xffffffff, added new snd_emu10k1_audigy_dsp_convert_32_to_2x16 calls in emufx.c). There is still a number of issues to solve but the 16 channel capture already works fine. I would like to get your opinion on the form of adding this support to the module. The options are either hard-coding the 16 capture channels into the code, assuming that users would prefer as many channels as possible and do the routing in jack, or introducing a module parameter emu1010-capture-channels (range e.g. 1 to 16 - untested yet) and leaving the default number at the existing 8. Furthermore, the PCMs other than efx seem to be of no use for the EMU-1x1x models, probably fairly confusing for new users. Would you find it OK, if they were removed for this specific card (if (emu->card_capabilities->emu1010)), keeping only the playback and capture PCM id 2? Thanks a lot for your suggestions. Based on them, I will prepare the patch (with comments on what we found out about the card - it is a pitty that the driver has almost no big-picture comments on the supported cards' specifics, making new developers spend a number of long nights going through the nontrivial code and guessing). Best regards, Pavel.

4 7

Re: [alsa-devel] [2/3] 2.6.22-rc4: known regressions v2
by Michal Piotrowski 09 Jun '07

09 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 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> Handled-By : Takashi Iwai <tiwai(a)suse.de> Status : Unknown IDE Subject : libata and legacy ide pcmcia failure References : http://lkml.org/lkml/2007/5/17/305 Submitter : Robert de Rooy <robert.de.rooy(a)gmail.com> Handled-By : Mark Lord <mlord(a)pobox.com> Status : problem is being debugged SATA/PATA Subject : 22-rc3 broke the CDROM in Dell notebook References : http://lkml.org/lkml/2007/5/27/63 Submitter : Gregor Jasny <gjasny(a)googlemail.com> Handled-By : Tejun Heo <htejun(a)gmail.com> Jeff Garzik <jeff(a)garzik.org> Caused-By : Tejun Heo <htejun(a)gmail.com> commit d4b2bab4f26345ea1803feb23ea92fbe3f6b77bc Status : problem is being debugged Sparc64 Subject : 2.6.22-rc broke X on Ultra5 References : http://lkml.org/lkml/2007/5/22/78 Submitter : Mikael Pettersson <mikpe(a)it.uu.se> Handled-By : David Miller <davem(a)davemloft.net> Status : problem is being debugged Regards, Michal -- "Najbardziej brakowało mi twojego milczenia." -- Andrzej Sapkowski "Coś więcej"

2 1

[alsa-devel] probing state of high definition audio card in windows / SigmaTel STAC9221 microphone problems
by Eran Guendelman 09 Jun '07

09 Jun '07

Hi, I am struggling to get the (external) microphone working on a SigmaTel STAC9221 A1 device on my Dell XPS M1210 laptop. I saw other emails indicating that this was still problematic, and the latest drivers from alsa 1.0.14 did not seem to fix the problem. So now that I've started reading and trying to understand the basics behind the hda codec in an effort to fix this problem, I was wondering if it was possible for me to boot into windows (I've got a dual-boot setup), get into a state where the microphone is working, and somehow probe the codec's state at that time (all of the pin configurations, etc.)... then theoretically, if I reproduce that configuration on the linux side, it should work (right?). So the question is, does anyone have a ready-made utility for Windows to do this probe of the high definition audio codec? I could probably try writing one myself, but thought I'd check if it already exists. Thanks. Please send responses by email too (not subscribed).

3 3

[alsa-devel] Sound Devices USBPre
by Brian Phelps 08 Jun '07

08 Jun '07

Hey guys, I contacted Sound Devices at sounddevices.com about writing a Linux driver (I was going to head the project but would take any help I can get) for the USBPre, a 2ch-in 2ch-out USB preamp with highquality balanced XLR Mic inputs. They said that they would love to have a Linux Driver and will provide specs for me, I am still waiting on the info though. I have not asked if I can view their firmware sourcecode yet, and if it requires an NDA, I will have to work around that. What advice do you have for writing a driver for alsa? I have written some small kernel drivers for embedded Linux devices, a few audio programs in C, and I come from a DSP background, but I am not sure exactly where to start, besides the specs and firmware. Thanks for your help -Brian Phelps

1 0

[alsa-devel] Callback trouble
by Juan Manuel Lopez Baio 08 Jun '07

08 Jun '07

Hello. I'm having some problems with the asynchronous usage of ALSA API, and I'm not sure if this usage is correct. What I have done so far is the following: I have an class that encapsulates the ALSA API, working in a multithreaded environment. I use alsa to capture audio and want to do so in an asynchronous and non-blocing way, so I defined a static method in my class that functions as callback, which receives a pointer to the instance of my class and calls on a member function, like this: void alsaDevice::myCallback(snd_async_handler_t *handler) //STATIC { alsaDevice *dev = (alsaDevice*)snd_async_handler_get_callback_private(handler); dev->triggerCondition(); } void alsaDevice::triggerCondition() { LogError(0,"Trigger en placa %d device %d",cn,dn); m_condMutex.lock(); m_noDataCondition.trigger(); m_condMutex.unlock(); } To init ALSA, I do this: int mode = SND_PCM_ASYNC | SND_PCM_NONBLOCK; if ((err=snd_pcm_open(&pcm_cap_handle, pcm_name.str().c_str(), SND_PCM_STREAM_CAPTURE, mode) < 0)) { LogError(0,"Opening ALSA PCM device %s: %s",pcm_name.str().c_str(),snd_strerror(err)); pcm_cap_handle=NULL; return false; } then set all the pertinent parameters, and finally if((asyncaddresult=snd_async_add_pcm_handler(&ahandler,pcm_cap_handle,alsaDevice::myCallback,this))<0) { LogError(0,"No se pudo registrar la callback; PCM Error: %i",asyncaddresult); } if ((asyncaddresult=snd_pcm_start(pcm_cap_handle))<0) LogError(0,"No se pudo start pcm; PCM Error: %i",asyncaddresult); Afterwards, the first time that a call to snd_pcm_readn returns EAGAIN I call wait() on a condition object with a 100 ms timeout, which is triggered by the callback, as seen before. The problem is that the callback never seems to get called (so shows the log), so I'm not really sure if the previous steps were right. Any light you can shed on this would be much appreciated. Thanks! juan

1 0