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

Re: [alsa-devel] [Intel-gfx] Problems with HDMI audio on Intel DG45FC motherboard
by Wu Fengguang 27 Oct '09

27 Oct '09

On Mon, Oct 26, 2009 at 06:31:45AM +0800, David Härdeman wrote: > On Wed, Oct 21, 2009 at 09:38:12AM +0800, Wu Fengguang wrote: > > On Wed, Oct 21, 2009 at 06:37:58AM +0800, David Härdeman wrote: > > > On Tue, Oct 20, 2009 at 09:26:00AM +0800, Wu Fengguang wrote: > > > >On Thu, Oct 15, 2009 at 01:40:53AM +0800, David Härdeman wrote: > > > >> >Complete silence for how much time? > > > >> > > > >> For the entire duration of the particular movie/audio track/video > > > >> clip/whatever. > > > >> > > > > > > > >I actually have a DG45FC box and have not run into this problem for > > > >all the HDMI monitors I have. What's your monitor model? > > > > > > A Samsung LE-55A956 LCD TV. But I think the problem is not with the > > > monitor (TV) but rather with the receiver that is between the DG45FC and > > > the TV. The receiver is a Marantz SR8002 with HDMI support. > > > > Got it. If you have a HDMI capable TV or monitor, it would be possible to get > > rid of the Marantz and check if the problem sticks :) > > Nope, DG45FC <-> TV works fine (although only with stereo of course), so > the culprit is the Marantz which is either being picky or buggy. Judging > from from quick Google searches, HDMI related problems with audio/video > seems par for the course with lots of different manufacturers (oh joy). Hmm.. > > OK. You can get more debug info if turning on > > > > CONFIG_SND_VERBOSE_PROCFS=y > > CONFIG_SND_VERBOSE_PRINTK=y > > CONFIG_SND_DEBUG=y > > CONFIG_SND_DEBUG_VERBOSE=y > > CONFIG_SND_PCM_XRUN_DEBUG=y > > Enabled in my latest tests, dmesg included below... Thanks. > > > >What if you change display > > > >modes with xrandr? > > > > > > Haven't tried that yet...currently running on 1920x1080@60 which should > > > (I guess) be one of the most common modes with modern LCD TV's. > > > > The infoframe would be different for 2-channel pure music and 5.1 channel > > movie. The video timing might also affect audio stream, because the HDMI > > audio data is transfered in the gaps of video data. > > I've tried a couple of different modes with xrandr, with both 2, 6 and 8 > channels of audio but it doesn't seem to change anything. OK. > > > >HDMI codec/sink seem to take some time to response to the output > > > >enable and new infoframe, so there are some delay. I've moved the HDMI > > > >output enable command to module load time, this helps. The infoframe > > > >is in theory created in run time based on the format of _each_ new > > > >audio stream, so infoframe transmission has to be started/stopped > > > >for each track.. > > > > > > So my current theory is along the line of HDMI audio infoframe or video > > > infoframe problems. Do you have any pointers where in the driver(s) > > > the infoframes (both audio and video) are generated so that I can add > > > some debugging statements to dump the frames and compare the working > > > and non-working scenarios? > > > > I guess the infoframe itself should be identical for the same clip. > > Have you tried upgrading to a recent Xorg/intel gfx driver? > > Currently testing with kernel 2.6.32-rc5 (self-compiled) + intel-gfx > 2.9.0 and X11R7.4 (from Debian unstable). That's fairly bleeding edge :) > > Anyway, the kernel driver code is linux/sound/pci/hda/patch_intelhdmi.c > > The relevant function is hdmi_setup_audio_infoframe(). Inside which the > > hdmi_setup_channel_mapping() is not functioning for G45, > > hdmi_setup_channel_allocation() is no-op for 2-channel music. > > hdmi_debug_dip_size() and hdmi_clear_dip_buffers() can also be commented out. > > And feel free to ask more questions :) > > I think I found a bug in the infoframe generation, > hdmi_fill_audio_infoframe from sound/pci/hda/patch_intelhdmi.c has two > for loops which use sizeof(ai) but ai is a pointer to struct > hdmi_audio_infoframe so the size of a pointer is used rather than the > size of the struct meaning that the wrong number of bytes is written. Good catch, thank you very much! > After fixing that, the dmesg output when playing "speaker-test -c8 -twav > -D hdmi -l1" is: > > [ 866.169344] ALSA sound/pci/hda/hda_intel.c:1617: azx_pcm_prepare: > bufsize=0x10000, format=0x17 > [ 866.169353] ALSA sound/pci/hda/hda_codec.c:1083: > hda_codec_setup_stream: NID=0x2, stream=0x5, channel=0, format=0x17 > [ 866.176112] ALSA sound/pci/hda/patch_intelhdmi.c:446: HDMI: select CA > 0x13 for 8-channel allocation: FL/FR LFE FC RL/RR RC FLC/FRC RLC/RRC > FLW/FRW FLH/FRH TC FCH > [ 866.176321] HDMI: ASP channel 0 => slot 0 > [ 866.176354] HDMI: ASP channel 0 => slot 0 > [ 866.176406] HDMI: ASP channel 0 => slot 0 > [ 866.176438] HDMI: ASP channel 0 => slot 0 > [ 866.176490] HDMI: ASP channel 0 => slot 0 > [ 866.176533] HDMI: ASP channel 0 => slot 0 > [ 866.176565] HDMI: ASP channel 0 => slot 0 > [ 866.176617] HDMI: ASP channel 0 => slot 0 > [ 866.176649] HDMI: ELD buf size is 64 > [ 866.176691] HDMI: DIP GP[0] buf size is 13 > [ 866.176733] HDMI: DIP GP[1] buf size is 10 > [ 866.176775] HDMI: DIP GP[2] buf size is 30 > [ 866.176817] HDMI: DIP GP[3] buf size is 30 > [ 866.176859] HDMI: DIP GP[4] buf size is 0 > [ 866.176901] HDMI: DIP GP[5] buf size is 0 > [ 866.176943] HDMI: DIP GP[6] buf size is 0 > [ 866.176986] HDMI: DIP GP[7] buf size is 0 > [ 866.179041] ALSA sound/pci/hda/patch_intelhdmi.c:342: HDMI: DIP GP[0] > buf reported size=13, written=32 > [ 866.181209] ALSA sound/pci/hda/patch_intelhdmi.c:342: HDMI: DIP GP[1] > buf reported size=10, written=32 > [ 866.183271] ALSA sound/pci/hda/patch_intelhdmi.c:342: HDMI: DIP GP[2] > buf reported size=30, written=32 > [ 866.185385] ALSA sound/pci/hda/patch_intelhdmi.c:342: HDMI: DIP GP[3] > buf reported size=30, written=32 > [ 866.185574] XXX: Writing audio inf: 0x84 0x01 0x0A 0x57 0x07 0x00 > 0x00 0x13 0x00 0x00 0x00 0x00 0x00 0x00 > [ 872.032225] ALSA sound/pci/hda/hda_codec.c:1096: > hda_codec_cleanup_stream: NID=0x2 > > (The XXX line was added by me to print the audio infoframe) FYI, I'll write another Intel GPU tool to dump the audio infoframe (among others) directly from the GPU registers :) > I think (if I understood the code correctly), that "DIP GP[0]" holds the > infoframe, but I don't understand why it would report a buf size of > 13...the audio infoframe is 14 bytes (3 header + 1 checksum + 10 body)? Good question. I guess I made it wrong again. The checksum field may be auto-generated by hardware: The HDMI specification defines a data island packet with a header of 4 bytes (3 bytes content + 1 byte ECC) and packet body of 32 bytes (28 bytes content and 4 bytes ECC). Note that the ECC bytes are not present in the DIP content populated by software and are hardware generated. - from HDA-034-A2.pdf > Also, what does the GP[1..3] buffers hold? They are for ACP and ISRC1/2 (not utilized by driver for now): When audio data is transmitted over the HDMI link, associated control information is transmitted as "Data Island Packets" over the link. Some of the packet types applicable to audio are ACP packets (for content protection), ISRC1/2 (for content info), Audio infoframe etc. For a detailed list of control packets and respective formats, please refer to the HDMI specification. > Anyway, even with the above for loops fixed, I still have the same > problems (not that weird perhaps since all the bytes that were being > missed anyway defaulted to 0x00). Yeah. I have always be wondering whether the checksum field is necessary. Removing it seems to change nothing. Anyway the number 13 is a strong indication for removing it. > I've noticed that if a run this: > > while true; do > speaker-test -t wav -c 8 -D hdmi -l 1 > speaker-test -t wav -c 2 -D hdmi -l 1 > done > > it always works, but this: > > while true; do > speaker-test -t wav -c 2 -D hdmi -l 1 > done > > doesn't. This is weird for now. Thanks for the tip! > Not sure what to make of it, the intel hdmi driver doesn't seem to do > anything special if the parameters (like channel count) change between > clips. Thanks, Fengguang

