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

Re: [alsa-devel] [RFC] [PATCH 0/2] ASoC sound support forSMDK2440boards
by Jose Henrique Spahn Torres 30 May '07

30 May '07

-----Original Message----- From: Zoltan Devai [mailto:zdevai@gmail.com] Sent: sexta-feira, 25 de Maio de 2007 14:40 To: Jose Henrique Spahn Torres Subject: Re: [alsa-devel] [RFC] [PATCH 0/2] ASoC sound support forSMDK2440boards 2007/5/25, Jose Henrique Spahn Torres <jose.torres(a)eldorado.org.br>: > > 2007/5/24, Jose Henrique Spahn Torres <jose.torres(a)eldorado.org.br>: > usbcore: registered new interface driver hci_usb Advanced Linux Sound > Architecture Driver Version 1.0.14rc4 (Wed May 16 > 09:45:46 2007 UTC). > ASoC version 0.13.1 > SMDK2440 ALSA SoC Audio driver > UDA1341 SoC Audio Codec > L3 write > L3 transfer > L3 sendbyte: 16 > L3 sendbyte: 40 > asoc: UDA1341 <-> s3c24xx-i2s mapping ok ALSA device list: > #0: SMDK2440 (UDA1341) > TCP cubic registered > ... Fine. > However, when triyng to play something I get this: > > asoc: machine hw_params failed > > This is in sound/soc/soc-core.c, line 494. > I couldn't go any futher then this. > Any hint? This combination of processor, crystal and codec only supports the following rates: 11.025 Khz, 22.050Khz and 44.100 Khz Please try to play a file with these sample rates. (If you have alsa-tools, you could try 'speaker-test -r 44.100'). BTW, could you tell me the freq of the crystal on the processor board ? (Is it 16.934 Mhz?) Zoltan Hi, I used speaker-test as indicated above and the result is: pendrive $ ./speaker-test -r 44100 speaker-test 1.0.11 Playback device is default Stream parameters are 44100Hz, S16_LE, 1 channels Using 16 octaves of pink noise ALSA lib pcm.c:2146:(snd_pcm_open_noupdate) Unknown PCM default Playback open error: -2,No such file or directory ALSA lib pcm.c:2146:(snd_pcm_open_noupdate) Unknown PCM default Playback open error: -2,No such file or directory ALSA lib pcm.c:2146:(snd_pcm_open_noupdate) Unknown PCM default Playback open error: -2,No such file or directory ALSA lib pcm.c:2146:(snd_pcm_open_noupdate) Unknown PCM default Playback open error: -2,No such file or directory ALSA lib pcm.c:2146:(snd_pcm_open_noupdate) Unknown PCM default Playback open error: -2,No such file or directory I have also tried: /pendrive $ ./aplay -f cd 01-jack_johnson-times_like_these-rns.wav ALSA lib pcm.c:2146:(snd_pcm_open_noupdate) Unknown PCM default aplay: main:547: audio open error: No such file or directory /pendrive $ so I don't know what is happening here. Does anyone have any idea? Thanks, Henrique

3 3

[alsa-devel] Fw: hardware not asking for more data using asyn call back
by stan 30 May '07

30 May '07

Begin forwarded message: Date: Tue, 29 May 2007 15:19:12 -0400 From: "Ashlesha Shintre" <ashlesha.shintre(a)gmail.com> To: stanl(a)cox.net, alsa-devel(a)alsa-project.org Subject: Re: hardware not asking for more data using asyn call back Hi, Thanks Stan, for your response - Instead of copying pcm data from a wav file, i decided to copy all the data to a master buffer first and then see if the circular buffer implementation works - so now instead of copying from the wave file, i m copying data from the master buffer to the circular buffer.. however, as per your suggestion, if i copy the data in the while loop in main, then, it might not always be copied between 2 consecutive callbacks, but maybe more, as the callbacks are asynchronous. however, the hardware still does not ask for more data after executing the callback function about twice -- is there a way to flush the hardware buffer before beginning playback? I have pasted my code below Regards, Ashlesha. <snip> I've been doing some thinking about what you are trying to accomplish and have a suggestion. I think you would be better off letting jack handle the back end/sound portion. Run a daemon/service listening on an arbitrary tcp/ip port. On startup it initializes alsa and jack. When it receives a request, it forks a process which opens a new channel on jack and creates a buffer for it. It then plays the sound it receives on that link via jack, silence when the buffer is empty. You would have to write client software for the user on the network to contact your daemon/service. You might even find something like this already out there.

