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

[alsa-devel] [ASoc] TDM over one SSC channel on AT91 possible?
by Friedrich Lobenstock 24 Jun '11

24 Jun '11

Hello! The background: I'm just designing an ATMEL AT91RM9200 based board which got two TLV320AIC33 on board. It is either possible to hook up the two TLV320AIC33 to a separate SSC (synchronous serial control) channel each or use one SSC channel and configure it for TDM (time division multiplex) mode. There is already a driver for TLV320AIC14k/TLV320AIC2k in the development tree, so adding support for the TLV320AIC33 should be feasible. What I'm not sure about is the fact if ASOC is prepared for using channels, especially SSC, in TDM mode. Is the core ASOC structure prepared to handle that? Would we be better off instantiate one drive twice each time with different parameters for the SSC channel? Thanks for any feedback. -- MfG / Regards Friedrich Lobenstock _________________________________________________________ SCOTTY Group Austria GmbH a SCOTTY Group plc company, http://www.scottygroup.com/ _________________________________________________________

4 3

Re: [alsa-devel] Patchmix-style application for EMU cards
by Camilo Polymeris 30 Aug '10

30 Aug '10

Hello > That is more or less what I had figured out, but it how are playback_1 to > > _16 channels routed to DSP0-15? It seems that it depends on the setting > of > > Front, Surround, LFE, etc. mixer controls. If they are turned up, I > don't > > understand what happens, sound to playback channels appears on various > DSP > > buses, at different levels. > > Really? Well, I didn't much experiment with surround mode. In source code, > I > can see that there are up to playback 8 channels at hw:0,0 with can be > controlled by faders in alsamixer. I tried surround40 and surroun51 on my > emu1616m and it worked as expected. The channles were mapped to first > couple > of DSP ports in a correct order. In fact this should work the same as > audigy > does, except the result is passed to DSP ports instead of physical > outputs. > On my card, playback channels 1 & 2 (hw:0,3) appear on all DSP busses associated with surround. Say you turn up the "Side" fader in alsamixer, channels 1 & 2 will appear at the relevant DSPs (6-7, I think) Whatever, for now I am just keeping all surround controls down (that is, Front, Surround, Center, Side & LFE). > Anyway, I think if there is another layer of routing done in audigy DSP, > it > shouldn't be used in EMU specific application. Or at least not for now. > The > most important thing is to provide all the switches and FPGA routing > scheme > for each EMU model. Or, to be precise, three routing schemes for each EMU > model, because for "double speed" (e.g. 96kHz) and "quadro speed" (e.g. > 192kHz) modes of operation the numebr of both physical and virtual > channels > changes. > I think the switches and enums for the card models are rather trivial, one can handle it with a customized version of qamix (done with a simple XML file), for example. A separate application would not be necessary for only that. > > If I turn the Front/Surround/LFE/etc. faders down, I can mix playback > > channels to DSP using the "Multichannel PCM Send/Routing/Volume" faders, > in > > a more or less intuitive way, besides that routing values do not map > > directly to DSP buses (i.e. 14-15 map to DSP0-1, but 2-3 map to DSP2-3). > Handling of this controls motivated me to write the application in the first place. No sound at all will appear if I don't set the appropiate controls for each playback channel: Multichannel PCM Volume (full), Multichannel PCM Send (an index of 8 controls, the first 4 select the target DSP) & Multichannel PCM Send Volume (again faders 0-3 of 8) By the way, only DSP0-7 work in this way. I have no idea how to make DSP8-31 work. On which card you did tested it? The driver was primary written for the > 1820M/1212M V1, so some things may not work well on other models and need > to > be fixed. I have a 1212m, don't know which version, but I think it's V1-- it does have firewire. I am using driver version 1.0.16. Thanks, Camilo.

3 3

[alsa-devel] snd_pcm_set_params() bug?
by Christian Morales Vega 26 Jan '09

26 Jan '09