1 0

Re: [alsa-devel] [Intel-gfx] Problems with HDMI audio on Intel DG45FC motherboard
by Wu Fengguang 27 Oct '09

27 Oct '09

Hi Shane, [sorry for late response - I was out traveling] On Wed, Oct 21, 2009 at 06:43:53AM +0800, Shane W wrote: > Hey all, > > On Tue, Oct 20, 2009 at 09:26:00AM +0800, Wu Fengguang wrote: > > It's <= 0.5 second silence from my experience. > > Correct. > > > HDMI codec/sink seem to take some time to response to the output > > enable and new infoframe, so there are some delay. I've moved the HDMI > > output enable command to module load time, this helps. The infoframe > > is in theory created in run time based on the format of _each_ new > > audio stream, so infoframe transmission has to be started/stopped > > for each track.. > > I know this has come up before but can't we not start/stop > the infoframe if the sample format on the new track is the > same as the old. I mean playing an album, you're gonna get > 44100, 2ch s16le 95% of the time so that would atleast > cause the problem to appear much less. Yeah, this is worth trying. The attached (combined) patch have bits to do sticky infoframe. However my tests show that it didn't improve the 0.5s delay.. Thanks, Fengguang

1 0

[alsa-devel] Patches for libasound to support upcoming Audacious 2.2
by John Lindgren 26 Oct '09