1 0

[alsa-devel] How the dma interrupt handlers have been registered in ALSA?
by Pharaoh . 30 May '07

30 May '07

Hi I am referring omap-alsa-dma.c and the related codec files. We usually register the IRQ handler by calling request_irq() function but in this mentioned files the IRQ handler etc is defined but it is not registered anywhere i.e. request_irq is not used anywhere. Is there any other way of registering irq handlers? The irq handlers address is passed to omap_request_dma, but there also it is not registered. I am missing the entire thing?

2 3

[alsa-devel] [1/4] 2.6.22-rc3: known regressions
by Michal Piotrowski 30 May '07

30 May '07

Hi all, Here is a list of some known regressions in 2.6.22-rc3. Feel free to add new regressions/remove fixed etc. http://kernelnewbies.org/known_regressions Unclassified Subject : long freezes on thinkpad t60 References : http://lkml.org/lkml/2007/5/24/100 Submitter : Miklos Szeredi <miklos(a)szeredi.hu> Handled-By : Ingo Molnar <mingo(a)elte.hu> Status : problem is being debugged ACPI 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 in dentry_iput with 2.6.22-rc2 on AMD64 References : http://lkml.org/lkml/2007/5/22/4 Submitter : Florin Iucha <florin(a)iucha.net> Status : Unknown Kbuild Subject : make M=$PWD modules_install does nothing References : http://lkml.org/lkml/2007/5/27/190 Submitter : Andrey Borzenkov <arvidjaar(a)mail.ru> Status : Unknown Regards, Michal -- "Najbardziej brakowało mi twojego milczenia." -- Andrzej Sapkowski "Coś więcej"

4 3

Re: [alsa-devel] hardware not asking for more data using asyn call back
by stan 30 May '07

30 May '07

