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

[alsa-devel] HDA Codec: Add support for MSI K9N Ultra
by Tobin Davis 29 May '07

29 May '07

This patch adds the MSI K9N Ultra system to the realtek patch. Signed off by Tobin Davis <tdavis(a)dsl-only.net>

2 1

[alsa-devel] ICE1724 alsa driver
by Rossco 29 May '07

29 May '07

Hi, I hope someone can help me. (tried the user list but no response) I have a hitpoint 7.1ch Envy24ht-s based card with the usual vt1616 multichannel codec and the wolfson WM8728. The card is recognised as a chaintech av710 with the only difference being that the card has spdif in as well as out. It appears to be physically similar to the maddog entertainer (would be good to know if this is also recognised as an AV710) By default 2 channel stereo in played through the "front" channel of the card through the vt1616 codec and I appear to be able to set spdif out through the mixer (but dont have another device to test at the moment). I have been able to change default output to go through the wolfson dac through an asound.state file posted on the web. I have to admit I do not quite understand what the file has done as it only appears to have removed some of the controls rather than change or add anything. Only two devices are detected for the card the vt1616 and IEC958, neither are shown as having any subdevices, therefore I am unsure how the asound.state file was able to address the wolfson chip which requires i2s input rather ac-link. This seems to indicate i2s and ac-link modes of the envy24ht-s chip are active. Most AV710 users seem happy enough to be able to route to toslink out and/or the higher quality wolfson chip, therefore there is little discussion of addressing the other channels of the card. I really want to be able to address each of the channels of the card so that I can use the convolution programme Brutefir with the card to create a multiway crossover for my loudspeakers. Is there anyway I can define each of the cards outputs so that I can select to send audio to any one of them? I am also keen to get the spdif in working and particularly the syncing to spdif in of the clock that the ice1724 chip supports. Can these features be added to the driver? Please advise of any required info, I have all the datasheets and can trace chip pins also. Thanks in advance. Ross

2 5

[alsa-devel] [PATCH] Add quirk for Supermicro PDSBA to alc883_cfg_tbl[]
by Daniel T. Chen 29 May '07

29 May '07

Attached is a diff against current alsa-kernel hg tip. Thanks, Daniel Chen

1 1

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

29 May '07

Hi, In my asynchronous playback program, the hardware stops asking for any data and the program gets stuck after one call to the callback function. I have pasted the program below -- please let me know if something is wrong - Thanks, 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 > > short int *buffer; > int ind=10, fd1; > 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,length,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); > > buflen = 4*SIZE; > buffer = (short int *) malloc (buflen*sizeof(short int)); > > wto = NULL; > rfrom = &buffer[0]; > > count=0; > a=1; > while(count<buflen && a>0) > a=read(fd1,&buffer[count++],sizeof(short int)); > if(a<0) > printf("error in reading from wav file\n"); > > 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; > } > else > { > printf("rfm at the end, rfrom -buffer[buflen-1] > =%d\n",(*rfrom - buffer[buflen-1])); > wto = rfrom; > rfrom = &buffer[0]; > } > for(k=0; k<SIZE; k++) > { > a=read(fd1,(wto+k),sizeof(short int)); > if(a<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,buffer); > 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; > sleep(1); > } > > err = snd_pcm_close(handle); > if(err<0) > printf("error in closing pcm device: %s\n",snd_strerror(err)); > close(fd1); > 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; > //short int *bufferin = > snd_async_handler_get_callback_private(pcm_callback); > > while((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"); > // break; > } > } > > if(frames >0 && frames < SIZE) > printf("expected to write %d, wrote %d\n",SIZE,frames); > count = 0; > a=1; > while(count<SIZE && a>0){ > a=read(fd1,(wto+count),sizeof(short int)); //write to > the buffer from file > ++count; > } > printf("count = %d\n",count); > if(a <0){ //EOF > wto = NULL; > printf("end of file reached\n"); > break; > } > else{ > if(rfrom < &buffer[buflen-1]) > { > wto = wto+count; > rfrom = rfrom + SIZE; > } > else > { > wto = wto + count; > rfrom = &buffer[0]; > } //location of where to start > writing from next > } > ++ind; > } > > printf("going out of callback, ind = %d\n",ind); > } > > >

2 1

[alsa-devel] async playback works despite error in snd_pcm_start.
by Ashlesha Shintre 28 May '07

28 May '07

Hi, I managed to write code to playback sound asynchronously -- however, this code works (i.e data is read from .wav file and output to the playback device) despite the snd_pcm_start giving a "file descriptor in bad state" error.. can someone explain this please? Thanks, Ashlesha.

1 0

Re: [alsa-devel] another ALSA question
by Jaroslav Kysela 28 May '07

28 May '07