26 Oct '09

Hello, I've been working on the ALSA output for the upcoming 2.2 release of Audacious media player and have run into some problems in snd_device_name_hint, which is now used to show the user a list of possible output devices. I've written patches which correct those problems. The biggest problem is that in several places, functions called by snd_device_name_hint call snd_config_delete on sections of the config returned by snd_config_search. Once these sections are deleted, future calls to snd_pcm_open fail miserably. ALSA lib conf.c:4600:(snd_config_expand) Unknown parameters CARD=ICH6,DEV=0 ALSA lib pcm.c:2211:(snd_pcm_open_noupdate) Unknown PCM front:CARD=ICH6,DEV=0 alsa-gapless: snd_pcm_open failed: Invalid argument. ALSA lib pcm.c:2211:(snd_pcm_open_noupdate) Unknown PCM pulse alsa-gapless: snd_pcm_open failed: No such file or directory. A smaller but still annoying problem shows up only once the offending snd_config_delete calls are taken out: software devices, such as "pulse" and "null" are listed twice or three times depending on how many hardware devices I have plugged in. A third problem is that "ctl" seems to be arbitrarily left out of the list of device types that snd_device_name_hint will search for. I've added it to the list in this patch, and it seems to work fine. Finally, a performance issue: snd_device_name_hint indirectly calls snd_dlopen frequently with the parameter name == NULL, meaning to open libasound.so itself. In this case, snd_dlopen calls dladdr every call to find out the path to libasound.so. Caching this path within snd_dlopen so that dladdr is called only once speeds up the execution time of snd_device_name_hint (a somewhat slow call) by 40%. I am attaching three patches that fix these problems: - src/conf.c - src/dlmisc.c - src/control/namehint.c Peace, John Lindgren

1 0