Somehow I replied to the wrong message and it went to a personal email address. Putting it on the list so searches can find it (for what that is worth :-) ) Begin forwarded message: Date: Tue, 29 May 2007 18:18:22 -0700 From: stan <stanl(a)cox.net> To: "Ashlesha Shintre" <ashlesha.shintre(a)gmail.com> Subject: Re: hardware not asking for more data using asyn call back On Tue, 29 May 2007 15:19:12 -0400 "Ashlesha Shintre" <ashlesha.shintre(a)gmail.com> wrote: <snip> I didn't understand what you were asking before. It sounds to me like you want to have a thread running that accepts input from arbitrary processes and puts it in the main buffer. Then when the alsa callback occurs you want to take any new sound samples and send them to alsa. If that is the case, it makes more sense for the main buffer to be the circular buffer and the alsa buffer to be just a regular buffer. That's just personal preference though. As far as the handle error, I don't know what it means beyond what it says. You would have to look in the sources for the alsa library to see what causes that error to be generated. I don't see anything wrong in the logic of the code below, but the output indicates that you are not keeping up with the play rate. This is astonishing. At each play you can see that the available room in the buffer grows larger until larger than 1000, the buffer you have allocated. I'm not sure what infinite loop means and how your program is recovering from it. I presume that is where the time is being eaten up that isn't allowing you to keep up with the requests for data. I don't think you need to check if there is room when you get a callback. You should be able to just write the data to alsa using the writei call. i.e. eliminate the snd_pcm_avail_update call. I'm not familiar enough with alsa to help you further. Perhaps someone else can give you a hint or point you to the right place to look. > > /* Reading wav file into a buffer and then trying to play it */ > > > > #include <stdio.h> > > #include </usr/include/alsa/asoundlib.h> > > #include </usr/include/alsa/pcm.h> > > #include <sys/types.h> > > #include <unistd.h> > > #include <fcntl.h> > > > > #define SIZE 128 > > //mpos is the position in the master buffer to write from > > short int *buffer, *mbuf, *mpos; > > int ind=10, fd1, length; > > static snd_pcm_t *handle; > > static char *device = "default"; /* playback > > device */ > > snd_output_t *output = NULL; > > static short int *wto, *rfrom, buflen; > > > > void MyCallback(snd_async_handler_t *pcm_callback); > > > > int main() > > { > > int i,j,n,count,a,err,k=0; > > char c; > > snd_pcm_sframes_t frames; > > snd_async_handler_t *pcm_callback; > > > > > > > > if((fd1=open("SA2.WAV",O_RDONLY,0))==-1) > > printf("error opening wav file\n"); > > > > count=0; > > while(count++<40) > > a=read(fd1,&c,sizeof(char)); > > > > a=read(fd1,&length,sizeof(int)); > > > > n=length/SIZE; > > > > printf("length = %d\n",length); > > mbuf = (short int *) malloc (length * sizeof(short int)); > > mpos = &mbuf[0]; > > > > buflen = 4*SIZE; > > buffer = (short int *) malloc (buflen*sizeof(short int)); > > > > wto = NULL; > > rfrom = &buffer[0]; > > > > /* reading to master buffer */ > > count=0; > > a=1; > > while(count<length && a>0) > > a=read(fd1,&mbuf[count++],sizeof(short int)); > > if(a<0){ > > printf("error in reading from wav file\n"); > > exit(1); > > } > > close (fd1); > > > > for(count =0; count < buflen; count++) > > { > > buffer[count]=mbuf[count]; > > } > > /******************************/ > > > > /*ALSA DEV INIT*/ > > if((err = snd_pcm_open(&handle, device, > > SND_PCM_STREAM_PLAYBACK, 0)) < 0) { > > printf("error opening device: %s\n",snd_strerror(err)); > > return -1; > > } > > > > if((err = snd_pcm_set_params(handle, > > SND_PCM_FORMAT_S16_LE, > > SND_PCM_ACCESS_RW_INTERLEAVED, > > 1, > > 16000, > > 1, > > 1000)) < 0) { /* 2 sec */ > > printf("Playback open error: %s\n", snd_strerror(err)); > > return -2; > > } > > /*****************************/ > > > > printf("n=%d\n",n); > > for (i=0; i<50; i++) > > { > > printf("i=%d\n",i); > > frames = snd_pcm_writei(handle, rfrom, SIZE); > > if(frames < 0) // underrun > > { > > printf("underrun recovery\n"); > > frames = snd_pcm_recover(handle, frames,0); > > if(frames < 0){ > > printf("error in recovery\n"); > > return -3; > > } > > } > > if(frames >0 && frames < SIZE) > > printf("expected to write %d, wrote %d\n",SIZE,frames); > > > > printf("distance between ptrs before reinit is %d\n",rfrom > > - wto); if(rfrom < &buffer[buflen-1]) > > { > > wto = rfrom; > > rfrom = rfrom + SIZE; > > } > > if(rfrom >= &buffer[buflen-1]) > > { > > printf("rfm at the end, rfrom -buffer[buflen-1] > > =%d\n",(*rfrom - buffer[buflen-1])); > > //wto = rfrom; > > rfrom = &buffer[0]; > > } > > > > if((a = writetobuf())<0) > > printf("error in reading from wav file k = %d\n"); > > > > printf("buffer[i*SIZE] - rfrom = %d\n",(buffer[(i+1)*SIZE] - > > *rfrom)); > > > > } > > > > /* Async Handler */ > > > > > > err = > > snd_async_add_pcm_handler(&pcm_callback,handle,MyCallback,NULL); > > if(err<0) printf("add pcm handler error = > > %d\n%s\n",err,snd_strerror(err)); > > > > err = snd_pcm_start(handle); > > if(err<0) > > printf("error in starting snd pcm start err > > :%s\n",snd_strerror(err)); > > /******************************/ > > > > while (1) { > > > > if(wto == NULL) > > break; // redundancy -- already checking > > for this condition in MyCallback > > printf("infinite loop\n"); > > sleep(1); > > } > > > > err = snd_pcm_close(handle); > > if(err<0) > > printf("error in closing pcm device: > > %s\n",snd_strerror(err)); > > > > return 0; > > } > > > > void MyCallback(snd_async_handler_t *pcm_callback) > > { > > > > snd_pcm_t *pcm_handle = snd_async_handler_get_pcm(pcm_callback); > > snd_pcm_sframes_t avail; > > int count,a; > > snd_pcm_uframes_t period_size = 64; > > snd_pcm_sframes_t frames; > > > > if((avail=snd_pcm_avail_update(pcm_handle)) >= period_size) ^ From the alsa lib api docs. | | Using of this function is useless for the standard read/write operations. Use it only for mmap access. See to snd_pcm_delay. Obtain delay for a running PCM handle. Parameters: pcm PCM handle delayp Returned delay in frames Returns: 0 on success otherwise a negative error code Delay is distance between current application frame position and sound frame position. It's positive and less than buffer size in normal situation, negative on playback underrun and greater than buffer size on capture overrun. > > { > > printf("available frames = %d\n",avail); > > frames = snd_pcm_writei(pcm_handle, rfrom, SIZE); Using rfrom is going to be problematic if you get to a > > if(frames < 0) // underrun > > { > > printf("underrun recovery\n"); > > frames = snd_pcm_prepare(pcm_handle); > > printf("error from snd_pcm_prepare is: > > %d\n",frames); if(frames < 0){ > > printf("error in recovery\n"); > > > > } > > } > > > > if(frames >0 && frames < SIZE) > > printf("expected to write %d, wrote > > %d\n",SIZE,frames); > > > > > > if(rfrom < &buffer[buflen-1]) > > { > > wto = rfrom; > > rfrom = rfrom + SIZE; > > } > > if(rfrom >= &buffer[buflen-1]) > > { > > // wto = rfrom; > > rfrom = &buffer[0]; > > } //location of where to start > > writing from next > > > > if(writetobuf()<0){ > > wto=NULL; > > exit(0); // returns 0 to the operating system -- so > > it ends the program! > > } > > ++ind; > > } > > > > printf("going out of callback, ind = %d\n",ind); > > } > > > > /*Function to copy data from master buffer (mbuf) to circular buffer > > (buffer)*/ > > int writetobuf() > > { > > int count=-1; > > > > while((++count < SIZE) && (mpos < &mbuf[length])) > > *(mpos++) = *(wto+count); > > > > if(mpos >= &mbuf[length-1]) > > return -1; > > else > > return 0; > > } > > i=49 error in starting snd pcm start err :File descriptor in bad state infinite loop inside callback, available frames = 364 going out of callback, ind = 1 infinite loop inside callback, available frames = 577 going out of callback, ind = 2 infinite loop inside callback, available frames = 790 underrun recovery error from snd_pcm_prepare is: 0 going out of callback, ind = 3 infinite loop infinite loop infinite loop

