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

[alsa-devel] [PATCH] PulseAudio plugin: report XRUN state back to application
by Lennart Poettering 22 Dec '07

22 Dec '07

Hi! Please consider merging this patch we ship in Fedora: http://cvs.fedoraproject.org/viewcvs/*checkout*/devel/alsa-plugins/1.0.14-s… It adds support to report back XRUN to the application if one happens. This is required to make some applications work on top of the pulse plugin. One being XMMS, which checks if a song finished to play by waiting for an XRUN (yes, I don't argue that XMMS shouldn't do that, but nonetheless it is a good thing if XRUNs are reported properly.) Now, this patch is a bit problematic, since it touches pcm->io.state which is not supposed to be touched by ioplug-based plugins -- according to the comments in ioplug. However, I saw no other way to fix this, and from judging the ioplug code overwriting the variable should be safe. Thus I decided to simply touch the variable but documented it in a comment. Alternatively, ioplug could be beefed up to properly handle XRUNs, but I thought this fix is simpler. Also reported on the ALSA BTS: https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3579 Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4

2 2

[alsa-devel] write/read system calls and ioctl
by Michael Voigt 22 Dec '07

22 Dec '07

Dear ALSA developers, At the beginning, I would like to give a short introdution of myself, then my question follows. My project: =============== Currently, I am interning at the TU Dresden operating systems group's [1] and it is my task to port ALSA to DROPS [2, 3], a L4-microkernel-based real-time system. The long-term goal of this project should be to establish a truely real-time capable FOSS platform for audio recording and processing. The current state of the project: By using DDELinux [4] and writing a small kernel-user inferface emulation layer, we now have an unchanged version of ALSA and an unchanged version of salsa-lib [5] running on our system. The next steps will be to test how stable this port is and fix bugs. Then, during my diploma thesis, it is my task to port Jack (or an equivalent) to our system and to evaluate how to make the whole thing to work in real-time. But now my question: =============== In the file pcm_native in alsa-core read (snd_pcm_read) and write (snd_pcm_write) functions are attached to the snd_pcm_f_ops. But as far as I can see, these write- und read- system calls aren't used either in salsa-lib or in alsa-lib. I can see that in former versions of alsa-lib (for instance alsalib-0.0.3) the write system call was used to implement snd_pcm_write (LIB); but now we have snd_pcm_writei (LIB) and snd_pcm_writen (LIB) which use ioctl. I guess this was done to realize both interleaved and noninterleaved audio playback (The old snd_pcm_write (LIB) was based on bytes not on frames and did not have a notion of interleaved/noninterleaved playback?). If I have a look at snd_pcm_write (KERNEL, pcm_native.c), I can see it also ends up in snd_pcm_lib_write(...). So does ioctl with SNDRV_PCM_IOCTL_WRITEI_FRAMES as argument, but snd_pcm_write (KERNEL) does not copy the frames to kernel memory. My question: what is snd_pcm_write in pcm_native.c good for? Is it only there to keep ALSA compatible to older versions of alsa-lib? Kindest regards, Michael Voigt ================ [1] http://www.inf.tu-dresden.de/index.php?node_id=1141&ln=en [2] http://www.osnews.com/story.php/15814/Introduction-to-TUD-OS/ [3] http://www.realtimelinuxfoundation.org/variants/variants.html#VARIANTS_DROPS [4] http://demo.tudos.org/dsweeper_tutorial.html [5] http://ftp.isr.ist.utl.pt/pub/MIRRORS/ftp.suse.com/people/tiwai/salsa-lib/ ================ -- Today is Pungenday, the 61st day of The Aftermath in the YOLD 3173

2 2

Re: [alsa-devel] snd-hda-intel support for SPDIF-in wiht vt1708 card?
by forumjunk＠comcast.net 21 Dec '07

21 Dec '07