[alsa-devel] snd-usb-caiaq: Locking bug fixes
by Mark Hills 26 Oct '09

26 Oct '09

Hi Takashi, I'll follow up this mail with 3 revised patches for inclusion. They fix a significant bug; Daniel has ack'd them and asked that they go into -rc if possible. Thanks, -- Mark

2 4

[alsa-devel] [PATCH] ASoC: Amstrad Delta: add info about the line discipline requirement to Kconfig help text
by Janusz Krzysztofik 25 Oct '09

25 Oct '09

I thought it could be usefull to add some information on how to get the device fully supported by loading a line discipline on the modem line. Signed-off-by: Janusz Krzysztofik <jkrzyszt(a)tis.icnet.pl> --- As you could probably notice, I am not a native English, so please feel free to correct my poor language if desired. --- linux-2.6.32-rc5/sound/soc/omap/Kconfig.orig 2009-10-16 02:41:50.000000000 +0200 +++ linux-2.6.32-rc5/sound/soc/omap/Kconfig 2009-10-24 00:01:26.000000000 +0200 @@ -21,7 +21,18 @@ config SND_OMAP_SOC_AMS_DELTA select SND_OMAP_SOC_MCBSP select SND_SOC_CX20442 help - Say Y if you want to add support for SoC audio on Amstrad Delta. + Say Y if you want to add support for SoC audio device connected to + a handset and a speakerphone found on Amstrad E3 (Delta) videophone. + + Note that in order to get those devices fully supported, you have to + build the kernel with standard serial port driver included and + configured for at least 4 ports. Then, from userspace, you must load + a line discipline #19 on the modem (ttyS3) serial line. The simplest + way to achieve this is to install util-linux-ng and use the included + ldattach utility. This can be started automatically from udev, + a simple rule like this one should do the trick (it does for me): + ACTION=="add", KERNEL=="controlC0", \ + RUN+="/usr/sbin/ldattach 19 /dev/ttyS3" config SND_OMAP_SOC_OSK5912 tristate "SoC Audio support for omap osk5912"

2 1

[alsa-devel] [PATCH 0/4 v2] MFD/OMAP/ASoC: MFD device for twl4030 codec submodule
by Peter Ujfalusi 25 Oct '09

25 Oct '09