1 0

Re: [alsa-devel] hardware not asking for more data using asyn call back
by Ashlesha Shintre 30 May '07

30 May '07

Hi, Thanks Stan, for your response - Instead of copying pcm data from a wav file, i decided to copy all the data to a master buffer first and then see if the circular buffer implementation works - so now instead of copying from the wave file, i m copying data from the master buffer to the circular buffer.. however, as per your suggestion, if i copy the data in the while loop in main, then, it might not always be copied between 2 consecutive callbacks, but maybe more, as the callbacks are asynchronous. however, the hardware still does not ask for more data after executing the callback function about twice -- is there a way to flush the hardware buffer before beginning playback? I have pasted my code below Regards, Ashlesha. /* Reading wav file into a buffer and then trying to play it */ > > #include <stdio.h> > #include </usr/include/alsa/asoundlib.h> > #include </usr/include/alsa/pcm.h> > #include <sys/types.h> > #include <unistd.h> > #include <fcntl.h> > > #define SIZE 128 > //mpos is the position in the master buffer to write from > short int *buffer, *mbuf, *mpos; > int ind=10, fd1, length; > static snd_pcm_t *handle; > static char *device = "default"; /* playback device > */ > snd_output_t *output = NULL; > static short int *wto, *rfrom, buflen; > > void MyCallback(snd_async_handler_t *pcm_callback); > > int main() > { > int i,j,n,count,a,err,k=0; > char c; > snd_pcm_sframes_t frames; > snd_async_handler_t *pcm_callback; > > > > if((fd1=open("SA2.WAV",O_RDONLY,0))==-1) > printf("error opening wav file\n"); > > count=0; > while(count++<40) > a=read(fd1,&c,sizeof(char)); > > a=read(fd1,&length,sizeof(int)); > > n=length/SIZE; > > printf("length = %d\n",length); > mbuf = (short int *) malloc (length * sizeof(short int)); > mpos = &mbuf[0]; > > buflen = 4*SIZE; > buffer = (short int *) malloc (buflen*sizeof(short int)); > > wto = NULL; > rfrom = &buffer[0]; > > /* reading to master buffer */ > count=0; > a=1; > while(count<length && a>0) > a=read(fd1,&mbuf[count++],sizeof(short int)); > if(a<0){ > printf("error in reading from wav file\n"); > exit(1); > } > close (fd1); > > for(count =0; count < buflen; count++) > { > buffer[count]=mbuf[count]; > } > /******************************/ > > /*ALSA DEV INIT*/ > if((err = snd_pcm_open(&handle, device, SND_PCM_STREAM_PLAYBACK, 0)) < > 0) { > printf("error opening device: %s\n",snd_strerror(err)); > return -1; > } > > if((err = snd_pcm_set_params(handle, > SND_PCM_FORMAT_S16_LE, > SND_PCM_ACCESS_RW_INTERLEAVED, > 1, > 16000, > 1, > 1000)) < 0) { /* 2 sec */ > printf("Playback open error: %s\n", snd_strerror(err)); > return -2; > } > /*****************************/ > > printf("n=%d\n",n); > for (i=0; i<50; i++) > { > printf("i=%d\n",i); > frames = snd_pcm_writei(handle, rfrom, SIZE); > if(frames < 0) // underrun > { > printf("underrun recovery\n"); > frames = snd_pcm_recover(handle, frames,0); > if(frames < 0){ > printf("error in recovery\n"); > return -3; > } > } > if(frames >0 && frames < SIZE) > printf("expected to write %d, wrote %d\n",SIZE,frames); > > printf("distance between ptrs before reinit is %d\n",rfrom - wto); > if(rfrom < &buffer[buflen-1]) > { > wto = rfrom; > rfrom = rfrom + SIZE; > } > if(rfrom >= &buffer[buflen-1]) > { > printf("rfm at the end, rfrom -buffer[buflen-1] > =%d\n",(*rfrom - buffer[buflen-1])); > //wto = rfrom; > rfrom = &buffer[0]; > } > > if((a = writetobuf())<0) > printf("error in reading from wav file k = %d\n"); > > printf("buffer[i*SIZE] - rfrom = %d\n",(buffer[(i+1)*SIZE] - > *rfrom)); > > } > > /* Async Handler */ > > > err = snd_async_add_pcm_handler(&pcm_callback,handle,MyCallback,NULL); > if(err<0) > printf("add pcm handler error = %d\n%s\n",err,snd_strerror(err)); > > err = snd_pcm_start(handle); > if(err<0) > printf("error in starting snd pcm start err > :%s\n",snd_strerror(err)); > /******************************/ > > while (1) { > > if(wto == NULL) > break; // redundancy -- already checking for this > condition in MyCallback > printf("infinite loop\n"); > sleep(1); > } > > err = snd_pcm_close(handle); > if(err<0) > printf("error in closing pcm device: %s\n",snd_strerror(err)); > > return 0; > } > > void MyCallback(snd_async_handler_t *pcm_callback) > { > > snd_pcm_t *pcm_handle = snd_async_handler_get_pcm(pcm_callback); > snd_pcm_sframes_t avail; > int count,a; > snd_pcm_uframes_t period_size = 64; > snd_pcm_sframes_t frames; > > if((avail=snd_pcm_avail_update(pcm_handle)) >= period_size) > { > printf("available frames = %d\n",avail); > frames = snd_pcm_writei(pcm_handle, rfrom, SIZE); > if(frames < 0) // underrun > { > printf("underrun recovery\n"); > frames = snd_pcm_prepare(pcm_handle); > printf("error from snd_pcm_prepare is: %d\n",frames); > if(frames < 0){ > printf("error in recovery\n"); > > } > } > > if(frames >0 && frames < SIZE) > printf("expected to write %d, wrote %d\n",SIZE,frames); > > > if(rfrom < &buffer[buflen-1]) > { > wto = rfrom; > rfrom = rfrom + SIZE; > } > if(rfrom >= &buffer[buflen-1]) > { > // wto = rfrom; > rfrom = &buffer[0]; > } //location of where to start writing > from next > > if(writetobuf()<0){ > wto=NULL; > exit(0); // returns 0 to the operating system -- so it > ends the program! > } > ++ind; > } > > printf("going out of callback, ind = %d\n",ind); > } > > /*Function to copy data from master buffer (mbuf) to circular buffer > (buffer)*/ > int writetobuf() > { > int count=-1; > > while((++count < SIZE) && (mpos < &mbuf[length])) > *(mpos++) = *(wto+count); > > if(mpos >= &mbuf[length-1]) > return -1; > else > return 0; > } >

