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

[alsa-devel] Maya44 driver in the official ALSA tree
by Piotr Zaryk 15 Mar '08

15 Mar '08

Hi, When will be the next alsa-driver version released? Can't wait till maya44 support will be added to the official alsa tree. It will help with the development of the new driver. -- Piotr Zaryk

3 3

Re: [alsa-devel] no front speaker sound with ALC262
by Takashi Iwai 14 Mar '08

14 Mar '08

At Fri, 29 Feb 2008 17:24:03 +0100, Rene Dohmen wrote: > > No I still don't know where the speakers are conencted. > I asked the support engineers at tangent to send me a detailed > blockdiagram of their sound solution and ik think i'll receive that > sooner or later. > > So, for now, I just tried passing the EAPD option to all NIDS in the > codec#0 file. > > I attached the code#0 file while working with very low volume > > When I run > sudo hda-verb/hda-verb /dev/snd/hwC0D0 0x03 SET_EAPD 0x02 > or > sudo hda-verb/hda-verb /dev/snd/hwC0D0 0x02 SET_EAPD 0x02 Doh, I actually misunderstood that your codec were ALC268 but it's ALC262. EAPD command can be issued only on widgets that support. ALC262 has no EAPD pin caps at all. so it doesn't work like that. Instead, ALC262 (and other Realtek codecs) has a special sequence with coefficients to the vendor-defined widget. Yes, it's a black magic. Try the following sequence: 0x20 SET_COEF_INDEX 0x07 0x20 SET_PROC_COEF 0x3060 0x3060 can be different numbers like 0x3070 or 0x3050. If you set a different number, reset the coef index again (i.e. always call as a pair). Takashi

3 3

[alsa-devel] aplay: playback:2021: read error
by Pharaoh . 14 Mar '08

14 Mar '08

Hi, I am getting aplay: playback:2021: read error while running my plugin on an arm based board, it seems that, this has to do something with permissions etc or may be the sound card is being shared etc. I don't have a registered sound card since there is no kernel driver for my sound hw. I use my plugin as, aplay -D my_plug test.wav -pharaoh.

2 2

[alsa-devel] AK4114 - capturing spdif input stops the stream
by Pavel Hofman 14 Mar '08

14 Mar '08

Hi, here is my scenario: ICE1724 card, trying to record from SPDIF input via AK4114, ICE1724 slaved to SPDIF clock from the receiver. The card detects SPDIF input rate correctly (in my case ESI Juli where AK4114 is provided with independent clock signal to enable the rate detection). Let's say it is 192000. Now I want to arecord the input stream, let's say in CD quality, using the plug plugin. The command fails, because of the check in ak4114.c: res = external_rate(rcs1); if (!(flags & AK4114_CHECK_NO_RATE) && runtime && runtime->rate != res) { snd_pcm_stream_lock_irqsave(ak4114->capture_substream, _flags); if (snd_pcm_running(ak4114->capture_substream)) { printk(KERN_DEBUG "rate changed (%i <- %i)\n", runtime->rate, res); snd_pcm_stop(ak4114->capture_substream, SNDRV_PCM_STATE_DRAINING); res = 1; } snd_pcm_stream_unlock_irqrestore(ak4114->capture_substream, _flags); } The stream gets stopped because res = 192000 and runtime->rate = 44100. The problem is that the capture device still offers all the available rates, instead of the single SPDIF input one. Thus, the plug plugin is not forced to convert from 192000 to 44100 and runtime->rate is 44100 instead of 192000. Of course recording at 192000 works fine. What would be the best way to force the SPDIF capture device to offer (advertise) only the current rate? This functionality would have to be applicable only to the few cards correctly detecting incoming rate (unlike most ice1724 cards without independent clock in slave mode). If the card cannot detect input frequency reliably (the driver developer should know), I guess it should not do the check in ak4114.c at all - I can prepare a simple patch for that. The same will most probably apply to cards with AK4117 as the code looks the same. I know it is a minor issue but if a user hits this problem, it will take him a lot of effort to fix his setup appropriately. Thanks, Pavel.

2 7

[alsa-devel] [ALC262 patch_realtek.c] Fujitsu Lifebook port replicator/dock headphone jack sense
by Tony Vroon 14 Mar '08

14 Mar '08

Good afternoon, Could you please consider the following patch for the 2.6.26 merge window. The docking station headphone output had no audio and jack sense was not considered. Jack information from the laptop itself and the dock are combined, as the dock does not obscure the connector. Signed-Off-By: Tony Vroon <tony(a)linx.net> Regards, Tony V. LINX sysadmin P.S. Codec graph included in case anyone wants to start using mic jack sense for automated capture source selection.

2 3

[alsa-devel] Underrun errors in aplay
by Barclay, Bruce 14 Mar '08

14 Mar '08

I have written a driver for Alsa and I think the sound is correct but I do get underrun errors. I don't understand how aplay would know if I am starved. This doesn't make sense to me. I would only think that the driver should know about underruns but maybe I am confused with this. I am wondering if I am calling snd_pcm_period_elapsed too often. I am calling that when I have free H/W buffers. Thanks, Bruce