Hello, Changes from the first series: - twl4030-codec MFD driver is using the mfd-core API (and selects MFD_CORE) - Added Acked-by: Tony Lindgren <tony(a)atomide.com> to the patch for the OMAP board files - User selectable Kconfig is removed for the TWL4030_CODEC - soc codec driver patch separated: - Change the header file, and use the include/linux/mfd/twl4030-codec.h for register definitions - The actual change in the soc codec driver - Module alias corrected in soc codec driver - The bias is brought up when the driver comes up, rather than in soc probe. - The soc codec driver is selecting the TWL4030_CODEC driver The series applies on top of sound-2.6:topic/asoc branch Commit message from the first series: The following series adds new MFD device on top of the twl4030 MFD device for the codec part of the chip, and also converts the soc audio driver to use the correct probing (device model). Reason for the twl4030_codec MFD: the vibra control is actually in the codec part of the twl4030. If both the vibra and the audio functionality is needed from the twl4030 at the same time, than they need to control the codec power and APLL at the same time without breaking the other driver. Also these two has to be able to work without the need for the other driver. The proposed solution: Register twl4030_codec as a child for the twl4030 mfd. twl4030_codec is also and mfd and at the moment it has two child: twl4030_codec_audio: for audio codec twl4030_codec_vibra: for vibra driver The twl4030_codec mfd registers the devices for audio and vibra (if the platform data is not NULL for them), and has - at the moment - functions to enable/disable resources, each of these resources has ref-counts, so the twl4030_codec knows, when the resource is need to be turned on or off. The interface is quite simple: int twl4030_codec_enable_resource(enum twl4030_codec_res id); int twl4030_codec_disable_resource(enum twl4030_codec_res id); These functions are returning the content of the given register after the modification (or negative value, if error - the error handling need to be revisited in a near future), so that the caller can update it's local cache if it need to do (the audio driver needs it). There are two resource defined: TWL4030_CODEC_RES_POWER: Controlling the power of the codec TWL4030_CODEC_RES_APLL: For APLL The vibra driver is not part of this series. I have also included a patch, which changes the board files for those, which in my knowledge uses the twl4030 codec as audio device. I might missed some boards... To-Do list: - add the actual vibra driver ;) - coexistence related fixes for the audio and vibra driver - move all audio related configuration from soc machine drivers to the board files (if any) --- Peter Ujfalusi (4): MFD: twl4030: add twl4030_codec MFD as a new child to the core OMAP: Platform support for twl4030_codec MFD ASoC: TWL4030: use the twl4030-codec.h for register descriptions ASoC: TWL4030: Driver registration via twl4030_codec MFD arch/arm/mach-omap2/board-3430sdp.c | 9 + arch/arm/mach-omap2/board-omap3beagle.c | 9 + arch/arm/mach-omap2/board-omap3evm.c | 9 + arch/arm/mach-omap2/board-omap3pandora.c | 9 + arch/arm/mach-omap2/board-overo.c | 9 + arch/arm/mach-omap2/board-zoom2.c | 9 + drivers/mfd/Kconfig | 6 + drivers/mfd/Makefile | 1 + drivers/mfd/twl4030-codec.c | 241 ++++++++++++++++++++++++++ drivers/mfd/twl4030-core.c | 14 ++ include/linux/i2c/twl4030.h | 18 ++ include/linux/mfd/twl4030-codec.h | 271 ++++++++++++++++++++++++++++++ sound/soc/codecs/Kconfig | 1 + sound/soc/codecs/twl4030.c | 203 ++++++++++++++--------- sound/soc/codecs/twl4030.h | 242 +-------------------------- 15 files changed, 738 insertions(+), 313 deletions(-) create mode 100644 drivers/mfd/twl4030-codec.c create mode 100644 include/linux/mfd/twl4030-codec.h

3 9

[alsa-devel] [PATCH 2/2] es18xx: remove snd_audiodrive structure
by Krzysztof Helt 25 Oct '09

25 Oct '09