2 2

[alsa-devel] CMI8788............
by Khalid Paden 29 May '07

29 May '07

Does anyone have a driver for the CMI8788 chipset? AKA The X-Meridian? -- Khalid Paden _______________________________________________________________________ So that's it?!?!?! Not quite. Right now he is taking the safety's off all his weapons. He won't make the same mistake twice. -Hunt for Red October

1 0

[alsa-devel] Reasonable sound hardware parameters?
by Lorenz Kolb 29 May '07

29 May '07

> Message: 4 > Date: Mon, 28 May 2007 10:52:18 +0200 (CEST) > From: Jaroslav Kysela <perex(a)suse.cz> > Subject: Re: [alsa-devel] Reasonable sound hardware parameters? > To: Joachim F?rster <mls.JOFT(a)gmx.de> > Cc: alsa-devel(a)alsa-project.org > Message-ID: <Pine.LNX.4.61.0705281045310.7894(a)tm8103.perex-int.cz> > Content-Type: text/plain; charset="iso8859-2" > > On Sat, 26 May 2007, Joachim F?rster wrote: > > > > > First question: To implement mmap on such kind of device IO memory, > > I have to use snd_pcm_lib_mmap_iomem() as mmap() callback - like it > > is used in the rme32 driver, right? > > Yes. rme32 is quite similar. > > > Second question: Do the following parameters make sense regarding > > the size of the HW ring buffer and period sizes: > > > > .buffer_bytes_max=16*1024; > > .period_bytes_max=8*1024; > > .period_bytes_min=?? resonable value ?? > > 32 or 64 > > > .periods_min=2; > > .periods_max=?? resonable value ?? > > 16 > > > Furthermore, the sound controller will fire an interrupt after one > > period is played. Are there any arguments against these values? Any > > comments? > > Yes, I think that the access through a PCI I/O window to a PCI device > is much slower than PCI DMA transfers with bursts. I would really > consider to design hardware with real DMA. Of course, if it's only > experimental stuff, then don't worry. > > Jaroslav > > ----- > Jaroslav Kysela <perex(a)suse.cz> > Linux Kernel Sound Maintainer > ALSA Project, SUSE Labs Hi Jaroslav, First of all: thanks for Your answer. Second: We do not have a PCI Bus. It is an embedded system with an OCP-Bus (aka OPB). The ML403 holds a SoC with PPC and FPGA. So the only difference between DMA with bursts and a dedicated memory (as far as we do see it) is the amount of time the bus gets occupied. With dedicated memory the system will (hopefully ;-)) do a burst write each period. So what happens in DMA case (except the more complex hardware as the DMA controller has to be written (in VHDL) as well and even more memory is located at an more complex bus (PLB - processor local bus): the bus will be occupied twice: (1) CPU writes data to memory. --> start DMA --> (2) Controller fetches data from memory. While (2) is in progress the poor CPU is "disconnected" from the bus. In an embedded system with a not too powerful CPU (PPC 405 @300MHz) this might be quite inefficient. Or did we miss something? Regards, Lorenz -- Lorenz Kolb <alsa-dev(a)lkmail.de> Embedded specialist ESIC-Solutions

2 4

[alsa-devel] SigmaTel STAC9221 - Mux Amp-Out > 0x02 == microphone not working
by Ivan N. Zlatev 29 May '07

29 May '07

Hello, I am on an iMac ("*imac-20" model/pinconfig) with a Intel HD card with the SigmaTel STAC9221 codec. I have attached the inital codec info after modprobe. I am using Alsa HG. Setting the mux gain to a value > 20 (0x02 Amp-Out value) results a non-working microphone. Steps and codec diffs as follows: 1) initial - microphone working 2) Mux Gain = 10 - microphone working Node 0x12 [Audio Selector] wcaps 0x30010d: Stereo Amp-Out Amp-Out caps: ofs=0x00, nsteps=0x04, stepsize=0x27, mute=0 - Amp-Out vals: [0x00 0x00] + Amp-Out vals: [0x01 0x01] Connection: 7 0x0e 0x15 0x0f 0x0b* 0x0c 0x0d 0x0a 3) Mux Gain = 20 - microphone working Node 0x12 [Audio Selector] wcaps 0x30010d: Stereo Amp-Out Amp-Out caps: ofs=0x00, nsteps=0x04, stepsize=0x27, mute=0 - Amp-Out vals: [0x01 0x01] + Amp-Out vals: [0x02 0x02] Connection: 7 0x0e 0x15 0x0f 0x0b* 0x0c 0x0d 0x0a 4) Mux Gain = 30 - microphone not working Node 0x12 [Audio Selector] wcaps 0x30010d: Stereo Amp-Out Amp-Out caps: ofs=0x00, nsteps=0x04, stepsize=0x27, mute=0 - Amp-Out vals: [0x02 0x02] + Amp-Out vals: [0x03 0x03] Connection: 7 0x0e 0x15 0x0f 0x0b* 0x0c 0x0d 0x0a 4) Mux Gain = 40 - microphone not working Node 0x12 [Audio Selector] wcaps 0x30010d: Stereo Amp-Out Amp-Out caps: ofs=0x00, nsteps=0x04, stepsize=0x27, mute=0 - Amp-Out vals: [0x03 0x03] + Amp-Out vals: [0x04 0x04] Connection: 7 0x0e 0x15 0x0f 0x0b* 0x0c 0x0d 0x0a Regards -- Ivan N. Zlatev Web: http://www.i-nZ.net "It's all some kind of whacked out conspiracy."

