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

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

22 Apr '08

On Fri, Apr 18, 2008 at 11:26:28PM +0300, Jarkko Nikula wrote: > No any show stopper either but I just started to think about gpiolib if > AIC3x GPIOs are used as a GPIO. I agree in general and thought about alternatives as well, but in this case, it turns out to be a thing the aic3x driver is responsible to as the registers in questions are purely in its scope. So the idea is to set up the GPIO's functions via alsa controls and handle its events in some board-related code as this is really not abstractable. One could, however, do this setup in machine-related code within the asoc environment. My changes don't cast any problems on the existing implementation either, so I would suggest to just take this patch until someone comes up with a more suitable solution :) Best regards, Daniel

4 11

[alsa-devel] [PATCH] ALSA: Fix capturing for envy1724ht based "audiophile 192"
by Karsten Wiese 22 Apr '08

22 Apr '08

The 1st hunk changes snd_ice1712_gpio_write_bits() to not affect the gpio's mask register. Lets gpio writers that are unaware of a changed mask register successfully write the gpio. The 2nd and 3rd hunks toggle "chip reset" and "eeprom based setup" sequence so "chip reset" becomes first. Increasement of the "chip reset" related timeout leads to correctly read eeprom's contents here. Also corrects some arguments in calls to snd_ice1712_gpio_write_bits() from ap192_set_rate_val(). Signed-off-by: Karsten Wiese <fzu(a)wemgehoertderstaat.de> --- Hi, patch might hamper cards that actually relied on snd_ice1712_gpio_write_bits() setting the gpio's mask register. Cscope tells me terratec ews and m-audio rev51 are might be candidates. I guess they are ok ;-) regards, Karsten diff -pur alsa.hg/alsa-kernel/pci/ice1712/ice1712.h fixed/alsa-kernel/pci/ice1712/ice1712.h --- alsa.hg/alsa-kernel/pci/ice1712/ice1712.h 2008-03-20 12:25:01.000000000 +0100 +++ fixed/alsa-kernel/pci/ice1712/ice1712.h 2008-04-19 23:21:31.000000000 +0200 @@ -438,10 +438,14 @@ int snd_ice1712_gpio_put(struct snd_kcon static inline void snd_ice1712_gpio_write_bits(struct snd_ice1712 *ice, unsigned int mask, unsigned int bits) { + unsigned val; + ice->gpio.direction |= mask; snd_ice1712_gpio_set_dir(ice, ice->gpio.direction); - snd_ice1712_gpio_set_mask(ice, ~mask); - snd_ice1712_gpio_write(ice, mask & bits); + val = snd_ice1712_gpio_read(ice); + val &= ~mask; + val |= mask & bits; + snd_ice1712_gpio_write(ice, val); } static inline int snd_ice1712_gpio_read_bits(struct snd_ice1712 *ice, diff -pur alsa.hg/alsa-kernel/pci/ice1712/ice1724.c fixed/alsa-kernel/pci/ice1712/ice1724.c --- alsa.hg/alsa-kernel/pci/ice1712/ice1724.c 2008-03-20 12:25:01.000000000 +0100 +++ fixed/alsa-kernel/pci/ice1712/ice1724.c 2008-04-19 23:07:29.000000000 +0200 @@ -2045,12 +2045,16 @@ static int __devinit snd_vt1724_read_eep -static int __devinit snd_vt1724_chip_init(struct snd_ice1712 *ice) +static void __devinit snd_vt1724_chip_reset(struct snd_ice1712 *ice) { outb(VT1724_RESET , ICEREG1724(ice, CONTROL)); - udelay(200); + msleep(10); outb(0, ICEREG1724(ice, CONTROL)); - udelay(200); + msleep(10); +} + +static int __devinit snd_vt1724_chip_init(struct snd_ice1712 *ice) +{ outb(ice->eeprom.data[ICE_EEP2_SYSCONF], ICEREG1724(ice, SYS_CFG)); outb(ice->eeprom.data[ICE_EEP2_ACLINK], ICEREG1724(ice, AC97_CFG)); outb(ice->eeprom.data[ICE_EEP2_I2S], ICEREG1724(ice, I2S_FEATURES)); @@ -2223,6 +2227,7 @@ static int __devinit snd_vt1724_create(s ice->irq = pci->irq; + snd_vt1724_chip_reset(ice); if (snd_vt1724_read_eeprom(ice, modelname) < 0) { snd_vt1724_free(ice); return -EIO; diff -pur alsa.hg/alsa-kernel/pci/ice1712/revo.c fixed/alsa-kernel/pci/ice1712/revo.c --- alsa.hg/alsa-kernel/pci/ice1712/revo.c 2008-03-17 09:25:02.000000000 +0100 +++ fixed/alsa-kernel/pci/ice1712/revo.c 2008-04-19 23:12:33.000000000 +0200 @@ -327,7 +327,7 @@ static void ap192_set_rate_val(struct sn revo_set_rate_val(ak, rate); /* reset CKS */ - snd_ice1712_gpio_write_bits(ice, 1 << 8, rate > 96000 ? 1 : 0); + snd_ice1712_gpio_write_bits(ice, 1 << 8, rate > 96000 ? 1 << 8 : 0); /* reset DFS pins of AK5385A for ADC, too */ if (rate > 96000) dfs = 2; @@ -338,7 +338,7 @@ static void ap192_set_rate_val(struct sn snd_ice1712_gpio_write_bits(ice, 3 << 9, dfs << 9); /* reset ADC */ snd_ice1712_gpio_write_bits(ice, 1 << 11, 0); - snd_ice1712_gpio_write_bits(ice, 1 << 11, 1); + snd_ice1712_gpio_write_bits(ice, 1 << 11, 1 << 11); } static const struct snd_akm4xxx_dac_channel ap192_dac[] = {

2 6

Re: [alsa-devel] snd_pcm_ops - .copy
by Harsha priya gupta 22 Apr '08

22 Apr '08

On Tue, Apr 22, 2008 at 8:07 AM, Harsha priya gupta <harshapriya(a)gmail.com> wrote: > I am not using the mmap method. How can i make sure that everytime a user > buffer is passed to driver, my copy function would be called? > > > On Mon, Apr 21, 2008 at 9:30 PM, Takashi Iwai <tiwai(a)suse.de> wrote: > > > At Mon, 21 Apr 2008 19:27:45 +0530, > > Harsha priya gupta wrote: > > > > > > 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 > > > > Do you use a mmap method? If so, the copy callback won't be called. > > The copy callback is only for copying the data from the user-space > > buffer to the driver buffer, which is skipped via mmap. > > > > > > Takashi > > > > > > -- > -Harsha -- -Harsha

1 0

[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