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

[alsa-devel] ALSA application programming: route audio from one PCM to another
by Stefan Schoenleitner 14 Apr '10

14 Apr '10

Hi, I finally managed to write an ALSA I/O plugin that does what I want. The plugin supports both playback and capture. Now I would like to write a simple audio application that takes audio samples * from the microphone and plays it back on my plugin and * from the plugin (capture) and plays it back on the speakers Hence as long as the application is running, it should do the above. * Is there a special ALSA way to route audio from one PCM to another ? * If not, I suppose it would just work if I open the plugin PCM and the hw PCM at the same time and copy audio frames between them ? cheers, stefan

2 4

[alsa-devel] Procfs cleanup in ALSA core
by Takashi Iwai 14 Apr '10

14 Apr '10

Hi, the another fixes are clean-ups of procfs interface in ALSA core. The patches below are found in sound git tree topic/core-cleanup branch. (This branch also contains the BKL-cleanup branch, too). [PATCH 1/5] ALSA: info - Use standard types for info callbacks [PATCH 2/5] ALSA: info - Check file position validity in common layer [PATCH 3/5] ALSA: info - Implement common llseek for binary mode [PATCH 4/5] ALSA: core - Define llseek fops [PATCH 5/5] ALSA: Update the documentation for changes of proc files Takashi

1 5

[alsa-devel] BKL removal from ALSA core
by Takashi Iwai 14 Apr '10

14 Apr '10

Hi, I recently cleaned up ALSA core code a bit. The first attemp is the removal of BKL, at least, in ALSA side. There are still in sound_core.c and OSS drivers, but who cares ;) The patches below are in sound git tree topic/bkl branch. [PATCH 1/3] ALSA: pcm - Remove BKL from async callback [PATCH 2/3] ALSA: info - Remove BKL [PATCH 3/3] ALSA: Remove BKL from open multiplexer Takashi

1 3

[alsa-devel] [RFC] ALSA: pcm_lib - read/write IO improvement
by Jarkko Nikula 14 Apr '10

14 Apr '10