2 1

[alsa-devel] reading peak meter values from a RME HDSP madi soundcard
by ListsAccount 14 Mar '08

14 Mar '08

Hi, I'd like to read the peak values of the RME HDSP madi soundcard. To do this, I use the function: snd_hwdep_ioctl() with the ioctl command "SNDRV_HDSPM_IOCTL_GET_PEAK_RMS". I use the following code: // create container hdspm_peak_rms_t madi_peak_rms; hdspm_peak_rms_t* ptr_madi_peak_rms = &madi_peak_rms; //snd_hwdep_open ... // fill the container with values snd_hwdep_ioctl(hw, SNDRV_HDSPM_IOCTL_GET_PEAK_RMS, (void *)&ptr_madi_peak_rms); for (unsigned int chn = 0; chn < numberOfChannels; ++chn) { //put values from madi soundcard into std::vector containers currentInputPeak[chn] = madi_peak_rms.level_offset[chn]; currentPlaybackPeak[chn] = madi_peak_rms.level_offset[chn+64]; currentOutputPeak[chn] = madi_peak_rms.level_offset[chn+128]; } The upper 24 bit of the read out values should be the signal peak. The next 8 bit seem to represent a clipping counter. For the first eight input channels this works pretty well. But for every eighth channel of all further channels (input, playback and output) the peak value is to low and is not in time with the other channels. Do i use the function in the right way? Is there a special function to get the peak meter values? (In a similar way as for ADAT soundcards?) Best regards.

1 0

[alsa-devel] bugfix for RME HDSPM alsa driver
by ListsAccount 14 Mar '08

14 Mar '08

Hi, I have had the following problem with the RME HDSPM alsa driver: settings of card: Preferred Sync Reference = Word Sample Clock Source = AutoSync and no input plugged in (neither madi nor optical) playing a file (important!) Monitoring the external rate with amixer, the value was jumping between "None" and "48000 kHz". The proc output showed that the sample rate on word clock was still right at 48000 kHz while the external rate was jumping here, too. External rate seems to jump between word clock and madi input select. When "Preferred Sync Reference = Word" is selected, just the word clock rate should be displayed! I fixed the problem with following patch in alsa-driver-1.0.16/alsa-kernel/pci/rme9652/hdspm.c in function hdspm_external_sample_rate() line 668: There was a typo: instead of status2, status was used. 668c668 < (status & HDSPM_SelSyncRef0) == 0) { --- > (status2 & HDSPM_SelSyncRef0) == 0) { (same way as in snd_hdspm_proc_read_madi function line 3123) greetings

1 0

[alsa-devel] Scope of snd_pcm_hw_params_alloca() ?
by Alan Horstmann 14 Mar '08

14 Mar '08

I've spent a couple of days pining this down. snd_pcm_hw_params_alloca() is part of the user API -right? But accomplished as a #define in pcm.h. However if it is called inside a function, and the pointer stored for future use, after leaving the function the allocation seems to have gone, and attempting thereafter to use the pointer to access the hwparams space in another API function results in seg-fault. This seems rather counter-intuitive (ie unexpected) to someone who has no knowledge of the inner workings, but simply uses the API; the allocation disappears without having been specifically free'd or released in any way. I know that calling it globally gets round the problem, but certainly I could do without all the debug needed to discover that. Comments? Alan

2 3

Re: [alsa-devel] Scope of snd_pcm_hw_params_alloca() ?
by Takashi Iwai 14 Mar '08

14 Mar '08

At Thu, 13 Mar 2008 15:41:02 -0300, Aldrin Martoq wrote: > > Hello, > > On Thu, Mar 13, 2008 at 1:44 PM, Takashi Iwai <tiwai(a)suse.de> wrote: > > At Thu, 13 Mar 2008 16:21:51 +0000, > > Alan Horstmann wrote: > > > I've spent a couple of days pining this down. > > > snd_pcm_hw_params_alloca() is part of the user API -right? But accomplished > > > as a #define in pcm.h. > > Because alloca can be used only with a macro due to its nature. > > > However if it is called inside a function, and the pointer stored for future > > > use, after leaving the function the allocation seems to have gone, and > > > attempting thereafter to use the pointer to access the hwparams space in > > > another API function results in seg-fault. > > You should use snd_pcm_hw_params_malloc() instead. *_alloca() from > asoundlib are based in alloca(). From my system man: > > $ man alloca > NAME > alloca - memory allocator > > SYNOPSIS > #include <alloca.h> > > void *alloca(size_t size); > > DESCRIPTION > The alloca() function allocates size bytes of space in the stack frame > of the caller. This temporary space is automatically freed when the > function that called alloca() returns to its caller. > > [..] > > Yup, this is actually very useful in many many many places! Especially in C, that isn't easy to have implicit destructors. BTW, a pitfall once I fell into is that the alloca frees the data at the function exit, not at the block exit. So, the following code eats stack up and shall evetually dies: { ... for (;;) { char *tmp = alloca(4096); ... } ... } Takashi

1 0