2 6

[alsa-devel] Intel HD SigmaTel STAC9221 - Wrong input after output change
by Ivan N. Zlatev 29 May '07

29 May '07

Hello, I am on an iMac ("*imac-20" model/pinconfig) with a Intel HD card with the SigmaTel STAC9221 codec. I have attached the inital codec info after modprobe. When I plug in and then unplug my speakers the microphone stops working. Reproduction steps with codec dump diffs as follows 1) Initial codec info - attached - Microphone working 2) Plug in speakers - Microphone working Node 0x0c [Pin Complex] wcaps 0x400181: Stereo Pincap 0x081737: IN OUT Detect Pin Default 0x9017e110: [Fixed] Speaker at Int N/A Conn = Analog, Color = White - Pin-ctls: 0x00: + Pin-ctls: 0x40: OUT Connection: 1 0x03 3) Unplug speakers - Microphone not working Node 0x0b [Pin Complex] wcaps 0x400181: Stereo Pincap 0x081737: IN OUT Detect Pin Default 0x90a7012e: [Fixed] Mic at Int N/A Conn = Analog, Color = Unknown - Pin-ctls: 0x44: OUT + Pin-ctls: 0x04: Connection: 1 0x04 Node 0x0c [Pin Complex] wcaps 0x400181: Stereo Pincap 0x081737: IN OUT Detect Pin Default 0x9017e110: [Fixed] Speaker at Int N/A Conn = Analog, Color = White - Pin-ctls: 0x40: OUT + Pin-ctls: 0x00: Connection: 1 0x03 Node 0x0f [Pin Complex] wcaps 0x400181: Stereo Pincap 0x0837: IN OUT Detect Pin Default 0x0181e020: [Jack] Line In at Ext Rear Conn = 1/8, Color = White - Pin-ctls: 0x40: OUT + Pin-ctls: 0x00: Connection: 1 0x05 4) Plug in speakers again - Microphone not working Node 0x0b [Pin Complex] wcaps 0x400181: Stereo Pincap 0x081737: IN OUT Detect Pin Default 0x90a7012e: [Fixed] Mic at Int N/A Conn = Analog, Color = Unknown - Pin-ctls: 0x04: + Pin-ctls: 0x44: OUT Connection: 1 0x04 Node 0x0c [Pin Complex] wcaps 0x400181: Stereo Pincap 0x081737: IN OUT Detect Pin Default 0x9017e110: [Fixed] Speaker at Int N/A Conn = Analog, Color = White - Pin-ctls: 0x00: + Pin-ctls: 0x40: OUT Connection: 1 0x03 Node 0x0f [Pin Complex] wcaps 0x400181: Stereo Pincap 0x0837: IN OUT Detect Pin Default 0x0181e020: [Jack] Line In at Ext Rear Conn = 1/8, Color = White - Pin-ctls: 0x00: + Pin-ctls: 0x40: OUT Connection: 1 0x05 -- Ivan N. Zlatev Web: http://www.i-nZ.net "It's all some kind of whacked out conspiracy."

2 4