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

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

[alsa-devel] Question on snd_soc_dai_link
by Timur Tabi 29 May '07

29 May '07

I have a question about these DAI structs for ASoC. Let's take eti_b1_wm8731.c as an example. It contains this structure: static struct snd_soc_dai_link eti_b1_dai = { .name = "WM8731", .stream_name = "WM8731", .cpu_dai = &at91_i2s_dai[1], .codec_dai = &wm8731_dai, .init = eti_b1_wm8731_init, .ops = &eti_b1_ops, }; Notice that the .cpu_dai field is hard-coded to use the 2nd I2S device on the AT91. The problem I'm having with this approach is that everything is hard-coded. On PowerPC, this approach doesn't work well, because we have a "device tree" that dictates what devices are present on the SOC. For a Freescale SOC that has two I2S devices (for example), both devices would be listed in the device tree, with the base address of the memory-mapped registers. This means that a Freescale I2S driver would have its 'probe' function called (much like PCI does) each time the kernel processes an I2S node in the device tree. This means that when the machine driver (which has the snd_soc_dai_link structure) loads, there's no guarantee that the I2S driver has also loaded and the probe functions have been called. It gets even more complicated if only one I2S device has a codec connected to it, because then I need to kmalloc the snd_soc_cpu_dai structures and somehow tell the snd_soc_dai_link structure which one to use. Has any thought been given to making these structures more dynamic and handling interdependencies among the drivers? As it stands now, it looks like I'm going to have to hard-code everything in the drivers and break the device tree paradigm. -- Timur Tabi Linux Kernel Developer @ Freescale

2 5

[alsa-devel] [PATCH] Sigmatel STAC9221 - Add Configs for all Apple Intel Macs
by Ivan N. Zlatev 29 May '07

29 May '07

This patch: * adds the pinconfigs for all 5 Apple boards and 14 Subsystem IDs (support for possibly all iMac, Mac, MacMini etc etc) * adds "intel-mac-v1" to v5 models which replace the current * reflects changes in Alsa-Configuration.txt Please review. Regards. -- Ivan N. Zlatev Web: http://www.i-nZ.net "It's all some kind of whacked out conspiracy."

2 5

Re: [alsa-devel] [PATCH] Disable debugging output for the ALS300 driver
by Ash Willis 29 May '07

29 May '07

> ----- Original Message ----- > From: "Takashi Iwai" <tiwai(a)suse.de> > To: "Ash Willis" <ashwillis(a)programmer.net> > Subject: Re: [alsa-devel] [PATCH] Disable debugging output for the ALS300 driver > Date: Tue, 29 May 2007 15:08:30 +0200 > > > At Sat, 26 May 2007 13:26:35 +0000, > Ash Willis wrote: > > > > Disables debugging output in the ALS300 driver. > > Also contains a whitespace cleanup and a fix for a potential bug. > > > > Signed-off-by: Ash Willis <ashwillis(a)programmer.net> > > Thanks for the patch. It seems that your MUA breaks the embedded > patch, so I had to apply it manually. Could you check whether the > latest HG is OK for you? I'm away from home right now. I'll test it as soon as I have a chance but it looks fine. > > Also I changed "if ((err = ...))" to two individual lines, which is a > newer standard kernel coding style. > Yeah, I left that for now. I'll go through the tree and tidy up remaining occurences of this style when I have some time. It seems that when people add drivers to the tree, they generally copy already existing drivers. It doesn't make much sense to be copying code that doesn't fit CodingStyle. Ash = Sports Memorabilia License Plates Signs All license plates $6 all signs $10 all frames $8 - same day shipping - fun company and selection. http://a8-asy.a8ww.net/a8-ads/adftrclick?redirectid=a44f49e42c5a283d05f0c96…

2 1

[alsa-devel] [PATCH] Disable debugging output for the ALS300 driver
by Ash Willis 29 May '07

29 May '07

Disables debugging output in the ALS300 driver. Also contains a whitespace cleanup and a fix for a potential bug. Signed-off-by: Ash Willis <ashwillis(a)programmer.net> ---------------------------------------------------- diff -r 337962e19de6 -r 8ea4fa014563 pci/als300.c --- a/pci/als300.c Fri May 25 12:18:49 2007 +0200 +++ b/pci/als300.c Sat May 26 14:04:14 2007 +0000 @@ -88,8 +88,8 @@ #define PLAYBACK_BLOCK_COUNTER 0x9A #define RECORD_BLOCK_COUNTER 0x9B -#define DEBUG_CALLS 1 -#define DEBUG_PLAY_REC 1 +#define DEBUG_CALLS 0 +#define DEBUG_PLAY_REC 0 #if DEBUG_CALLS #define snd_als300_dbgcalls(format, args...) printk(format, ##args) @@ -730,10 +730,9 @@ static int __devinit snd_als300_create(s } chip->irq = pci->irq; - snd_als300_init(chip); - if (snd_als300_ac97(chip) < 0) { + if ((err = snd_als300_ac97(chip)) < 0) { snd_printk(KERN_WARNING "Could not create ac97\n"); snd_als300_free(chip); return err;

2 1

[alsa-devel] sound on smdk2410
by Jose Henrique Spahn Torres 29 May '07

29 May '07

Hi, I am trying recent Zoltan Devai's patchs for kernel 2.6.22-rc2 on a smdk2410 board. I reached the point where the kernel recognized the uda1341 sound chip, however, when I try to play something, I get the output below. Can anyone, please, show me the path to follow to get sound working? Thanks, Henrique /home $ l drwxr-xr-x 3 root root 0 Jan 1 00:00 . drwxr-xr-x 18 root root 1024 May 18 2007 .. -r--r--r-- 1 root root 3419671 Jan 1 1970 jj.mp3 /home $ mpg123 jj.mp3 High Performance MPEG 1.0/2.0/2.5 Audio Player for Layers 1, 2 anasoc: UDA1341 <-> s3c24xx-i2s info: asoc: rate mask 0xfe asoc: min ch 2 max ch 2 asoc: min rate 8000 max rate 48000 version 0.65; written and copyright by Michael Hipp and others free software (LGPL/GPL) without any warranty but with best wishes asoc: machine hw_params failed ... (lots of asoc: messages) ... asoc: machine hw_params failed pop wq checking: Playback status: inactive waiting: yes pop wq D3 UDA1341 Playback Playing MPEG stream 1 of 1: jj.mp3 ... Title: Times Like These Artist: Jack Johnson Comment: Album: On And On Year: 2003 Genre: Acoustic MPEG 1.0 layer III, 192 kbits/s, 44100 Hz stereo [audio.c:264] error: No supported rate found! /home $

3 3