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

[alsa-devel] Alsa Callbacks and C++ classes
by Reuben Martin 22 Apr '08

22 Apr '08

Hello all, I have an AES32 sound card that I am trying to write a general control interface for using qt4. I'm wanting to register callbacks so that the interface will reflect changes made by other apps. Now I'm not entirely up to speed on the API, but from what I can gather, the callback can be registered to call a regular function, or to change a public class variable. Since I decided to use qt4, everything is in classes. Is there any way to have the callback trigger a public class function? I guess I don't understand why you would want to use a public variable instead. Wouldn't you have to set up a means within the class to continually pole the variable to see if it has been changed? Or can the option to call a regular function be used to call a public class function as well? Go easy on me. I'm not much of an experienced programmer. More of a hack who can kinda get by with his sloppy programming most of the time. Thanks, -Reuben

3 3

[alsa-devel] Buffering issues
by Lennart Poettering 22 Apr '08

22 Apr '08

Heya! As you might now I am currently working on something called "glitch-free playback model" for PulseAudio: http://0pointer.de/blog/projects/pulse-glitch-free.html One of the central ideas is to schedule audio via timer interrupts, no longer via period-based interrupts. To acomplish this I need to be able to estimate in advance how long (in time) it will take until the playback buffer runs empty at a certain point. Then I can set myself a system timer to wakeup a certain margin earlier than this and fill the buffer up again. That way I minimize wakeups and should always have enough safety margin to never get an xrun. Now, the way I implemented this right now is: in each iteration of my playback loop I first fill up the playback buffer completely if it is not fully filled up yet. After that I obviously can go to sleep for the time it takes to play buffer_size samples minus some safety margin, which i set to 20ms. Apparently this is actually not as obvious as I thought. This works fine on many soundcards but it apparently doesn't work on USB hardware. There, ALSA detects a buffer underrun much earlier than when my timer elapses. My loop wakes up due to activity on the ALSA fd, not because of the timer. My code then goes and asks _avail_update() for the free space in the buffer and sees that the full buffer is available, thus assuming a xrun happened. This will cause PA to double the safety margin and do some other things to make sure an XRUN doesn't happen the next time again. So, how do I properly estimate how long the filled up buffer will take to play? Or to word it differently: how do I properly estimate how much time will pass until an XRUN would occur? [My interpretation of what's going on here with lots of guessing how things work is this: the buffer exposed by ALSA is merely a send buffer and just one of the buffers involved before the data actually reaches the speakers. ALSA just takes the data out of this buffer and sends it to the device via USB block-by-block. Thus the send buffer maintained by ALSA is much quicker empty than the audio data is actually played. And Boom! -- If that should actually be the case then I'd like to request an API that allows me to query an upper limit for how much buffering/latency actually happens after the audio data left the ALSA buffer. I could then use this an subtract it from my time to sleep.] Thanks, Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4

1 0

[alsa-devel] snd_pcm_ops - .copy
by Harsha priya gupta 21 Apr '08

21 Apr '08

Hi, I am trying to implement the .copy function of playack_ops in my driver. But when I try playing an mp3 file, my .copy's function code path was executing. Suddenly I do not see that function being called. Can anyone help me understand when the following code path will be executed snd_pcm_lib_write_transfer substream->ops->copy -Harsha

2 1

[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