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

[alsa-devel] [PATCH 0/5] ASoC: tlv320dac33: Adding new FIFO mode
by Peter Ujfalusi 04 Jan '10

04 Jan '10

Hello, the following series adds new FIFO operating mode to the tlv320dac33 codec driver. To be able to add new FIFO mode the code has to be restructured in order to keep it readable after the new mode is added. Since both of the support FIFO mode in the driver needs the codec to be the master, an additional check is added to avoid misconfiguration. --- Peter Ujfalusi (5): ASoC: tlv320dac33: Change nsample switch to FIFO mode enum ASoC: tlv320dac33: Introduce prefill and playback state handlers ASoC: tlv320dac33: Clean up the hardware configuration code ASoC: tlv320dac33: Add new FIFO mode: mode 7 ASoC: tlv320dac33: Safety check for codec slave mode sound/soc/codecs/tlv320dac33.c | 190 ++++++++++++++++++++++++++++++++-------- 1 files changed, 153 insertions(+), 37 deletions(-)

2 8

[alsa-devel] How to compile 1.0.22 drivers with 2.6.33-rc?
by Elimar Riesebieter 31 Dec '09

31 Dec '09

Hi all, to built alsa-driver 1.0.22.1 against 2.6.33-rc2 I had to copy files of kernels's include/generated to include/linux. Is there a more elegant way to improve that? I want to prepare a Debian upload. So users which are running 2.6.33 can't compile the 1.0.22 drivers without manipulating the kernel built dir. Any hints? Thanks Elimar -- On the keyboard of life you have always to keep a finger at the escape key;-)

1 0

[alsa-devel] [PATCH v2] soc-cache: cleanup training whitespace and coding style
by Barry Song 31 Dec '09

31 Dec '09