From: Krzysztof Helt <krzysztof.h1(a)wp.pl> Remove intermediate snd_audiodrive structure between snd_card structure and snd_es18xx. This reduces size of source code and binary driver. Signed-off-by: Krzysztof Helt <krzysztof.h1(a)wp.pl> --- sound/isa/es18xx.c | 71 ++++++++++++++++++--------------------------------- 1 files changed, 25 insertions(+), 46 deletions(-) diff --git a/sound/isa/es18xx.c b/sound/isa/es18xx.c index 160752b..5cf42b4 100644 --- a/sound/isa/es18xx.c +++ b/sound/isa/es18xx.c @@ -139,10 +139,6 @@ struct snd_es18xx { #ifdef CONFIG_PM unsigned char pm_reg; #endif -}; - -struct snd_audiodrive { - struct snd_es18xx *chip; #ifdef CONFIG_PNP struct pnp_dev *dev; struct pnp_dev *devc; @@ -755,8 +751,7 @@ static int snd_es18xx_playback_trigger(struct snd_pcm_substream *substream, static irqreturn_t snd_es18xx_interrupt(int irq, void *dev_id) { struct snd_card *card = dev_id; - struct snd_audiodrive *acard = card->private_data; - struct snd_es18xx *chip = acard->chip; + struct snd_es18xx *chip = card->private_data; unsigned char status; if (chip->caps & ES18XX_CONTROL) { @@ -1699,8 +1694,7 @@ static struct snd_pcm_ops snd_es18xx_capture_ops = { static int __devinit snd_es18xx_pcm(struct snd_card *card, int device, struct snd_pcm **rpcm) { - struct snd_audiodrive *acard = card->private_data; - struct snd_es18xx *chip = acard->chip; + struct snd_es18xx *chip = card->private_data; struct snd_pcm *pcm; char str[16]; int err; @@ -1742,8 +1736,7 @@ static int __devinit snd_es18xx_pcm(struct snd_card *card, int device, #ifdef CONFIG_PM static int snd_es18xx_suspend(struct snd_card *card, pm_message_t state) { - struct snd_audiodrive *acard = card->private_data; - struct snd_es18xx *chip = acard->chip; + struct snd_es18xx *chip = card->private_data; snd_power_change_state(card, SNDRV_CTL_POWER_D3hot); @@ -1760,8 +1753,7 @@ static int snd_es18xx_suspend(struct snd_card *card, pm_message_t state) static int snd_es18xx_resume(struct snd_card *card) { - struct snd_audiodrive *acard = card->private_data; - struct snd_es18xx *chip = acard->chip; + struct snd_es18xx *chip = card->private_data; /* restore PM register, we won't wake till (not 0x07) i/o activity though */ snd_es18xx_write(chip, ES18XX_PM, chip->pm_reg ^= ES18XX_PM_FM); @@ -1773,8 +1765,7 @@ static int snd_es18xx_resume(struct snd_card *card) static int snd_es18xx_free(struct snd_card *card) { - struct snd_audiodrive *acard = card->private_data; - struct snd_es18xx *chip = acard->chip; + struct snd_es18xx *chip = card->private_data; release_and_free_resource(chip->res_port); release_and_free_resource(chip->res_ctrl_port); @@ -1789,7 +1780,6 @@ static int snd_es18xx_free(struct snd_card *card) disable_dma(chip->dma2); free_dma(chip->dma2); } - kfree(chip); return 0; } @@ -1802,19 +1792,14 @@ static int __devinit snd_es18xx_new_device(struct snd_card *card, unsigned long port, unsigned long mpu_port, unsigned long fm_port, - int irq, int dma1, int dma2, - struct snd_es18xx ** rchip) + int irq, int dma1, int dma2) { - struct snd_es18xx *chip; + struct snd_es18xx *chip = card->private_data; static struct snd_device_ops ops = { .dev_free = snd_es18xx_dev_free, }; int err; - *rchip = NULL; - chip = kzalloc(sizeof(*chip), GFP_KERNEL); - if (chip == NULL) - return -ENOMEM; spin_lock_init(&chip->reg_lock); spin_lock_init(&chip->mixer_lock); spin_lock_init(&chip->ctrl_lock); @@ -1865,14 +1850,12 @@ static int __devinit snd_es18xx_new_device(struct snd_card *card, snd_es18xx_free(card); return err; } - *rchip = chip; return 0; } static int __devinit snd_es18xx_mixer(struct snd_card *card) { - struct snd_audiodrive *acard = card->private_data; - struct snd_es18xx *chip = acard->chip; + struct snd_es18xx *chip = card->private_data; int err; unsigned int idx; @@ -2074,11 +2057,11 @@ static int __devinit snd_audiodrive_pnp_init_main(int dev, struct pnp_dev *pdev) return 0; } -static int __devinit snd_audiodrive_pnp(int dev, struct snd_audiodrive *acard, +static int __devinit snd_audiodrive_pnp(int dev, struct snd_es18xx *chip, struct pnp_dev *pdev) { - acard->dev = pdev; - if (snd_audiodrive_pnp_init_main(dev, acard->dev) < 0) + chip->dev = pdev; + if (snd_audiodrive_pnp_init_main(dev, chip->dev) < 0) return -EBUSY; return 0; } @@ -2104,26 +2087,26 @@ static struct pnp_card_device_id snd_audiodrive_pnpids[] = { MODULE_DEVICE_TABLE(pnp_card, snd_audiodrive_pnpids); -static int __devinit snd_audiodrive_pnpc(int dev, struct snd_audiodrive *acard, +static int __devinit snd_audiodrive_pnpc(int dev, struct snd_es18xx *chip, struct pnp_card_link *card, const struct pnp_card_device_id *id) { - acard->dev = pnp_request_card_device(card, id->devs[0].id, NULL); - if (acard->dev == NULL) + chip->dev = pnp_request_card_device(card, id->devs[0].id, NULL); + if (chip->dev == NULL) return -EBUSY; - acard->devc = pnp_request_card_device(card, id->devs[1].id, NULL); - if (acard->devc == NULL) + chip->devc = pnp_request_card_device(card, id->devs[1].id, NULL); + if (chip->devc == NULL) return -EBUSY; /* Control port initialization */ - if (pnp_activate_dev(acard->devc) < 0) { + if (pnp_activate_dev(chip->devc) < 0) { snd_printk(KERN_ERR PFX "PnP control configure failure (out of resources?)\n"); return -EAGAIN; } snd_printdd("pnp: port=0x%llx\n", - (unsigned long long)pnp_port_start(acard->devc, 0)); - if (snd_audiodrive_pnp_init_main(dev, acard->dev) < 0) + (unsigned long long)pnp_port_start(chip->devc, 0)); + if (snd_audiodrive_pnp_init_main(dev, chip->dev) < 0) return -EBUSY; return 0; @@ -2139,24 +2122,20 @@ static int __devinit snd_audiodrive_pnpc(int dev, struct snd_audiodrive *acard, static int snd_es18xx_card_new(int dev, struct snd_card **cardp) { return snd_card_create(index[dev], id[dev], THIS_MODULE, - sizeof(struct snd_audiodrive), cardp); + sizeof(struct snd_es18xx), cardp); } static int __devinit snd_audiodrive_probe(struct snd_card *card, int dev) { - struct snd_audiodrive *acard = card->private_data; - struct snd_es18xx *chip; + struct snd_es18xx *chip = card->private_data; struct snd_opl3 *opl3; int err; - if ((err = snd_es18xx_new_device(card, - port[dev], - mpu_port[dev], - fm_port[dev], - irq[dev], dma1[dev], dma2[dev], - &chip)) < 0) + err = snd_es18xx_new_device(card, + port[dev], mpu_port[dev], fm_port[dev], + irq[dev], dma1[dev], dma2[dev]); + if (err < 0) return err; - acard->chip = chip; sprintf(card->driver, "ES%x", chip->version); -- 1.6.0.3 ---------------------------------------------------------------------- Nie dla nich ciepla praca za biurkiem. Sprawdz >>> http://link.interia.pl/f2383

1 0

[alsa-devel] Problems in snd_device_name_hint
by John Lindgren 25 Oct '09

25 Oct '09

Hello, I haven't frequented the alsa-devel list in the past, but Debian's maintainer apparently prefers that I go directly to the ALSA developers. While developing a new ALSA output plugin for Audacious audio player, I have run into several problems in snd_device_name_hint. I've already described the problems in the Debian bug tracker and made up some patches, which I would like someone to review. Here are the links: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=549531 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=552240 I'm also attaching the patches here. Peace, John Lindgren

1 0

Re: [alsa-devel] How to close ALSA device nodes?
by Rémi Denis-Courmont 24 Oct '09

24 Oct '09

Le dimanche 18 octobre 2009 20:13:15 Robert Hancock, vous avez écrit : > > From the earlier thread, I reckon that ALSA developers consider that this > > is an upper-layer issue. Maybe so, but then how is the upper-layer > > supposed to find which file descriptors ALSA-lib has opened - if any? > > Conversely, if ALSA- lib won't tell while file descriptors it is using, > > what could possibly be the use case for not closing those on exec? > > I agree that it's a difficult problem for an app that wants to fork > and exec another process.. I'd think really should be some way for an > app to control the CLOEXEC flag for the file descriptors that alsa-lib > has open.. Right. The kernel recently introduced the O_CLOEXEC open flag, to support thread-safe close-on-exec. The only way to leverage this is for ALSA-lib to set close-on-exec itself when it opens a file (whether by default or when the application requests it). That said, I still fail to see any potential use case to not set the flag. Since ALSA-lib won't let the application know about the file handles, any application cannot a use them across exec() in the first place. For the reference, glibc is now setting close-on-exec in similar cases, e.g. syslog(). > I guess the alternative would be to shutdown all open PCMs, etc. in > ALSA in the child process after forking and before the exec, so that > they don't end up still open for the new process.. I suspect such an approach would be painful both for ALSA and for the applications. From ALSA, this would need safety with regards to fork in another thread. That probably requires pthread_atfork() *glurp* if ALSA is to keep its SMP & thread-safety promise *ouch*. From the application, this require calling an ALSA function between fork and exec. That would forbid using system(), popen() or -faster- posix_spawn*(). That also means linking to ALSA in every place that executes. Considering that VLC is heavily plugin- based, this would be so impractical that I'd even rather scan through /proc/self/fd... -- Rémi Denis-Courmont http://git.remlab.net/cgi-bin/gitweb.cgi?p=vlc-courmisch.git;a=summary

2 5

[alsa-devel] What is the meaning of the mask values in the pcm hw constraints struct ?
by Neil Jones 24 Oct '09

24 Oct '09

I am developing an ASoC driver for a custom SoC (not in tree yet), I have written the platform and board modules and my hardware detects and installs ok, im now trying to play sound using aplay but im having issues. I get the error "aplay: set_params:1022: Unable to install hw params:" I have traced the problem to a failing ioctl call (snd_pcm_playback_ioctl) the error occurs in snd_pcm_hw_refine when refining the mask for the SNDRV_PCM_HW_PARAM_ACCESS mask, all the bit fields in my runtime->hw_constraints are zero for this field, but the requested params have the value 7, Im not sure what this means, the SNDRV_PCM_ACCESS_xxx defines in asound.h only go upto 4 ? I have attached logs below (with RULES_DEBUG turned on) hopefully this may shed some light. Thanks in advance for any help, Neil Jones Logs: # /usr/bin/aplay /var/snd48khz.wav Playing WAVE '/var/snd48khz.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo aplay: set_params:1022: Unable to install hw params: ACCESS: RW_INTERLEAVED FORMAT: S16_LE SUBFORMAT: STD SAMPLE_BITS: 16 FRAME_BITS: 32 CHANNELS: 2 RATE: 48000 PERIOD_TIME: (85333 85334) PERIOD_SIZE: 4096 PERIOD_BYTES: 16384 PERIODS: (5 6) BUFFER_TIME: 500000 BUFFER_SIZE: 24000 BUFFER_BYTES: 96000 TICK_TIME: 0 (klog) ... Rule 0 [4030f9f4]: FORMAT = 4 -> 4 Rule 2 [4030f750]: SAMPLE_BITS = [16 16] -> [16 16] Rule 4 [4030f90c]: FRAME_BITS = [16 16] -> [16 16] Rule 5 [4030f90c]: FRAME_BITS = [16 16] -> [16 16] Rule 7 [4030f90c]: RATE = [48000 48000] -> [48000 48000] Rule 8 [4030f90c]: RATE = [48000 48000] -> [48000 48000] Rule 9 [4030f750]: PERIODS = [1 128] -> [1 128] Rule 10 [4030f750]: PERIOD_SIZE = [16 4096] -> [16 4096] Rule 12 [4030f828]: PERIOD_SIZE = [16 4096] -> [16 4096] Rule 15 [4030f828]: BUFFER_SIZE = [16 65536] -> [16 65536] Rule 18 [4030f90c]: PERIOD_TIME = (166 128000] -> (333 85334) Rule 19 [4030f90c]: BUFFER_TIME = (166 2048000] -> (333 1365334) Rule 7 [4030f90c]: RATE = [48000 48000] -> [48000 48000] Rule 8 [4030f90c]: RATE = [48000 48000] -> [48000 48000] Rule 12 [4030f828]: PERIOD_SIZE = [16 4096] -> [16 4096] Rule 15 [4030f828]: BUFFER_SIZE = [16 65536] -> [16 65536] ACCESS = 0000000000000007 -> 0000000000000000 - This message is subject to Imagination Technologies' e-mail terms: http://www.imgtec.com/e-mail.htm Imagination Technologies Ltd is a limited company registered in England No: 1306335 Registered Office: Imagination House, Home Park Estate, Kings Langley, Hertfordshire, WD4 8LZ. Email to and from the company may be monitored for compliance and other administrative purposes. -

2 3