Hi I've noticed a problem with the ALSA read/write IO as it tries to pad buffer as full/empty as possible after each wake-up. Then there is no wake-up during the next period interrupt since avail < avail_min and effectively there could be very short time left for wake-up on an interrupt after that. What I've seen on OMAP3 and Intel HDA that typically avail_max is only a frame or two less than size of two periods. I.e. very near to xrun when using a buffer with two periods. I came up with two ideas. The first one won't do padding and the second one which does the padding as currently but checks are there available frames in the next period and does a wake-up if necessary (even if the avail < avail_min). With the first one, the avail_max is typically a few frames more than the size of one period. With the second one it's a few frames less than size of one period. So by not doing the padding the distance to xrun is about the same and the wake-up semantics remains the same. I understood from the thread below that not all applications like if the wake-up happens before avail >= avail_min what would happen with the second idea. http://mailman.alsa-project.org/pipermail/alsa-devel/2009-December/023986.h… -- Jarkko ========================== RFC 1 ========================== From: Jarkko Nikula <jhnikula(a)gmail.com> Subject: [PATCH] ALSA: pcm_lib - Do not copy less than avail_min amount of frames in RW IO Copying less than avail_min amount of frames after each wake-up, i.e. by padding buffer as full/empty as possible by following the running HW pointer can actually cause xrun to be more possible than without padding. Padding causes that the avail is less than the avail_min when the next period interrupt occurs and thus no wake-up at that time. However, period interrupt following that one will see a situation where the avail is near the size of two periods. I.e. there could be only few frames left before xrun would happen if the buffer size is only two periods. Signed-off-by: Jarkko Nikula <jhnikula(a)gmail.com> --- sound/core/pcm_lib.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/core/pcm_lib.c b/sound/core/pcm_lib.c index a2ff861..a47a010 100644 --- a/sound/core/pcm_lib.c +++ b/sound/core/pcm_lib.c @@ -1821,7 +1821,7 @@ static snd_pcm_sframes_t snd_pcm_lib_write1(struct snd_pcm_substream *substream, if (runtime->status->state == SNDRV_PCM_STATE_RUNNING) snd_pcm_update_hw_ptr(substream); avail = snd_pcm_playback_avail(runtime); - if (!avail) { + if (avail < runtime->control->avail_min) { if (nonblock) { err = -EAGAIN; goto _end_unlock; @@ -2043,7 +2043,7 @@ static snd_pcm_sframes_t snd_pcm_lib_read1(struct snd_pcm_substream *substream, if (runtime->status->state == SNDRV_PCM_STATE_RUNNING) snd_pcm_update_hw_ptr(substream); avail = snd_pcm_capture_avail(runtime); - if (!avail) { + if (avail < runtime->control->avail_min) { if (runtime->status->state == SNDRV_PCM_STATE_DRAINING) { snd_pcm_stop(substream, SNDRV_PCM_STATE_SETUP); -- ========================== RFC 2 ========================== From: Jarkko Nikula <jhnikula(a)gmail.com> Subject: [PATCH] ALSA: pcm_lib - Do wake-up and copy if the next period has available frames It is possible that the next period has only a few frames before xrun would happen after next interrupt but wakeup does not happen now since the avail is less than the avail_min threshold. This patch adds a wake-up and copy check if the appl_ptr is less than end of next period so that application can transfer data already now. Signed-off-by: Jarkko Nikula <jhnikula(a)gmail.com> --- sound/core/pcm_lib.c | 17 +++++++++++++---- 1 files changed, 13 insertions(+), 4 deletions(-) diff --git a/sound/core/pcm_lib.c b/sound/core/pcm_lib.c index a2ff861..424873d 100644 --- a/sound/core/pcm_lib.c +++ b/sound/core/pcm_lib.c @@ -268,7 +268,7 @@ static void xrun_log_show(struct snd_pcm_substream *substream) int snd_pcm_update_state(struct snd_pcm_substream *substream, struct snd_pcm_runtime *runtime) { - snd_pcm_uframes_t avail; + snd_pcm_uframes_t avail, next_end; if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) avail = snd_pcm_playback_avail(runtime); @@ -287,7 +287,11 @@ int snd_pcm_update_state(struct snd_pcm_substream *substream, return -EPIPE; } } - if (avail >= runtime->control->avail_min) + next_end = runtime->hw_ptr_interrupt + 2 * runtime->period_size - 1; + if (next_end >=runtime->boundary) + next_end -= runtime->boundary; + if (avail >= runtime->control->avail_min || + runtime->control->appl_ptr <= next_end) wake_up(runtime->twake ? &runtime->tsleep : &runtime->sleep); return 0; } @@ -1707,7 +1711,7 @@ static int wait_for_avail_min(struct snd_pcm_substream *substream, int is_playback = substream->stream == SNDRV_PCM_STREAM_PLAYBACK; wait_queue_t wait; int err = 0; - snd_pcm_uframes_t avail = 0; + snd_pcm_uframes_t avail = 0, next_end; long tout; init_waitqueue_entry(&wait, current); @@ -1750,7 +1754,12 @@ static int wait_for_avail_min(struct snd_pcm_substream *substream, avail = snd_pcm_playback_avail(runtime); else avail = snd_pcm_capture_avail(runtime); - if (avail >= runtime->control->avail_min) + next_end = runtime->hw_ptr_interrupt + + 2 * runtime->period_size - 1; + if (next_end >=runtime->boundary) + next_end -= runtime->boundary; + if (avail >= runtime->control->avail_min || + runtime->control->appl_ptr <= next_end) break; } _endloop: --

3 3

[alsa-devel] Help needed
by Akhilesh Soni 14 Apr '10

14 Apr '10

Hi, I'm using Osprey-440 4 channel Capture card in Centos 5.4 distribution with kernel 2.6.18-164.15.1.el5 #1 SMP Wed Mar 17 11:30:06 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux I'm able to load the bttv driver for video capture and it created /dev/video0 /dev/video1 /dev/video2 /dev/video3 devices which I'm able to capture as well. But when I do modprobe snd-bt87x i'm unable to get the audio capture devices either /dev/audio or /dev/dsp Is there any parameters to be given in inserting this module for the card. Please guide me to resolve this issue. Is there any place where I can get the latest driver source for this card Thanks in advance. Akhilesh