This code: #include <alsa/asoundlib.h> int main(){ snd_pcm_t *handle; if(snd_pcm_open(&handle, "default:1", SND_PCM_STREAM_PLAYBACK, 0) < 0) { exit(1); } if(snd_pcm_set_params(handle, SND_PCM_FORMAT_S16_LE, SND_PCM_ACCESS_RW_INTERLEAVED, 2, 24000, 1, 100000) < 0) { exit(2); } } fails with error "ALSA lib pcm.c:7193:(snd_pcm_set_params) Unable to get period size for PLAYBACK: Invalid argument" Disable resampling and you get "ALSA lib pcm.c:7142:(snd_pcm_set_params) Rate doesn't match (requested 24000Hz, get 0Hz)" (normal, I suppose). With other samplerates works fine. I'm using alsa-driver-kmp-default-1.0.16.20080602 and alsa-1.0.16.hg20080510 RPM packages from multimedia:audio openSUSE Build Service repository (from Takashi Iwai) and an AD1988 (hda-intel) codec. A XUbuntu user also has the same problem with an hda-intel codec (that I suppose uses stable 1.0.16). With a SB Live! in the same computer there are no problems. This was discovered with bsnes ( http://byuu.cinnamonpirate.com/bsnes/ - http://board.zsnes.com/phpBB2/viewtopic.php?t=11584 ) that can use openal, libao or alsa directly. The problem just happens when using 24KHz with alsa. So I suppose the problem is in the snd_pcm_set_params() itself, since openal and libao have not the problem but they set parameters "manually", not with snd_pcm_set_params().

3 2

[alsa-devel] snd_pcm_avail_update() needed before snd_pcm_delay() with hda-intel
by Christian Morales Vega 24 Jan '09

24 Jan '09

snd_pcm_avail_update() documentation says: "Using of this function is useless for the standard read/write operations. Use it only for mmap access. See to snd_pcm_delay." snd_pcm_delay() documentation says: "Note this function does not update the actual r/w pointer for applications. The function snd_pcm_avail_update() have to be called before any begin+commit operation." My english is far from perfect, and so the problem can be that I missunderstood the docs but: 1- "Using of this function"? Should not be "Use of this function"? 2- Is snd_pcm_avail_update() really useless when not using mmap? I have a SB Live! where snd_pcm_delay() always returns the correct value, without any need for snd_pcm_avail_update(). But the same code in the same machine with an hda-intel AD1988 needs a call to snd_pcm_avail_update() before snd_pcm_delay() to give the correct result. Without it snd_pcm_delay() always returns the value that *was* correct in the last snd_pcm_writei() call. So should the "application frame position" be always updated, or only in read/write operations? In the first case AD1988 fails, in the second case perhaps SB Live! is making too mucho work ;-)

4 9

[alsa-devel] snd_pcsp locking mess
by Stas Sergeev 21 Oct '08

21 Oct '08

bugme-daemon(a)bugzilla.kernel.org wrote: > ------- Comment #17 from tiwai(a)suse.de 2008-05-18 10:22 ------- > Anyway, what I meant is that the part touching I/O ports could be a faster path > than softirq. And the hrtimer code can use a bit simpler locks. The hrtimer > callback needs just one thing about DMA buffer - the buffer is allocated and > the address doesn't change during the callback. So, we'd need the lock for the > hr callback and for the PCM prepare, hwparams and free callbacks, i.e. to > assure that the hrtimer callback is finished when these PCM callbacks may > change the DMA buffer. Thus this lock doesn't have to be PCM substream lock. I wonder if it would be better to introduce such a lock in an alsa core rather than in a driver. The same way as snd_pcm_stream_lock(). > The current lock mess may come from the PCM trigger (STOP) called from > snd_pcm_period_elapsed(). So, putting snd_pcm_period_elapsed() out of hrtimer > lock is anyway necessary. A tasklet for snd_pcm_period_elapsed() is needed for > this reason, too. Wouldn't it be better to just make snd_pcm_period_elapsed() to not take the stream lock? There is a requirement right now to drop the stream lock before calling this. I still beleive this is the root of all the headache. If you need to drop it, then you either accept the race or need a second lock, and the troubles ensue.

