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

[alsa-devel] How to stop playback on alsa synth?
by Lukasz Pawelczyk 16 Mar '08

16 Mar '08

Hello. I'd like to ask how to completely stop playback using alsa synth. Basically my program initialized output in the following way: snd_seq_open() snd_seq_set_client_name() snd_seq_client_id() snd_seq_parse_address() snd_seq_create_simple_port() snd_seq_connect_to() snd_seq_alloc_named_queue() Then I create a new thread that processes events. It sets tempo and in infinite loop it does: snd_seq_ev_set_fixed() snd_seq_event_output() This all is based on aplaymidi code. How can I asynchronously immediately stop all the playback? Basicaly it requires breaking snd_seq_event_output() thats locked on my thread. I tried everything I could come up with. I know very little about alsa synth programming and basically thats the only thing i need to do now. Tried: snd_seq_ev_set_queue_stop() snd_seq_stop_queue() snd_seq_remove_events() or even closing the seq completely to reopen it on another file playback with: snd_seq_stop_queue() snd_seq_disconnect_to() snd_seq_delete_simple_port() snd_seq_close() All failed, results were very various. I simply run out of ideas. It doesn't matter if the method would require to close seq or not. I just need to stop the playback so i can gracefully stop the thread and play another file (with eventual reopening ports/seq). Would appreciate any help. -- Regards Havner {jid,mail}:havner(at)pld-linux.org "Quis custodiet ipsos custodes?"

1 1

[PATCH] Correct dapm controls length.
by Robert Jarzmik 16 Mar '08

16 Mar '08

Dapm control names should follow alsa standard, which defines controls name's length to 44 and not 32. Signed-off-by: Robert Jarzmik <rjarzmik(a)free.fr> Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- sound/soc/soc-dapm.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/soc/soc-dapm.c b/sound/soc/soc-dapm.c index 4b03e3f..a61024c 100644 --- a/sound/soc/soc-dapm.c +++ b/sound/soc/soc-dapm.c @@ -281,7 +281,7 @@ static int dapm_new_mixer(struct snd_soc_card *soc_card, struct snd_soc_dapm_widget *w) { int i, ret = 0; - char name[32]; + char name[44]; struct snd_soc_dapm_path *path; /* add kcontrol */ @@ -295,7 +295,7 @@ static int dapm_new_mixer(struct snd_soc_card *soc_card, continue; /* add dapm control with long name */ - snprintf(name, 32, "%s %s", w->name, w->kcontrols[i].name); + snprintf(name, 44, "%s %s", w->name, w->kcontrols[i].name); path->long_name = kstrdup (name, GFP_KERNEL); if (path->long_name == NULL) return -ENOMEM; -- 1.5.6.5

1 0

[PATCH] Dirty hack to use GPIO95 in AC97 reset.
by Robert Jarzmik 16 Mar '08

16 Mar '08

Mio Mitac A701 uses GPIO95 instead of GPIO113 as the reset line connected to the WM9713 chip. This is dirty, and should be replaced by an elegant solution where cold and warm reset are implemented in machine driver mioa701_wm9713.c Signed-off-by: Robert Jarzmik <rjarzmik(a)free.fr> --- sound/soc/pxa/pxa2xx-ac97.c | 12 ++++++------ 1 files changed, 6 insertions(+), 6 deletions(-) diff --git a/sound/soc/pxa/pxa2xx-ac97.c b/sound/soc/pxa/pxa2xx-ac97.c index cb12544..86fb9c2 100644 --- a/sound/soc/pxa/pxa2xx-ac97.c +++ b/sound/soc/pxa/pxa2xx-ac97.c @@ -145,10 +145,10 @@ static void pxa2xx_ac97_warm_reset(struct snd_ac97 *ac97) #ifdef CONFIG_PXA27x /* warm reset broken on Bulverde, so manually keep AC97 reset high */ - pxa_gpio_mode(113 | GPIO_OUT | GPIO_DFLT_HIGH); + pxa_gpio_mode(95 | GPIO_OUT | GPIO_DFLT_HIGH); udelay(10); GCR |= GCR_WARM_RST; - pxa_gpio_mode(113 | GPIO_ALT_FN_2_OUT); + pxa_gpio_mode(95 | GPIO_ALT_FN_1_OUT); udelay(500); #elif defined(CONFIG_PXA3xx) /* Can't use interrupts */ @@ -303,8 +303,8 @@ static int pxa2xx_ac97_resume(struct platform_device *dev) pxa_gpio_mode(GPIO29_SDATA_IN_AC97_MD); #endif #ifdef CONFIG_PXA27x - /* Use GPIO 113 as AC97 Reset on Bulverde */ - pxa_gpio_mode(113 | GPIO_ALT_FN_2_OUT); + /* Use GPIO 95 as AC97 Reset on Bulverde */ + pxa_gpio_mode(95 | GPIO_ALT_FN_1_OUT); #endif clk_enable(ac97_clk); return 0; @@ -457,8 +457,8 @@ static int pxa2xx_ac97_probe(struct platform_device *pdev) return -ENOMEM; #ifdef CONFIG_PXA27x - /* Use GPIO 113 as AC97 Reset on Bulverde */ - pxa_gpio_mode(113 | GPIO_ALT_FN_2_OUT); + /* Use GPIO 95 as AC97 Reset on Bulverde */ + pxa_gpio_mode(95 | GPIO_ALT_FN_1_OUT); ac97conf_clk = clk_get(&pdev->dev, "AC97CONFCLK"); if (IS_ERR(ac97conf_clk)) { -- 1.5.5.3 --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=0002-Dirty-hack-to-workaround-pxa27x-buggy-hardreset.patch

1 0

[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