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

[alsa-devel] Flash Plugin & IO Plug: Async interface not implemented?
by Alexander Indenbaum 21 Apr '08

21 Apr '08

Hello, I'm trying to integrate Firefox Flash plugin with ASLA IO plug driver for proprietary hardware. I've found out that Flash Plugin ASLA client side (sources could be found at http://labs.adobe.com/wiki/index.php/Flash_Player:Additional_Interface_Supp…) is incompatible with IO Plug. The reason is that during initialization Flash Plugin calls snd_async_add_pcm_handler() which always return -ENOSYS out of snd_pcm_ioplug_async(). This error causes Flash Plugin ALSA client code to fail. Is there a good reason why snd_pcm_ioplug_async() unconditionally return -ENOSYS? Is it possible to implement IO Plug async interface? Thank you for your help, Alexander Indenbaum

2 1

[alsa-devel] How to choose output channels for AD1386A sound?
by Ihar Hrachyshka 21 Apr '08

21 Apr '08

Hello! I build my BF533-EZKIT-based board (Blackfin processor development board) sound system on AD1386A sound. I use blackfin.uclinux.org distribution for it. One of my board's function is to play three different stereo sound streams simultaneously on it. What I done is choosing for AD1386 '3 stereos' option. After loading the kernel, my software is able to open pcm 3 times and plays sound properly, with no glitches or smth. The only missed functionality is that I can't specify the needed subdevice I want to play a stream on. I should have the possibility to play, f.e., mplayer stream on the 3rd stereo output while the 1st and the 2nd are not used. How can I do it? Also that would be great if I can optionally play the same stream on all the outputs. If I'm not wrong, this can be made through asound.conf settings though I can't figer out what are the right values. If I can choose next used output through kernel interface (kobject value or smth) then please tell me where should I look into. Here are some info (line-in playing on the 1st subdevice): root:~> aplay -l **** List of PLAYBACK Hardware Devices **** card 0: ad1836 [ADI ad1836], device 0: AD1836_PCM [AD1836_PCM] Subdevices: 2/3 Subdevice #0: subdevice #0 Subdevice #1: subdevice #1 Subdevice #2: subdevice #2 root:~> cat /proc/asound/devices 0: [ 0] : control 16: [ 0- 0]: digital audio playback 24: [ 0- 0]: digital audio capture 33: : timer root:~> cat /proc/asound/pcm 00-00: AD1836_PCM : AD1836_PCM : playback 3 : capture 1 root:~> cat /proc/asound/cards 0 [ad1836 ]: AD1836 - ADI ad1836 ADI ad1836 at PF4 SPORT0 rx/tx dma 1/2 err irq 10 root:~> cat /proc/asound/ad1836/registers DAC_CTRL_1 0x0000 DAC_CTRL_2 0x1000 DAC_VOL_1L 0x23ff DAC_VOL_1R 0x33ff DAC_VOL_2L 0x43fa DAC_VOL_2R 0x53fa DAC_VOL_3L 0x63fa DAC_VOL_3R 0x73fa ADC_PEAK_1L 0xffff -63 dBFS ADC_PEAK_1R 0xffff -63 dBFS ADC_PEAK_2L 0xffff -63 dBFS ADC_PEAK_2R 0xffff -63 dBFS ADC_CTRL_1 0xc000 ADC_CTRL_2 0xd180 ADC_CTRL_3 0xe03a root:~> cat /proc/asound/ad1836/pcm0p/info card: 0 device: 0 subdevice: 0 stream: PLAYBACK id: AD1836_PCM name: AD1836_PCM subname: subdevice #0 class: 0 subclass: 0 subdevices_count: 3 subdevices_avail: 2 root:~> ls /proc/asound/ad1836/pcm0p/ info oss sub0 sub1 sub2 xrun_debug root:~> cat /proc/asound/ad1836/pcm0p/sub0/status state: RUNNING trigger_time: 1208611073.963748000 tstamp : 1208611991.506408000 delay : 6441 avail : 1751 avail_max : 6188 ----- hw_ptr : 44035799 appl_ptr : 44042240 root:~> cat /proc/asound/ad1836/pcm0p/sub1/status closed root:~> cat /proc/asound/ad1836/pcm0p/sub2/status closed Thanks for help.

2 3

[alsa-devel] [PATCH] speaker-test.c - fix sine generator on big-endian archs
by Giuliano Pochini 21 Apr '08

21 Apr '08

speaker-test doesn't work well when you choose a little-endian format on a big-endian processor, or the opposite. Yes, I know about plughw:, but for debugging purposes it may not be an option. The following patch add proper support for S32 and S16 support for but LE and BE processors: - The "if (bits-per-sample)" construct was replaced by case (format). - Support for S16_BE, S32_BE formats was added. - S16_LE and S32_LE were made compatible with big-endian processors. - NB: The pink noise generator wasn't changed (I'll do if this patch is OK). --- speaker-test/speaker-test.c__orig 2008-04-19 23:01:22.000000000 +0200 +++ speaker-test/speaker-test.c 2008-04-19 23:29:45.000000000 +0200 @@ -139,7 +139,6 @@ static void generate_sine(uint8_t *frame int16_t *samp16 = (int16_t*) frames; int32_t *samp32 = (int32_t*) frames; float *samp_f = (float*) frames; - int sample_size_bits = snd_pcm_format_width(format); while (count-- > 0) { //res = sin((phase * 2 * M_PI) / max_phase - M_PI) * 32767; @@ -154,26 +153,43 @@ static void generate_sine(uint8_t *frame //ires = 0; for(chn=0;chn<channels;chn++) { - if (sample_size_bits == 8) { + switch (format) { + case SND_PCM_FORMAT_S8: if (chn==channel) { res = (sin((phase * 2 * M_PI) / max_phase - M_PI)) * 0x03fffffff; /* Don't use MAX volume */ ires = res; - *samp8++ = ires >> 24; - //*samp8++ = 0x12; + *samp8++ = ires >> 24; } else { - *samp8++ = 0; + *samp8++ = 0; } - } else if (sample_size_bits == 16) { + break; + case SND_PCM_FORMAT_S16_LE: if (chn==channel) { res = (sin((phase * 2 * M_PI) / max_phase - M_PI)) * 0x03fffffff; /* Don't use MAX volume */ ires = res; - *samp16++ = ires >>16; - //*samp16++ = 0x1234; +#if __BYTE_ORDER == __LITTLE_ENDIAN + *samp16++ = ires >> 16; +#elif __BYTE_ORDER == __BIG_ENDIAN + *samp16++ = bswap_16(ires >> 16); +#endif } else { - //*samp16++ = (ires >>16)+1; - *samp16++ = 0; + *samp16++ = 0; } - } else if ((sample_size_bits == 32) && (format == SND_PCM_FORMAT_FLOAT_LE)) { + break; + case SND_PCM_FORMAT_S16_BE: + if (chn==channel) { + res = (sin((phase * 2 * M_PI) / max_phase - M_PI)) * 0x03fffffff; /* Don't use MAX volume */ + ires = res; +#if __BYTE_ORDER == __BIG_ENDIAN + *samp16++ = ires >> 16; +#elif __BYTE_ORDER == __LITTLE_ENDIAN + *samp16++ = bswap_16(ires >> 16); +#endif + } else { + *samp16++ = 0; + } + break; + case SND_PCM_FORMAT_FLOAT_LE: if (chn==channel) { res = (sin((phase * 2 * M_PI) / max_phase - M_PI)) * 0.75 ; /* Don't use MAX volume */ fres = res; @@ -185,18 +201,35 @@ static void generate_sine(uint8_t *frame //*samp32++ = ires; *samp_f++ = 0.0; } - } else if ((sample_size_bits == 32) && (format != SND_PCM_FORMAT_FLOAT_LE)) { + break; + case SND_PCM_FORMAT_S32_LE: if (chn==channel) { res = (sin((phase * 2 * M_PI) / max_phase - M_PI)) * 0x03fffffff; /* Don't use MAX volume */ ires = res; - *samp32++ = ires; - //*samp32++ = 0xF2345678; - //printf("res=%lf, ires=%d 0x%x, samp32=0x%x\n",res,ires, ires, samp32[-1]); +#if __BYTE_ORDER == __LITTLE_ENDIAN + *samp32++ = ires; +#elif __BYTE_ORDER == __BIG_ENDIAN + *samp32++ = bswap_32(ires); +#endif } else { - //*samp32++ = ires+0x10000; - //*samp32++ = ires; - *samp32++ = 0; + *samp32++ = 0; } + break; + case SND_PCM_FORMAT_S32_BE: + if (chn==channel) { + res = (sin((phase * 2 * M_PI) / max_phase - M_PI)) * 0x03fffffff; /* Don't use MAX volume */ + ires = res; +#if __BYTE_ORDER == __BIG_ENDIAN + *samp32++ = ires; +#elif __BYTE_ORDER == __LITTLE_ENDIAN + *samp32++ = bswap_32(ires); +#endif + } else { + *samp32++ = 0; + } + break; + default: + ; } } -- Giuliano.

2 1

[alsa-devel] Monotonic timestamps
by Lennart Poettering 21 Apr '08

21 Apr '08

Hey! I saw that ALSA 1.0.16 claims to support monotonic timestamps. I couldn't figure out however, how they are supposed to work. From the sources I only could figure out that they are enabled if a) the libc knows CLOCK_MONOTONIC a) the kernel supports CLOCK_MONOTONIC, b) the ALSA kernel code support timestamps this way. That's at least how I read this code from pcm_hw.c: <snip> #if defined(HAVE_CLOCK_GETTIME) && defined(CLOCK_MONOTONIC) if (SNDRV_PROTOCOL_VERSION(2, 0, 9) <= ver) { struct timespec timespec; if (clock_gettime(CLOCK_MONOTONIC, &timespec) == 0) { int on = SNDRV_PCM_TSTAMP_TYPE_MONOTONIC; if (ioctl(fd, SNDRV_PCM_IOCTL_TTSTAMP, &on) < 0) { ret = -errno; SNDMSG("TTSTAMP failed\n"); return ret; } monotonic = 1; } } #endif else if (SNDRV_PROTOCOL_VERSION(2, 0, 5) <= ver) { int on = 1; if (ioctl(fd, SNDRV_PCM_IOCTL_TSTAMP, &on) < 0) { ret = -errno; SNDMSG("TSTAMP failed\n"); return ret; } } </snip> The problem with this is that there seems to be no way to determine from an application if monotonic timestamps are enabled in an snd_pcm_t or not, ALSA just switches over to them, making the timestamps relatively useless, because we cannot reliable relate them to timestamps we query from the kernel ourselves -- because we just don't know if we need to use CLOCK_MONOTONIC or CLOCK_REALTIME. I find it very strange that ALSA just switches to monotonic timestamps just like that, anyway. Programs written for wallclack timestamps will break if they run on a system where ALSA uses monotonic timestamps! There's a function missing that enables monotonic timestamps explicitly, or at least one that can be used to query if they are monotonic or not. Could anybody please explain the difference between status->tstamp and status->trigger_tstamp for me, please? The doxygen docs are bit too terse on this, I fear. Oh, and the code I pasted above will not compile if the #ifdef check fails, because of the "else". The "else" should be moved inside of #ifddef block. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4

3 8

[alsa-devel] snd_hda_intel locking up on VIA CX700M2 with VT1708A codec
by Simon Farnsworth 21 Apr '08

21 Apr '08

Hello, I'm trying to work out what's going wrong with the HDA controller in our VIA CX700M2 board; there's a full bug report at https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3910, but briefly, I'm seeing it lock up and refuse to DMA after long enough transferring audio data. Does anyone have any ideas that would help me track down this lockup and find a workaround? -- Thanks, Simon Farnsworth

1 2

[alsa-devel] [PATCH] asoc tlv320aic33: skip usage of PLL in some cases
by Daniel Mack 19 Apr '08

19 Apr '08

This patch makes the tlv320aic33 driver skip the initialisation of the PLL in case the sysclk is 256 * samplerate. Had to do some minor refactoring too - the check whether a sysclk set by set_sysclk() is valid is now done in set_hw_params(). Signed-off-by: Daniel Mack <daniel(a)caiaq.de>

3 13

[alsa-devel] Patchmix-style application for EMU cards
by Camilo Polymeris 18 Apr '08

18 Apr '08

Hello I am working on a graphical mixing/routing application for the Emu10k series of semi-pro soundcards, but I am having trouble figuring out the routing mechanism of the driver, specially the "Multichannel PCM" part. Is there any technical documentation on this card I could read (I haven't found any), or maybe the driver developer can help me out? Thanks, Camilo.

2 2

[alsa-devel] [PATCH] asoc tlv320aic3x: add GPIO support
by Daniel Mack 18 Apr '08

18 Apr '08

This patch adds support for AIC3x GPIO lines. They can be configured for many possible functions as well as be driven manually. I also introduced i2c read functionality since the GPIO state register has to be read from hardware every time and can not be served from cache. Signed-off-by: Daniel Mack <daniel(a)caiaq.de>

1 0

[alsa-devel] Alsa Driver on Coldfire
by Simon Dunn 18 Apr '08

18 Apr '08

Hi I've been given the job of writing a sound card driver using the alsa architecture for a development platform that uses a coldfire chip. The first thing I came across was a chunky 'if !M68K' in sound/Kconfig, which excludes all the alsa components. I can't find any reason for this in the mailing list archives or on the web in general, so I'm wondering if anybody knows why the M68K architecture is excluded? Cheers Simon -- Simon Dunn, Software Engineer MPC Data Limited e-mail: sdunn(a)mpc-data.co.uk web: www.mpc-data.co.uk tel: +44 (0) 1225 710600 fax: +44 (0) 1225 710601 ddi: +44 (0) 1225 710631 MPC Data Limited is a company registered in England and Wales with company number 05507446 Registered Address: County Gate, County Way, Trowbridge, Wiltshire, BA14 7FJ VAT no: 850625238 The information in this email and in the attached documents is confidential and may be legally privileged. Any unauthorized review, copying, disclosure or distribution is prohibited and may be unlawful. It is intended solely for the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. When addressed to our clients any opinions or advice contained in this email is subject to the terms and conditions expressed in the governing contract.

3 4

[alsa-devel] [PATCH 001c/001] snd-powermac: more older kernel compatibility
by Risto Suominen 18 Apr '08

18 Apr '08

2008/4/17, Takashi Iwai <tiwai(a)suse.de>: > > The hack isn't definitely for the latest upstream, so if this is > needed, rather define in each *.c in alsa-driver/ppc please. > Now it's done in ppc/*.patch. Risto

2 1