Well, I spoke too soon... with or without the via patch, I now get an error from the driver about an inappropriate ioctl for the device while KDE is trying to start the sound system. On a command line, madplay and aplay return this: #> aplay /usr/share/sounds/KDE_Glass_Break.ogg #> ALSA lib pcm_dmix.c:866:(snd_pcm_dmix_open) unable to open slave #> aplay: main:546: audio open error: Device or resource busy #> aplay /usr/share/sounds/pop.wav #> ALSA lib pcm_dmix.c:866:(snd_pcm_dmix_open) unable to open slave #> aplay: main:546: audio open error: Device or resource busy #> madplay /usr/share/sounds/KDE_Glass_Break.ogg #> MPEG Audio Decoder 0.15.2 (beta) - Copyright © 2000-2004 Robert Leslie et al. #> audio: /dev/dsp: Device or resource busy #> madplay /usr/share/sounds/pop.wav #> MPEG Audio Decoder 0.15.2 (beta) - Copyright © 2000-2004 Robert Leslie et al. #> audio: /dev/dsp: Device or resource busy alsaconf correctly detects the VT1708, and alsamixer and alsactl all seem to work correctly. I've tried obtaining and installing the latest mercurial clone of alsa-lib, and I've tried this with or without the patch_via.c patch below. Am I doing something wrong? -- Darryl -------------- Original message ---------------------- From: forumjunk(a)comcast.net (Darryl House) > The patch fixed all compilation errors for me, thank you. I did have to apply it > manually, but that was rather simple. > > I can confirm that SPDIF input doesn't work for the card, but I haven't applied > the patch that you suggested to John Stile for that, yet. I'll do that a bit > later today if you still recommend it > > Is this patch still recommended? > > > diff -r 2d3893cf030c pci/hda/patch_via.c > > --- a/pci/hda/patch_via.c Tue Dec 18 15:42:53 2007 +0100 > > +++ b/pci/hda/patch_via.c Tue Dec 18 17:48:00 2007 +0100 > > @@ -568,25 +568,27 @@ static int via_init(struct hda_codec *co > > if (IS_VT1708_VENDORID(codec->vendor_id)) { > > snd_hda_codec_write(codec, VT1708_DIGIN_PIN, 0, > > AC_VERB_SET_PIN_WIDGET_CONTROL, > > - 0x40); > > + PIN_OUT); > > snd_hda_codec_write(codec, VT1708_DIGIN_PIN, 0, > > AC_VERB_SET_EAPD_BTLENABLE, 0x02); > > } else if (IS_VT1709_10CH_VENDORID(codec->vendor_id) || > > IS_VT1709_6CH_VENDORID(codec->vendor_id)) { > > snd_hda_codec_write(codec, VT1709_DIGIN_PIN, 0, > > AC_VERB_SET_PIN_WIDGET_CONTROL, > > - 0x40); > > + PIN_OUT); > > snd_hda_codec_write(codec, VT1709_DIGIN_PIN, 0, > > AC_VERB_SET_EAPD_BTLENABLE, 0x02); > > } else if (IS_VT1708B_8CH_VENDORID(codec->vendor_id) || > > IS_VT1708B_4CH_VENDORID(codec->vendor_id)) { > > snd_hda_codec_write(codec, VT1708B_DIGIN_PIN, 0, > > AC_VERB_SET_PIN_WIDGET_CONTROL, > > - 0x40); > > + PIN_OUT); > > snd_hda_codec_write(codec, VT1708B_DIGIN_PIN, 0, > > AC_VERB_SET_EAPD_BTLENABLE, 0x02); > > } > > - } > > + } else /* enable SPDIF-input pin */ > > + snd_hda_codec_write(codec, spec->autocfg.dig_in_pin, 0, > > + AC_VERB_SET_PIN_WIDGET_CONTROL, PIN_IN); > > > > return 0; > > } > > Thanks again! > > -- Darryl > > > -------------- Original message ---------------------- > From: Takashi Iwai <tiwai(a)suse.de> > [...] > > Thanks. Does the patch below fix the probelm? > > Run hgcompile after applying it. > > > > > > Takashi > > > > diff -r 414b1156a8b3 configure.in > > --- a/configure.in Tue Dec 18 16:09:20 2007 +0100 > > +++ b/configure.in Fri Dec 21 12:10:53 2007 +0100 > > @@ -1230,7 +1230,7 @@ esac > > > > dnl set ia32 (X86) > > case "$processor" in > > - i?86*|k?|crusoe|mcyrixiii|mwinchip|viac3_2|mcore2|geodegx*) > > + i?86*|k?|crusoe|mcyrixiii|mwinchip|viac3_2|mcore2|geodegx*|x86_32) > > if $KCC -mpreferred-stack-boundary=2 -S -o /dev/null -xc /dev/null > > >/dev/null 2>&1; then > > c_opts="-mpreferred-stack-boundary=2 $c_opts" > > CONFIG_X86=y > > _______________________________________________ > > Alsa-devel mailing list > > Alsa-devel(a)alsa-project.org > > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel > > _______________________________________________ > Alsa-devel mailing list > Alsa-devel(a)alsa-project.org > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