2 22

[alsa-devel] X-Fi support in ALSA.
by James Courtier-Dutton 18 Sep '08

18 Sep '08

Hi, I have now had a chance to read some of the specs of the X-Fi cards. aka. emu20k1. It turns out that some of the X-Fi cards have a compatibility mode. By default, they boot up in compatibility mode. The interesting point is that this "compatibility mode" is in fact the intel-HD standard so could use the intel-hda driver. For one X-Fi card with IDs: Device 1102:0009 Subsystem: 1102:0010 works a bit with the ALSA hda-intel driver. So far, the off the shelf hda-intel driver, with simple PCIs adjustment, works for the above card, but only sound capture works so far, so probably some quirk would be needed. This compatibility mode works with the Windows Vista UAA drivers. Not all X-Fi cards support with compatibility mode. For example, any card with (after a cold boot into Linux) Device 1102:0005 Subsystem: xxxx:xxxx will be X-Fi only. With regard to actual full X-Fi support, I am still in the progress of creating a GPL emu20k1.h file, that is the first step towards an snd-emu20k1 native ALSA driver. James

3 3

Re: [alsa-devel] [Fwd: [Alsa-user] Intel Poulsbo(SCH) chipset does not recognize Adi 1986 codec under linux]]
by Kan-I Jyo 01 Aug '08

01 Aug '08

Dear list, My original mail on this topic was posted to the alsa-user list, while I was informed that this alsa-devel list would be the right place to post. The problem I had encountered is that the Adi 1986 codec chip on my device with Poulsbo(SCH) chipset could not be recognized by the snd_hda_intel driver module. Tobin has kindly given me an advice on trying an ALSA driver that is later than 1.0.16.final. For a cross-test pupose, I have tried both the following 1.0.16 and the latest 1.0.17-rc2. [1.0.16] ftp://ftp.alsa-project.org/pub/driver/alsa-driver-1.0.16.tar.bz2 [1.0.17-rc2] ftp://ftp.alsa-project.org/pub/driver/alsa-driver-1.0.17rc2.tar.bz2 By following the guide described in the INSTALL text file in both the above two packages, I have done make and make install without a problem. Unfortunately, both these two version of ALSA driver does not recognized the Adi 1986 codec and in the dmesg output claiming that "no codecs found!". <dmesg> -- snip -- ACPI: PCI Interrupt 0000:00:1b.0[A] -> GSI 16 (level, low) -> IRQ 17 PCI: Setting latency timer of device 0000:00:1b.0 to 64 ALSA /root/alsa-driver-1.0.16/pci/hda/../../alsa-kernel/pci/hda/hda_intel.c:1887: hda-intel: no codecs found! ACPI: PCI interrupt for device 0000:00:1b.0 disabled ACPI: PCI Interrupt 0000:00:1b.0[A] -> GSI 16 (level, low) -> IRQ 17 PCI: Setting latency timer of device 0000:00:1b.0 to 64 ALSA /root/alsa-driver-1.0.17rc2/pci/hda/../../alsa-kernel/pci/hda/hda_intel.c:2142: hda-intel: no codecs found! ACPI: PCI interrupt for device 0000:00:1b.0 disabled -- snip -- I have also tried applying some module parameters like probe_mask and position_fix but with no luck. Actually, we have two machines with Poulsbo(SCH) chipset inside. The ALSA driver works fine in one(with a chipset's revision of "04") while it does not work on the other (with a chipset's revision of "06"). Here I attach the "lspci -nnvvvxxxx" result from both two machines. Any comment would be greatly appericiated. If anyone needs more information, please let me know. ---------- Forwarded message ---------- 2008/6/24 stan <ghjeold_i_mwee(a)cox.net>: > This is a response from the alsa-devel list. I forwarded your message there > as that was the more appropriate list. > > > Not sure what version of alsa driver you are using, but the driver for that > chipset was added prior to 1.0.16 final. Anything after that should work. > > Tobin > > On Mon, 2008-06-23 at 06:20 -0700, stan wrote: > > Sent to wrong list. > > email message attachment ([Alsa-user] Intel Poulsbo(SCH) chipset does not > recognize Adi 1986 codec under linux.eml) > > -------- Forwarded Message -------- > From: Kan-I Jyo <cecilhsujp(a)gmail.com> > To: alsa-user(a)lists.sourceforge.net > Subject: [Alsa-user] Intel Poulsbo(SCH) chipset does not recognize Adi 1986 > codec under linux > Date: Mon, 23 Jun 2008 20:53:42 +0900 > > Dear list, > > I have recently got a device with Intel's Poulsbo chipset and Adi 1986 > codec attatched. > > The Adi 1986 codec along with the Poulsbo chipset could been > recognized by installing the SoundMAX driver under Windows XP. > > While switching to Linux, the snd_intel_hda is loaded but the Adi 1986 > codec could not been seen and there is no "codec#0" entry under > /proc/asound/card0. > > >From what I can see from dmesg, the hda_intel module had complained > about "no codecs found!". > > <dmesg.txt> > -- snip -- > [ 93.463277] PCI: Setting latency timer of device 0000:00:1b.0 to 64 > [ 93.463286] Do fixup for Poulsbo <6>D0 or newer stepping > [ 93.463439] HDA snoop disabled, try to enable ... OK > [ 93.491624] hda-intel: no codecs found! > -- snip -- > > I have attached both output of dmesg command the "lspci -nnvvvxxx" > result along with this mail. Any comment would be greatly appreciated. > > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php > _______________________________________________ Alsa-user mailing list > Alsa-user(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/alsa-user > > _______________________________________________ Alsa-devel mailing list > Alsa-devel(a)alsa-project.org > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel > > -- Tobin Davis > > 22. The only copy of Norton Utilities was on THAT disk??? > > --Top 100 things you don't want the sysadmin to say > > -- Sincerely, Jyo