I'm CCing alsa-devel because this discussion might be interesting for other developers, too. On Mon, 28 May 2007, Maarten Lankhorst wrote: > Jaroslav Kysela schreef: > > On Mon, 28 May 2007, Maarten Lankhorst wrote: > > > >> After playing around a little more with alsa I tried to do manipulation > >> of pointer using the instructions, I wrote some simple code either does > >> rewind or forward to get to the right point, taking in respect the > >> amount of delay and where to go. > >> > >> However it doesn't seem to work: Looking at the source code it seems > >> rewinding isn't implemented, using the #if 0'd code there gives problems > >> when doing snd_pcm_forward later: It then ends up at the pointer where > >> the sound is currently being played at. > >> > > > > Not all alsa-lib plugins are capable or have implemented this fine > > position control (check error value). > > > For a plugin like dmix, I would expect it to be implemented, especially > since most cards sold are integrated cards that don't have multiple > sound buffers. Go ahead and send us patches. We're doing open source :-) Anyway any rewind operation mens "undo" - it will eat extra CPU ticks for nothing. > >> As workaround I used the following in my own code: > >> typeof(snd_pcm_forward) snd_pcm_mmap_appl_forward; > >> #define snd_pcm_forward snd_pcm_mmap_appl_forward > >> > >> typeof(snd_pcm_rewind) snd_pcm_mmap_appl_backward; > >> #define snd_pcm_rewind snd_pcm_mmap_appl_backward > >> > >> This works, but I wonder if there is a cleaner way to do it. > >> > > > > It won't work with all plugins and mentioned functions are not part of > > public API. > > > As I work in wine on it's DirectSound implementation, I can tell it > relies heavily on the fact that it can lock a buffer at an arbitrary > position, and that it works with absolute pointers, rather then > relative. So if snd_pcm_rewind/snd_pcm_forward don't work as expected, > an alsa driver for it would become nearly useless, I don't expect it to > always work, but I would expect it to work for a common plugin like dmix > at least. > >> Also, I noticed some audio glitches when using this in combination with > >> alsa-lib's resampling, is that because of the way it is done or is > >> something else wrong? > >> > > > > You should not use mentioned functions. > > > > You can try to use the direct hardware access (hw:CARD_NAME) devices > > (you'll lose all stream conversions from the ALSA side) or use an > > intermediate buffer for fine position control and configure ALSA to use > > smallest ring buffer as possible (to minimalize latency). > > > > Jarosla > I wish that would work, directsound expects to have access to a fixed > size buffer, and if I go for direct hardware access, I lose the ability > to work properly with most cheap cards on the market, since people want > to be able to listen to music on background while gaming. For now it > seems I have to use the internal calls in case of dmix, or modify > already committed data, which is what winealsa's current driver does. I > don't know what is the least of those 2 evils, or if there is a third > option. I'm open for advice. I'm afraid, that you're trying to exactly copy DirectSound API. Playing with the buffer position in this way is always dangerous, because it's really hard to predict the final result in the multitasking environment. Think about these proposals: 1) what sample (ring buffer) rewritting is supposed to do - maybe you can change only not yet commited samples with satisfactory results 2) use a small ALSA ring buffer and use own "big" ring buffer for changes before you commit samples to ALSA's ring buffer - you'll increase a bit sample flow latency, but you can do anything you want (you just add extra buffering to avoid rewind / forward for ALSA API) 3) fix (or better implement) dmix plugin rewind function Jaroslav ----- Jaroslav Kysela <perex(a)suse.cz> Linux Kernel Sound Maintainer ALSA Project, SUSE Labs

1 0

[alsa-devel] [ALSA] ALSA Power Management, Drivers behaving unexpectedly after suspend/resume cycle
by Nobin Mathew 28 May '07

28 May '07

I am implementing power management in my ALSA sound drivers. ALSA drivers are not working properly after resume. All registers values are proper and I am able to read back the codec register contents. If I do a playback after resume then I am getting lots of "underrun". After a reboot playback is working fine. Is there any known issues with ALSA power management? Why Ubuntu and Redhat does ALSA modules removal before suspend and insertion after resume?

3 10

[alsa-devel] Reasonable sound hardware parameters?
by Joachim Förster 28 May '07

28 May '07

Hi ALSA devs, as I already described in one of my last posts on the list, I'm going to write a ALSA driver for a sound controller which will also be "written" at the same time (VHDL for FPGA) - on top of an embedded system (Xilinx ML403 EvalBoard, PowerPC 405). We will do playback feature only. The point is, that we will have _no_ real DMA and we don't want to use the copy/silence or ack/workqueue (with intermediate buffer). So we decided to move the ring buffer, which usually exists in RAM into the sound controller and handle it as some kind of device IO memory, which should be mmap'able (kernel function io_remap_pfn_range()). So, the important goal is, to have mmap feature in the ALSA driver. 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? 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 ?? .periods_min=2; .periods_max=?? resonable value ?? Furthermore, the sound controller will fire an interrupt after one period is played. Are there any arguments against these values? Any comments? Thanks, Joachim

2 1

[alsa-devel] alsa playback channel interleaving question
by Matthias Nyffenegger 27 May '07

27 May '07

Hi, Earlier this year I wrote to this list: > I am trying to write an alsa driver for my audiowerk8 soundcard. > The aw8 uses a Philips saa7146 chipset. There are 2 capture and > 8 playback channels mapped on the saa7146's DMA as follows: > > DMA1: 2xcapture > DMA2: 4xplayback > DMA3: 4xplayback > > Sample format is 16bit. > > Frame format is as follows: > (A number corresponds to a channel, a stereo channel-pair is embraced > by [] and 1 digit corresponds to one sample byte) > > capture channels [0,1] on DMA1: 00--11-- > playback channels [2,3],[4,5] on DMA2: 22443355 > playback channels [6,7],[8,9] on DMA3: 66887799 I tried to find a way to handle this in the card, but this special interleaving for the playback channels is by hardware restriction and can't be worked around in the soundcard itself. AFAIK alsa provides the samples interleaved like 22334455 (66778899). To avoid channel switching I guess some special processing in the alsa driver is required. Where is this done best? Do I have to move around the samples in the interrupt handler or does alsa provide some (possibly better) means to achive the correct (for the soundcard) interleaving? Regards, Matthias

1 0

[alsa-devel] Suggestion for getting alsa to use Conexant
by Victor Schneider 26 May '07

26 May '07

How about being able to parameterize Alsa modules so that the intel 80xm module finds any hda modem that also acts as an Intel hda chip? I am referring to the Conexant combination modem and hda chip that gets identified as "Conexant Waikiki" by alsamixer, but that 80xm can't find as a modem. Giving the 80xm module the device:identifier value to override its detection of the Intel version of the Conexant hda modem might let slmodemd work.

3 5