1 0

Re: [alsa-devel] snd-hda-intel support for SPDIF-in wiht vt1708 card?
by forumjunk＠comcast.net 21 Dec '07

21 Dec '07

The patch fixed all compilation errors for me, thank you. I did have to apply it manually, but that was rather simple. I can confirm that SPDIF input doesn't work for the card, but I haven't applied the patch that you suggested to John Stile for that, yet. I'll do that a bit later today if you still recommend it Is this patch still recommended? > diff -r 2d3893cf030c pci/hda/patch_via.c > --- a/pci/hda/patch_via.c Tue Dec 18 15:42:53 2007 +0100 > +++ b/pci/hda/patch_via.c Tue Dec 18 17:48:00 2007 +0100 > @@ -568,25 +568,27 @@ static int via_init(struct hda_codec *co > if (IS_VT1708_VENDORID(codec->vendor_id)) { > snd_hda_codec_write(codec, VT1708_DIGIN_PIN, 0, > AC_VERB_SET_PIN_WIDGET_CONTROL, > - 0x40); > + PIN_OUT); > snd_hda_codec_write(codec, VT1708_DIGIN_PIN, 0, > AC_VERB_SET_EAPD_BTLENABLE, 0x02); > } else if (IS_VT1709_10CH_VENDORID(codec->vendor_id) || > IS_VT1709_6CH_VENDORID(codec->vendor_id)) { > snd_hda_codec_write(codec, VT1709_DIGIN_PIN, 0, > AC_VERB_SET_PIN_WIDGET_CONTROL, > - 0x40); > + PIN_OUT); > snd_hda_codec_write(codec, VT1709_DIGIN_PIN, 0, > AC_VERB_SET_EAPD_BTLENABLE, 0x02); > } else if (IS_VT1708B_8CH_VENDORID(codec->vendor_id) || > IS_VT1708B_4CH_VENDORID(codec->vendor_id)) { > snd_hda_codec_write(codec, VT1708B_DIGIN_PIN, 0, > AC_VERB_SET_PIN_WIDGET_CONTROL, > - 0x40); > + PIN_OUT); > snd_hda_codec_write(codec, VT1708B_DIGIN_PIN, 0, > AC_VERB_SET_EAPD_BTLENABLE, 0x02); > } > - } > + } else /* enable SPDIF-input pin */ > + snd_hda_codec_write(codec, spec->autocfg.dig_in_pin, 0, > + AC_VERB_SET_PIN_WIDGET_CONTROL, PIN_IN); > > return 0; > } Thanks again! -- Darryl -------------- Original message ---------------------- From: Takashi Iwai <tiwai(a)suse.de> [...] > Thanks. Does the patch below fix the probelm? > Run hgcompile after applying it. > > > Takashi > > diff -r 414b1156a8b3 configure.in > --- a/configure.in Tue Dec 18 16:09:20 2007 +0100 > +++ b/configure.in Fri Dec 21 12:10:53 2007 +0100 > @@ -1230,7 +1230,7 @@ esac > > dnl set ia32 (X86) > case "$processor" in > - i?86*|k?|crusoe|mcyrixiii|mwinchip|viac3_2|mcore2|geodegx*) > + i?86*|k?|crusoe|mcyrixiii|mwinchip|viac3_2|mcore2|geodegx*|x86_32) > if $KCC -mpreferred-stack-boundary=2 -S -o /dev/null -xc /dev/null > >/dev/null 2>&1; then > c_opts="-mpreferred-stack-boundary=2 $c_opts" > CONFIG_X86=y > _______________________________________________ > Alsa-devel mailing list > Alsa-devel(a)alsa-project.org > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