Signed-off-by: Barry Song <21cnbao(a)gmail.com> --- sound/soc/soc-cache.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/sound/soc/soc-cache.c b/sound/soc/soc-cache.c index d2505e8..02c2357 100644 --- a/sound/soc/soc-cache.c +++ b/sound/soc/soc-cache.c @@ -182,7 +182,7 @@ static struct { { .addr_bits = 7, .data_bits = 9, .write = snd_soc_7_9_write, .read = snd_soc_7_9_read, - .spi_write = snd_soc_7_9_spi_write + .spi_write = snd_soc_7_9_spi_write, }, { .addr_bits = 8, .data_bits = 8, -- 1.5.6.3

2 1

Re: [alsa-devel] hw_ptr accuracy with intel8x0 -> PulseAudio issue
by Raymond Yau 31 Dec '09

31 Dec '09

2009/12/4 pl bossart <bossart.nospam(a)gmail.com> > Hi Raymond, > comments below. > - PL > > On Wed, Dec 2, 2009 at 8:26 PM, Raymond Yau <superquad.vortex2(a)gmail.com> > wrote: > > 1. D: alsa-util.c: Trying front:0 with SND_PCM_NO_AUTO_FORMAT ... > > 2. D: alsa-util.c: Managed to open front:0 > > 3. D: alsa-util.c: Maximum hw buffer size is 371 ms > > 4. D: alsa-util.c: Set buffer size first (to 4408 samples), period size > > second (to 1102 samples) > > > > What is the purpose of these buffer-size and period size during the > probing > > phase ? > > The PA server seem use different values > > This is a red herring, PulseAudio tries to open multiple profiles and > finds out which ones make sense. You want to look at the result below > which is the final configuration. > > > 1. I: sink.c: Created sink 0 > "alsa_output.pci-0000_00_1e.2.analog-stereo" > > with sample spec s16le 2ch 44100Hz and channel map > front-left,front-right > > 2. I: sink.c: alsa.resolution_bits = "16" > > 3. I: sink.c: device.api = "alsa" > > 4. I: sink.c: device.class = "sound" > > 5. I: sink.c: alsa.class = "generic" > > 6. I: sink.c: alsa.subclass = "generic-mix" > > 7. I: sink.c: alsa.name = "Intel ICH6" > > 8. I: sink.c: alsa.id = "Intel ICH" > > 9. I: sink.c: alsa.subdevice = "0" > > 10. I: sink.c: alsa.subdevice_name = "subdevice #0" > > 11. I: sink.c: alsa.device = "0" > > 12. I: sink.c: alsa.card = "0" > > 13. I: sink.c: alsa.card_name = "Intel ICH6" > > 14. I: sink.c: alsa.long_card_name = "Intel ICH6 with AD1981B at > irq > > 22" > > 15. I: sink.c: alsa.driver_name = "snd_intel8x0" > > 16. I: sink.c: device.bus_path = "pci-0000:00:1e.2" > > 17. I: sink.c: sysfs.path = > > "/devices/pci0000:00/0000:00:1e.2/sound/card0" > > 18. I: sink.c: device.bus = "pci" > > 19. I: sink.c: device.vendor.id = "8086" > > 20. I: sink.c: device.vendor.name = "Intel Corporation" > > 21. I: sink.c: device.product.id = "266e" > > 22. I: sink.c: device.product.name = "82801FB/FBM/FR/FW/FRW (ICH6 > > Family) AC'97 Audio Controller" > > 23. I: sink.c: device.form_factor = "internal" > > 24. I: sink.c: hal.udi = > > "/org/freedesktop/Hal/devices/pci_8086_266e_sound_card_0" > > 25. I: sink.c: hal.product = "Intel ICH6 with AD1981B Sound Card" > > 26. I: sink.c: hal.card_id = "Intel ICH6 with AD1981B" > > 27. I: sink.c: device.string = "front:0" > > 28. I: sink.c: device.buffering.buffer_size = "65536" > > 29. I: sink.c: device.buffering.fragment_size = "65536" > > 30. I: sink.c: device.access_mode = "mmap+timer" > > 31. I: sink.c: device.profile.name = "analog-stereo" > > 32. I: sink.c: device.profile.description = "Analog Stereo" > > 33. I: sink.c: device.description = "Internal Audio Analog Stereo" > > 34. I: sink.c: alsa.mixer_name = "Analog Devices AD1981B" > > 35. I: sink.c: alsa.components = "AC97a:41445374" > > 36. I: sink.c: module-udev-detect.discovered = "1" > > 37. I: sink.c: device.icon_name = "audio-card-pci" > > > intel8x0 does not has hdmi , it seem PA hardcode hdmi for all sound cards > > instead of using namehint for playback device > > Yes, PA will try all possible profiles. Not that smart but unrelated > to my problem. > > > > Is it possible to add timestamp in alsa-sink.c: Wrote 31792 bytes (of > > possible 31792 bytes) statement for debugging > > Not sure why this is needed. In that case the driver reports 7948 > frames are available, which translates to 31792 bytes. > The problem shows in the next call to snd_pcm_avail down to the kernel > level, PA only uses the misleading information reported by the driver. > > 17. hwptr 24351 buffer 16384 appl 24332, avail=16403 appl pointer is behind hwprtr ( underrun ) , need timestamp to find out whether PA is unable to write audio data in time since > 13. D: alsa-sink.c: Not filling up, because too early. > 14. D: alsa-sink.c: Wakeup from ALSA! > 15. D: alsa-sink.c: Loop > 16. D: alsa-sink.c: Buffer time: 371 ms; Sleep time: 351 ms; Process > time: 20 ms did it adjust the sleeping time when it think too early ? > > > 1. D: alsa-sink.c: Loop > > 2. D: alsa-sink.c: Buffer time: 371 ms; Sleep time: 351 ms; Process > time: > > 20 ms > > 3. hwptr 7948 buffer 16384 appl 16384, avail=7948 > > 4. D: alsa-sink.c: avail: 31792 (samples 7948) > > 5. D: alsa-sink.c: 191.29 ms left to play; inc threshold = 0.00 ms; dec > > threshold = 100.00 ms > > 6. D: alsa-sink.c: Filling up > > 7. hwptr 7948 buffer 16384 appl 16384, avail=7948 > > 8. hwptr 7948 buffer 16384 appl 16384, avail=7948 > > 9. D: alsa-sink.c: Wrote 31792 bytes (of possible 31792 bytes) > > 10. hwptr 7960 buffer 16384 appl 24332, avail=12 > > 11. D: alsa-sink.c: avail: 48 (samples 12) > > 12. D: alsa-sink.c: 371.25 ms left to play; inc threshold = 0.00 ms; > dec > > threshold = 100.00 ms > > 13. D: alsa-sink.c: Not filling up, because too early. > > 14. D: alsa-sink.c: Wakeup from ALSA! > > 15. D: alsa-sink.c: Loop > > 16. D: alsa-sink.c: Buffer time: 371 ms; Sleep time: 351 ms; Process > > time: 20 ms > > 17. hwptr 24351 buffer 16384 appl 24332, avail=16403 > > 18. E: alsa-util.c: avail 16403 delay -19 > > 19. D: alsa-sink.c: avail: 65536 (samples 16384) > > 20. D: alsa-sink.c: 0.00 ms left to play; inc threshold = 0.00 ms; dec > > threshold = 100.00 ms > > 21. D: alsa-sink.c: Filling up >

4 16

[alsa-devel] [PATCH 1/3] ASoC: fsi: Add over_period flag to prevent the misunderstanding
by Kuninori Morimoto 30 Dec '09

30 Dec '09

Signed-off-by: Kuninori Morimoto <morimoto.kuninori(a)renesas.com> --- sound/soc/sh/fsi.c | 20 ++++++++++++-------- 1 files changed, 12 insertions(+), 8 deletions(-) diff --git a/sound/soc/sh/fsi.c b/sound/soc/sh/fsi.c index 497c5e0..4337afc 100644 --- a/sound/soc/sh/fsi.c +++ b/sound/soc/sh/fsi.c @@ -373,14 +373,16 @@ static int fsi_data_push(struct fsi_priv *fsi) int fifo_free; int width; u8 *start; - int i; + int i, over_period; if (!fsi || !fsi->substream || !fsi->substream->runtime) return -EINVAL; - runtime = fsi->substream->runtime; + over_period = 0; + substream = fsi->substream; + runtime = substream->runtime; /* FSI FIFO has limit. * So, this driver can not send periods data at a time @@ -388,7 +390,7 @@ static int fsi_data_push(struct fsi_priv *fsi) if (fsi->byte_offset >= fsi->period_len * (fsi->periods + 1)) { - substream = fsi->substream; + over_period = 1; fsi->periods = (fsi->periods + 1) % runtime->periods; if (0 == fsi->periods) @@ -429,7 +431,7 @@ static int fsi_data_push(struct fsi_priv *fsi) fsi_irq_enable(fsi, 1); - if (substream) + if (over_period) snd_pcm_period_elapsed(substream); return 0; @@ -443,14 +445,16 @@ static int fsi_data_pop(struct fsi_priv *fsi) int fifo_fill; int width; u8 *start; - int i; + int i, over_period; if (!fsi || !fsi->substream || !fsi->substream->runtime) return -EINVAL; - runtime = fsi->substream->runtime; + over_period = 0; + substream = fsi->substream; + runtime = substream->runtime; /* FSI FIFO has limit. * So, this driver can not send periods data at a time @@ -458,7 +462,7 @@ static int fsi_data_pop(struct fsi_priv *fsi) if (fsi->byte_offset >= fsi->period_len * (fsi->periods + 1)) { - substream = fsi->substream; + over_period = 1; fsi->periods = (fsi->periods + 1) % runtime->periods; if (0 == fsi->periods) @@ -498,7 +502,7 @@ static int fsi_data_pop(struct fsi_priv *fsi) fsi_irq_enable(fsi, 0); - if (substream) + if (over_period) snd_pcm_period_elapsed(substream); return 0; -- 1.6.3.3

2 1

[alsa-devel] [PATCH 0/3] ad1836/ad1938: PM and typo fix/cleanup
by Barry Song 30 Dec '09

30 Dec '09

Hi Mark, The following 3 patches fix/cleanup PM and typo of ad1836/ad1938 codec driver: 1. ad1836: reset and restore clock control mode in suspend/resume entry 2. ad1938: fix typo, rename mask to rx_mask for ad1938_set_tdm_slot 3. ad1938:let soc-core dapm handle PLL power As I will send patches special for moving to soc-cache, in patch 1, I still use the old way to read/write codec registers. Thanks Barry

2 4

[alsa-devel] ALSA: HDA VIA VT2020 support
by draco 30 Dec '09

30 Dec '09

Hello, I saw in the devel archive that the support for VIA VT2020 chipset have been added and merged to 1.0.22 released. (cf. http://mailman.alsa-project.org/pipermail/alsa-devel/2009-October/022183.ht… and http://www.alsa-project.org/main/index.php/Changes_v1.0.21_v1.0.22 ) Unfortunately, despite all was OK from the 1.0.21+git devel snapshot few month ago, the alsa-driver v1.0.22 doesn't work. I tried different snapshot from 1.0.22, and sent a bug report here : https://bugtrack.alsa-project.org/alsa-bug/view.php?id=4857 I don't know what I can do more to resolve the bug, but I can make some other tests and give you more log if needed. NB : I don't subscribe the devel mailing list, but I am "monitoring" the above bug report. Thank's in advance. Best Regards, draco

2 2

[alsa-devel] [PATCH] soc-cache: fix training whitespace checkpatch issue
by Barry Song 30 Dec '09

30 Dec '09

Signed-off-by: Barry Song <21cnbao(a)gmail.com> --- sound/soc/soc-cache.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/sound/soc/soc-cache.c b/sound/soc/soc-cache.c index d2505e8..906878e 100644 --- a/sound/soc/soc-cache.c +++ b/sound/soc/soc-cache.c @@ -182,7 +182,7 @@ static struct { { .addr_bits = 7, .data_bits = 9, .write = snd_soc_7_9_write, .read = snd_soc_7_9_read, - .spi_write = snd_soc_7_9_spi_write + .spi_write = snd_soc_7_9_spi_write }, { .addr_bits = 8, .data_bits = 8, -- 1.5.6.3

2 2

[alsa-devel] [PATCH] ASoC: fsi-ak4642: Remove ak4642_add_i2c_device
by Kuninori Morimoto 30 Dec '09

30 Dec '09

I2C devices should be registered when platform board setting in latest ASoC. Signed-off-by: Kuninori Morimoto <morimoto.kuninori(a)renesas.com> --- sound/soc/sh/fsi-ak4642.c | 30 ------------------------------ 1 files changed, 0 insertions(+), 30 deletions(-) diff --git a/sound/soc/sh/fsi-ak4642.c b/sound/soc/sh/fsi-ak4642.c index c7af097..5263ab1 100644 --- a/sound/soc/sh/fsi-ak4642.c +++ b/sound/soc/sh/fsi-ak4642.c @@ -42,42 +42,12 @@ static struct snd_soc_device fsi_snd_devdata = { .codec_dev = &soc_codec_dev_ak4642, }; -#define AK4642_BUS 0 -#define AK4642_ADR 0x12 -static int ak4642_add_i2c_device(void) -{ - struct i2c_board_info info; - struct i2c_adapter *adapter; - struct i2c_client *client; - - memset(&info, 0, sizeof(struct i2c_board_info)); - info.addr = AK4642_ADR; - strlcpy(info.type, "ak4642", I2C_NAME_SIZE); - - adapter = i2c_get_adapter(AK4642_BUS); - if (!adapter) { - printk(KERN_DEBUG "can't get i2c adapter\n"); - return -ENODEV; - } - - client = i2c_new_device(adapter, &info); - i2c_put_adapter(adapter); - if (!client) { - printk(KERN_DEBUG "can't add i2c device\n"); - return -ENODEV; - } - - return 0; -} - static struct platform_device *fsi_snd_device; static int __init fsi_ak4642_init(void) { int ret = -ENOMEM; - ak4642_add_i2c_device(); - fsi_snd_device = platform_device_alloc("soc-audio", -1); if (!fsi_snd_device) goto out; -- 1.6.3.3

3 7

[alsa-devel] X-Fi notebook support
by The Source 30 Dec '09

30 Dec '09

Hello. I have some info on that card, but not much. I have discovered that this card is detected connected via USB rather than PCI-E (the slot is ExpressCard). snd_ctxfi uses PCI interfaces right? Can X-Fi support be also added to snd_usb_audio? Or can snd_ctxfi support USB?

1 0