3 11

[alsa-devel] Requiring the same sample rate for playback and record?
by Timur Tabi 25 Jul '08

25 Jul '08

In my driver, how do I tell ALSA that the sample rate for playback must be the same as for capture? I know I can have my driver remember the sample rate for the first stream open, and then if the second stream doesn't specify the same sample rate, it can reject it, but this is inelegant. I'm hoping there's a more straightforward way. -- Timur Tabi Linux kernel developer at Freescale

3 11

[alsa-devel] Setting format to SND_PCM_FORMAT_MU_LAW does not let me apply hardware parameters
by Mitul Sen (misen) 24 Jul '08

24 Jul '08

I am a newbie to ALSA and any help will be much appreciated. I have an application which sets up the signaling between an IP phone and my desktop and then sets up the audio path between the two. On my desktop application, I am able to receive RTP packets from IP phone. I use an RTP stack to parse the data and after going through the RTP stack, I try to play back the audio using ALSA. When I use the ALSA code to play back (in real time) using sound card of my device, there is only noise, I cannot hear the audio that I speak into the IP phone. However, if I take the raw data coming from the RTP stack and write it to a file, I can play back the file successfully. Since my data from IP phone is G.711 encoded, I have set the sampling rate within ALSA to 8000. Also I am using one source (mono) and non-interleaved data option for preparing ALSA for playback. When I set the format to SND_PCM_FORMAT_MU_LAW, at runtime it lets me set that format ie. snd_pcm_hw_params_set_format (for SND_PCM_FORMAT_MU_LAW) is successful. However I get a runtime error while applying the hardware parameters using snd_pcm_hw_params(..) if the format set earlier is SND_PCM_FORMAT_MU_LAW. Using any other format like SND_PCM_FORMAT_U8 or SND_PCM_FORMAT_S8, lets me apply the hardware parameters but it gives the problem of the noise (no "audible" voice) that I described earlier. This is what my ALSA code looks like ***** beginning of code snippet ***************** int err; snd_pcm_hw_params_t *hw_params; // Try to open the default device err = snd_pcm_open( &_soundDevice, "plughw:0,0", SND_PCM_STREAM_PLAYBACK, 0 ); // Check for error on open. if( err < 0 ) { printf("Init: cannot open audio device\n"); return -1; } // Allocate the hardware parameter structure. if ((err = snd_pcm_hw_params_malloc (&hw_params)) < 0) { printf("Init: cannot allocate hardware parameter structure\n"); return -1; } if ((err = snd_pcm_hw_params_any (_soundDevice, hw_params)) < 0) { printf("Init: cannot initialize hardware parameter structure\n"); return -1; } // Set access to RW interleaved. if ((err = snd_pcm_hw_params_set_access (_soundDevice, hw_params, SND_PCM_ACCESS_RW_NONINTERLEAVED)) < 0) { printf("Init: cannot set access type\n"); return -1; } if ((err = snd_pcm_hw_params_set_format (_soundDevice, hw_params, SND_PCM_FORMAT_MU_LAW)) < 0) { return -1; } // Set channels to mono (1) if ((err = snd_pcm_hw_params_set_channels (_soundDevice, hw_params, 1)) < 0) { return -1; } // Set sample rate. unsigned int actualRate = 8000; if ((err = snd_pcm_hw_params_set_rate_near (_soundDevice, hw_params, &actualRate, 0)) < 0) { return -1; } // Apply the hardware parameters that we've set. if ((err = snd_pcm_hw_params (_soundDevice, hw_params)) < 0) { printf("Audio device parameters have not been set successfully.(%s)(%s)\n", strerror (err), snd_strerror (err)); return -1; } // Free the hardware parameters now that we're done with them. snd_pcm_hw_params_free (hw_params); /* Prepare interface for use. if ((err = snd_pcm_prepare (_soundDevice)) < 0) { printf("Audio device not prepared for use\n"); return -1; } // If the frames are received... /* find out how much space is available for playback data if ((frames_to_deliver = snd_pcm_avail_update (_soundDevice)) < 0) { printf("Error returned by snd_pcm_avail_update\n"); } frames_to_deliver = frames_to_deliver > 4096 ? 4096 : frames_to_deliver; printf("frames to deliver is %d\n",(int)frames_to_deliver); */ frames_to_deliver = 172; bufs[1] = (void*)buffer; if ((err = snd_pcm_writen( _soundDevice, bufs, frames_to_deliver)) < 0) { printf ("write failed (%s)\n", snd_strerror (err)); } ****************** end of code snippet ********************************** The error I get is as follows:- Audio device parameters have not been set successfully.(Unknown error 4294967274)(Invalid argument) Any pointers on what I could be doing wrong? Thanks and regards, Mitul

3 14

[alsa-devel] Still have choppy audio using 1.0.17
by Gustavo da Silva Serra 16 Jul '08

16 Jul '08

I have been trying for many weeks to solve this problem, but with no success. After updating to Alsa 1.0.17, which include changes to aloop, I still have choppy audio. I will try to summarize what happens: - I need to use aloop, if I change to a sound card all the problems are gone; - After some time of continuous play, applications start to reproduce choppy audio. Choppy audio doesn't happens all the time; - If I repeatedly start and stop my sound capture application choppy audio occur sooner; - Start/stop my application restores the sound quality (after some tryies); - This happens with ALSA applications (xine, vlc) and OSS emulated; - I have tryied many period_size and buffer_size in asound.conf, now I am using 960 for period and 3840 for buffer. As I decrease period size, the audio quality improves, but choppy audio still happens; - I test for overrun but no errors occur. - I am using block mode, interleaved, 44100, 16 bit, 2 channels - I am using dmix, dsnoop, removing them does not correct the audio These are some of the information I have, I don't know if is is enough. If necessary I can provide any other information. What do you suggest that I do? Are there any known issues or configuration requirements? Thanks in advance.

3 17