1 0

[alsa-devel] no input/output analog channels on rme multiface I
by rmgls＠free.fr 21 Dec '07

21 Dec '07

Hi all, the multiface 1, does not work for me. it is recognized as hammerfal DSP, but the amixer shows no analog in/out (there are 8 analog I/O in the box) and of course no volume control for any channel. the driver: hg: 20071205, the last lib, and firmware, and utils. unpluging the box (power off), and loading the firmware on windows gives: in the debian (2.6.24-rc3) dmesg: e9652/../../alsa-kernel/pci/rme9652/hdsp.c:5037: Hammerfall-DSP: Firmware already present, initializing card. ... pcmcia: Detected deprecated PCMCIA ioctl usage from process: discover. pcmcia: This interface will soon be removed from the kernel; please expect breakage unless you upgrade to new tools. pcmcia: see http://www.kernel.org/pub/linux/utils/kernel/pcmcia/pcmcia.html for details. sndstat reports: Xilinx FPGA ??? and now amixer -c2: Simple mixer control 'Line Out',0 Capabilities: pswitch pswitch-joined Playback channels: Mono Mono: Playback [on] Simple mixer control 'IEC958 Emphasis Bit',0 Capabilities: pswitch pswitch-joined Playback channels: Mono Mono: Playback [on] Simple mixer control 'IEC958 Input Connector',0 Capabilities: enum Items: 'Optical' 'Coaxial' 'Internal' Item0: 'Internal' Simple mixer control 'IEC958 Non-audio Bit',0 Capabilities: pswitch pswitch-joined Playback channels: Mono Mono: Playback [on] Simple mixer control 'IEC958 Output also on ADAT1',0 Capabilities: pswitch pswitch-joined Playback channels: Mono Mono: Playback [on] Simple mixer control 'IEC958 Professional Bit',0 Capabilities: pswitch pswitch-joined Playback channels: Mono Mono: Playback [on] Simple mixer control 'ADAT Lock Status',1 Capabilities: enum Items: 'No Lock' 'Lock' 'Sync' Item0: 'No Lock' Simple mixer control 'ADAT Sync Lock Status',0 Capabilities: enum Items: 'No Lock' 'Lock' 'Sync' Item0: 'No Lock' Simple mixer control 'AutoSync Reference',0 Capabilities: enum Items: 'Word' 'ADAT Sync' 'IEC958' 'None' 'ADAT1' 'ADAT2' 'ADAT3' Item0: 'None' Simple mixer control 'External Rate',0 Capabilities: enum Items: '32000' '44100' '48000' '64000' '88200' '96000' 'None' Item0: 'None' Simple mixer control 'Preferred Sync Reference',0 Capabilities: enum Items: 'Word' 'IEC958' 'ADAT1' 'ADAT Sync' Item0: 'IEC958' Simple mixer control 'SPDIF Lock Status',0 Capabilities: enum Items: 'No Lock' 'Lock' 'Sync' Item0: 'No Lock' Simple mixer control 'SPDIF Sample Rate',0 Capabilities: enum Items: '32000' '44100' '48000' '64000' '88200' '96000' 'None' Item0: 'None' Simple mixer control 'Sample Clock Source',0 Capabilities: enum Items: 'AutoSync' 'Internal 32.0 kHz' 'Internal 44.1 kHz' 'Internal 48.0 kHz' 'Internal 64.0 kHz' 'Internal 88.2 kHz' 'Internal 96.0 kHz' Item0: 'Internal 44.1 kHz' Simple mixer control 'Sample Clock Source Locking',0 Capabilities: pswitch pswitch-joined Playback channels: Mono Mono: Playback [off] Simple mixer control 'System Clock Mode',0 Capabilities: enum Items: 'Master' 'Slave' Item0: 'Master' Simple mixer control 'System Sample Rate',0 Capabilities: volume volume-joined Playback channels: Mono Capture channels: Mono Limits: 0 - 0 Mono: 0 [0%] Simple mixer control 'Word Clock Lock Status',0 Capabilities: enum Items: 'No Lock' 'Lock' 'Sync' Item0: 'No Lock' please do i miss something? thanks rmgls(a)free.fr