3 2

[alsa-devel] asus xonar d1
by Lars Schotte 14 Apr '10

14 Apr '10

i finally got the asus xonar d1 and installed the latest kernel from the backports for debian lenny and the card doesnt work at all and has unbelievably less controls in the mixer, so my guess is that the driver is ok, but alsa can not operate it. i am keeping on trying. i am about to download fedora 13 beta to test it there, maybe it helps. while the download is runing i am continuing to try and look what could be the problem. -- ------------------- Lars Schotte @ romy

2 2

[alsa-devel] Laggy mixer with Xonar DX snd_virtuoso
by Flávio Martins 14 Apr '10

14 Apr '10

Hello Alsa team, I have a Xonar DX with a laggy volume control, you might have guessed already. Sound will interrupt if the volume change is big like from 100% to 50%, it will only skip a bit if the volume change is smaller. The interruptions/silence last more than 5 seconds easily. I can actually see the mixer slider going up and down on its own. I am seeking for your help and i'm using 1.0.22.1. Here goes the alsa-info.sh output, some weird things going on in dmesg http://www.alsa-project.org/db/?f=ee911fe73baa60aac51c62ff787ab8b8bd8565e8 Flávio Martins

2 3

[alsa-devel] no soundcards detected on MCP51 rev a
by Gregory T Flynn 14 Apr '10

14 Apr '10

$ alsaconf will detect the soundcard but $ aplay -l aplay: device_list:223: no soundcards found... ALC883 Realtek lspci: 00:10.1 Audio device: nVidia Corporation MCP51 High Definition Audio (rev a2) Alsa info result: upload=true&script=true&cardinfo= !!################################ !!ALSA Information Script v 0.4.59 !!################################ !!Script ran on: Tue Apr 13 20:50:40 UTC 2010 !!Linux Distribution !!------------------ Arch Linux \r (\n) (\l) !!DMI Information !!--------------- Manufacturer: Micro-Star International Product Name: MEGA BOOK S430 !!Kernel Information !!------------------ Kernel release: 2.6.33-ARCH Operating System: GNU/Linux Architecture: x86_64 Processor: AMD Turion(tm) 64 X2 Mobile Technology TL-50 SMP Enabled: Yes !!ALSA Version !!------------ Driver version: 1.0.21 Library version: 1.0.22 Utilities version: 1.0.22 !!Loaded ALSA modules !!------------------- !!Sound Servers on this system !!---------------------------- ESound Daemon: Installed - Yes (/usr/bin/esd) Running - No Jack: Installed - Yes (/usr/bin/jackd) Running - No !!Soundcards recognised by ALSA !!----------------------------- --- no soundcards --- !!PCI Soundcards installed in the system !!-------------------------------------- 00:10.1 Audio device: nVidia Corporation MCP51 High Definition Audio (rev a2) !!Advanced information - PCI Vendor/Device/Susbsystem ID's !!-------------------------------------------------------- 00:10.1 0403: 10de:026c (rev a2) Subsystem: 1462:373d !!Loaded sound module options !!-------------------------- !!ALSA Device nodes !!----------------- crw-rw----+ 1 root audio 116, 3 Apr 13 14:37 /dev/snd/seq crw-rw----+ 1 root audio 116, 2 Apr 13 14:37 /dev/snd/timer !!Aplay/Arecord output !!------------ APLAY aplay: device_list:223: no soundcards found... ARECORD arecord: device_list:223: no soundcards found... !!Amixer output !!------------- !!Alsactl output !!------------- --startcollapse-- --endcollapse-- !!All Loaded Modules !!------------------ Module ipt_MASQUERADE xt_state ipt_REJECT xt_tcpudp iptable_filter nf_nat_h323 nf_conntrack_h323 nf_nat_pptp nf_conntrack_pptp nf_conntrack_proto_gre nf_nat_proto_gre nf_nat_tftp nf_conntrack_tftp nf_nat_sip nf_conntrack_sip nf_nat_irc nf_conntrack_irc nf_nat_ftp nf_conntrack_ftp iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 ip_tables x_tables ipv6 ext2 joydev usbhid hid arc4 ecb rt73usb crc_itu_t rt2x00usb rt2x00lib led_class mac80211 cfg80211 rfkill snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_hda_intel snd_pcm_oss snd_hda_codec snd_hwdep snd_pcm snd_mixer_oss ohci_hcd snd_timer video ac battery ehci_hcd snd snd_page_alloc nvidia output usbcore thermal i2c_nforce2 i2c_core button k8temp processor forcedeth psmouse sg edac_core edac_mce_amd evdev serio_raw soundcore fuse rtc_cmos rtc_core rtc_lib ext4 mbcache jbd2 crc16 sr_mod sd_mod cdrom ata_generic pata_acpi pata_amd sata_nv libata scsi_mod !!ALSA/HDA dmesg !!------------------ ACPI: PCI Interrupt Link [LAZA] enabled at IRQ 23 HDA Intel 0000:00:10.1: PCI INT B -> Link[LAZA] -> GSI 23 (level, low) -> IRQ 23 hda_intel: Disable MSI for Nvidia chipset HDA Intel 0000:00:10.1: setting latency timer to 64 usb 1-8: new high speed USB device using ehci_hcd and address 3 -- usbhid: USB HID core driver hda-intel: azx_get_response timeout, switching to polling mode: last cmd=0x000f0000 hda-intel: Codec #0 probe error; disabling it... hda-intel: Codec #1 probe error; disabling it... hda-intel: Codec #2 probe error; disabling it... hda-intel: Codec #3 probe error; disabling it... hda_intel: azx_get_response timeout, switching to single_cmd mode: last cmd=0x000f0000 hda-intel: no codecs initialized HDA Intel 0000:00:10.1: PCI INT B disabled EXT4-fs (sda4): mounted filesystem with ordered data mode -- - Greg Flynn

