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

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

[alsa-devel] Front jack not working with hda-intel driver SigmaTel STAC9271D codec
by David Mohr 29 Dec '09

29 Dec '09

Hi, I'm running ubuntu 9.10. I had to force model=5stack to get any audio output at all. While the jack in the back now works, I still don't get any sound on the front jack. I haven't found any options in alsamixer, and switching the output mode in pavucontrol to the headphones just makes the sound disappear from the back jack, but I still get nothing in the front. I uploaded my alsa-info.sh output here: http://www.alsa-project.org/db/?f=3ed2ab9e7732bf08d2bbfbe8adb74bf037d9e618 Can I fix this somehow, or is it a bug? And of course thanks everyone for the usually great working alsa system. ~David

2 3

[alsa-devel] ASoC updates for 2.6.33
by Mark Brown 29 Dec '09

29 Dec '09

The following changes since commit 6b7b284958d47b77d06745b36bc7f36dab769d9b: Linus Torvalds (1): Linux 2.6.33-rc2 are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound-2.6.git for-2.6.33 The change in the branch is much bigger than the diffstat shows due to the merge up of Linus' tree (which now builds for ARM). Guennadi Liakhovetski (1): ASoC: fix params_rate() macro use in several codecs Kuninori Morimoto (1): ASoC: fsi-ak4642: Remove ak4642_add_i2c_device Mark Brown (1): Merge commit 'v2.6.33-rc2' into for-2.6.33 sound/soc/codecs/wm8510.c | 14 +++++++------- sound/soc/codecs/wm8940.c | 14 +++++++------- sound/soc/codecs/wm8974.c | 14 +++++++------- sound/soc/sh/fsi-ak4642.c | 30 ------------------------------ 4 files changed, 21 insertions(+), 51 deletions(-)

2 1

[alsa-devel] DMA and delay feedback
by James Courtier-Dutton 29 Dec '09

29 Dec '09

Hi, Would there be benefit in separating the DMA and the transfer of audio samples to the sound card hardware from the delay and hw position feedback. For example, If the playback position is 0, the hardware has probably already transferred one period of the sound card. So, one cannot write to playback position 2 and expect it to be output to the sound card if the period size is 1024. For transfer purposes, one only needs to know that DMA transfer is complete on period X so that period X can now be over-written. I believe that this is what the DMA interrupt indicates. One needs to reliably detect a missed interrupt. It one took this approach, one might be able to hide the "missed interrupt" problem. When the interrupt finally did arrive, we would know where the next free period X is, and continue writing samples to that, irrespective of what went wrong before. This would allow for auto-recovery of the audio stream without having to stop and start the ring buffers again. One then needs to determine how one can get accurate "delay" values back from all sound card types. The "delay" value is used for applications like ensuring that audio and video play in sync. The problem ones at the moment appear to be the intel8x0 and hd-audio ones. There may be benefits from making the "delay" value return in nanoseconds instead of samples, particularly if gettimeofdate() is being used to try to produce accurate "delay" values. Kind Regards James

4 6