2 1

[alsa-devel] Userspace control of HDA port connections
by Andrew Paprocki 21 Dec '07

21 Dec '07

Takashi, I'm wondering if there is any interest in providing a userspace way of modifying the HDA port/mixer input/output mappings? The driver currently uses hard-coded models to define the standard configuration for a given piece of hardware, but this doesn't allow a user to redefine a line-in port as an output port if the chipset has an available unmapped mixer. I'm bringing this up because from what I understand of the ALC883 is that it has 4 mixers, yet on my motherboard there are only 3 ports configured as output by default (6stack-dig). Correct me if I'm wrong, but I should be able to map all of the physical jacks as outputs and then assign each of the mixers to a jack or more than one jack. That would require adding a new model to the driver and/or unloading/reloading the module with a new model string. In a system which has the driver built-in and isn't using modules, this requires a reboot. If there was a userspace way of reconfiguring the jacks (via /proc/asound?) then perhaps even all of the hardware -> model mappings could be moved into a little tool run at boot time which doesn't require a kernel change every time new hardware is introduced. A nice little ncurses tool could even be made to modify port mappings. What do you think? If I'm misunderstanding the capabilities of the chips please let me know. Thanks, -Andrew p.s. I still have yet to test out the multi-card patch. I'll reply to that once I have more info.

2 1

[alsa-devel] [PATCH] fix entries for U24_BE and U24_LE in pcm_formats[] array
by Timur Tabi 21 Dec '07

21 Dec '07

SNDRV_PCM_FORMAT_U24_BE and SNDRV_PCM_FORMAT_U24_LE represent 24-bit samples that are aligned into a 4-byte word, so the most significant byte is always zero. The entries for these two sample formats in the pcm_formats[] array only specified 3 bytes. For SNDRV_PCM_FORMAT_U24_LE, the compiler automatically adds the 4th byte, but for SNDRV_PCM_FORMAT_U24_BE the entry was just wrong. This patch fixes both entries. Signed-off-by: Timur Tabi <timur(a)freescale.com> --- I do not have hardware that supports U24_BE, so I can't test this change. sound/core/pcm_misc.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/core/pcm_misc.c b/sound/core/pcm_misc.c index dd9aa51..077fc0b 100644 --- a/sound/core/pcm_misc.c +++ b/sound/core/pcm_misc.c @@ -71,11 +71,11 @@ static struct pcm_format_data pcm_formats[SNDRV_PCM_FORMAT_LAST+1] = { }, [SNDRV_PCM_FORMAT_U24_LE] = { .width = 24, .phys = 32, .le = 1, .signd = 0, - .silence = { 0x00, 0x00, 0x80 }, + .silence = { 0x00, 0x00, 0x80, 0x00 }, }, [SNDRV_PCM_FORMAT_U24_BE] = { .width = 24, .phys = 32, .le = 0, .signd = 0, - .silence = { 0x80, 0x00, 0x00 }, + .silence = { 0x00, 0x80, 0x00, 0x00 }, }, [SNDRV_PCM_FORMAT_S32_LE] = { .width = 32, .phys = 32, .le = 1, .signd = 1, -- 1.5.2.4