2 1

[alsa-devel] alsa-lib pcm_share.c snd_pcm_share_open() bug ?
by Mathieu Desnoyers 13 Apr '10

13 Apr '10

Hi, I was looking at snd_pcm_share_open() in alsa-lib-1.0.22, and stumbled on the following line: pcm->monotonic = pcm->monotonic; what is that supposed to do ? There is clearly something wrong there. Thanks, Mathieu -- Mathieu Desnoyers Operating System Efficiency R&D Consultant EfficiOS Inc. http://www.efficios.com

3 4

[alsa-devel] [PATCH] Use thread-safe locale functions
by Rémi Denis-Courmont 13 Apr '10

13 Apr '10

setlocale() is not thread-safe. It can actually trigger a crash if another thread uses locale informations at the same time in the process. Library code should use POSIX newlocale/duplocale/uselocale/freelocale instead. Those functions only change the locale data for the calling thread. --- src/conf.c | 16 +++++++--------- 1 files changed, 7 insertions(+), 9 deletions(-) diff --git a/src/conf.c b/src/conf.c index 570c90f..ce252ab 100644 --- a/src/conf.c +++ b/src/conf.c @@ -499,22 +499,20 @@ static int safe_strtod(const char *str, double *val) { char *end; double v; - char *saved_locale; - char locstr[64]; /* enough? */ + locale_t saved_locale, c_locale; int err; if (!*str) return -EINVAL; - saved_locale = setlocale(LC_NUMERIC, NULL); - if (saved_locale) { - snprintf(locstr, sizeof(locstr), "%s", saved_locale); - setlocale(LC_NUMERIC, "C"); - } + c_locale = newlocale(LC_NUMERIC_MASK, "C", 0); + saved_locale = uselocale(c_locale); errno = 0; v = strtod(str, &end); err = -errno; - if (saved_locale) - setlocale(LC_NUMERIC, locstr); + if (c_locale != (locale_t)0) { + uselocale(saved_locale); + freelocale(c_locale); + } if (err) return err; if (*end) -- 1.7.0.4

2 3