2 1

[alsa-devel] Using dmix/dsnoop/dshare to access individual channels
by Steve Strobel 21 Dec '07

21 Dec '07

I am using a 4-input, 8-output codec (AD1938) in an application similar to a live sound mixing board, where a combination of the input signals get mixed for each output. I can mix four inputs to four outputs with a command like: arecord --file-type raw --channels=4 --format=S32_LE --rate=16000 \ | crosspoint \ | aplay --file-type raw --channels=4 --format=S32_LE --rate=16000 where crosspoint is a simple program that reads from stdin, does some mixing, and outputs to stdout. My next step is to play and record wave files from the various channels, while the crosspoint is running. For example, I might need to play message1.wav to channel 2 and message2.wav to channel 3 while recording channel 1 to message3.wav. I am looking for advice about the best way to accomplish that. It seems like it should be possible using a combination of dmix, snoop, and dshare, as follows: - Use dsnoop to split the 4-channel input to the crosspoint and another virtual sound input, call it "A". - Use dshare to split "A" into four mono sources. Then can use arecord normally to capture wave files. - Use dmix and possibly dshare to similarly let the crosspoint continue to use the multi-channel output while also providing a mono sound device for each channel that I can use with aplay. Am I on the right track, or would I be better off adding functionality to the crosspoint application to read and write wave files? Thanks for any suggestions. Steve --- Steve Strobel Link Communications, Inc. 1035 Cerise Rd Billings, MT 59101-7378 (406) 245-5002 ext 102 (406) 245-4889 (fax) WWW: http://www.link-comm.com MailTo:steve.strobel@link-comm.com

3 3

Re: [alsa-devel] snd-hda-intel support for SPDIF-in wiht vt1708 card?
by forumjunk＠comcast.net 20 Dec '07

20 Dec '07

For VIA platforms, to avoid the driver compile error in pci.h, reconfigure your kernel to remove SMP support, and set the architecture type to PC-compatible. (you already know this, I'm sure): Recompile the kernel (as a paranoid, I always trash /lib/modules/<kernel_version> before making modules_install). Install the kernel, of course, and reconfigure your boot loader and/or initrd and reboot. There are still several fixes that need to be made to get all of this to compile cleanly, but I haven't got the permanent fixes nailed down yet. I'm almost positive that these are alsa-driver configure errors or omissions. I can't (yet) find a kernel config that will avoid them. The fixes below are harmless, and they will allow you to get the driver compiled. Add this definition to the top section of acore/memory_wrapper.c after the line that reads #include <linux/version.h> #define VMALLOC_VMADDR(x) ((unsigned long)(x)) Change these lines (45 and 46 or close to that) of acore/memory_wrapper.c from: pmd = pmd_offset(pgd, lpage); pte = pte_offset(pmd, lpage); to pmd = pmd_offset((pud_t *)pgd, lpage); pte = pte_offset_kernel(pmd, lpage); The driver will then compile cleanly (at least with no errors or warnings relating to any of these changes) I will work more as time allows to find or create configure tests to make sure that the correct versions of these functions get included or patched.

3 2

[alsa-devel] [PATCH 0/2] ASoC drivers for the Freescale MPC8610 SoC
by Timur Tabi 20 Dec '07

20 Dec '07

These patches add ALSA SoC device drivers for the Freescale MPC8610 SoC and the MPC8610-HPCD reference board. The first patch updates some files in arch/powerpc and booting-without-of.txt. The second patch adds the new audio driver files to sound/soc. Both must be applied in order to avoid a build break.

1 2