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

[alsa-devel] a52: update to new libavcodec API
by Anton Khirnov 13 Nov '12

13 Nov '12

Hi, this patchset updates the a52 plugin to work with the upcoming Libav 9 release. In doing that, it drops support for pre-0.8 libavcodec versions. I think it is not unreasonable to demand at least a year old libavcodec to compile latest git of alsa-plugins and keeping compatibility with the old audio encoding API would result in ugly #ifdefery mess. The plugin compiles and appears to work, but as I have no SPDIF receiver, I cannot properly test it. I would very much appreciate it if someone else could do that. Please comment. -- Anton Khirnov

2 5

[alsa-devel] [PATCH 1/2] aplay: Show usage if no parameter is passed
by Fabio Estevam 12 Nov '12

12 Nov '12

From: Fabio Estevam <fabio.estevam(a)freescale.com> When aplay/arecord are called without any argument the application hangs forever. Instead of hanging, print the usage and exit. Signed-off-by: Fabio Estevam <fabio.estevam(a)freescale.com> --- aplay/aplay.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/aplay/aplay.c b/aplay/aplay.c index 741979a..9cc5063 100644 --- a/aplay/aplay.c +++ b/aplay/aplay.c @@ -519,6 +519,11 @@ int main(int argc, char *argv[]) return 1; } + if (argc == 1) { + usage(command); + return 0; + } + chunk_size = -1; rhwparams.format = DEFAULT_FORMAT; rhwparams.rate = DEFAULT_SPEED; -- 1.7.9.5

2 2

Re: [alsa-devel] Help requested: new HSS1394 MIDI back-end
by Clemens Ladisch 12 Nov '12

12 Nov '12

Sean M. Pappalardo - D.J. Pegasus wrote: > On 05/30/2012 06:51 AM, Clemens Ladisch wrote: >> Sean M. Pappalardo - D.J. Pegasus wrote: >>> four-byte platter messages that start with >>> 0xF9 and the remaining three can range from 0x00 to 0xFF. >> >> This is not MIDI. Into what MIDI messages should >> the driver convert this? > > It shouldn't convert it at all. Just deliver it as-is in a single > four-byte message, if possible. The problem is the communication between the driver and userspace; _that_ must be valid MIDI. > 0xF9 is a valid, if undefined, MIDI status. Undefined means invalid. Furthermore, data bytes must not have the eighth bit set. > I will also need the ability to use the HSS1394 SendUserControl > function to set the device's timers, and that is definitely not MIDI > at all. > I wonder if it would be a good idea to define a special SYSEX message > that the SCS1x driver would interpret and convert to a call to that > function? As it happens, the actual SysEx commands use the wrong manufacturer ID ("00 01 02" is Crystal Semiconductor); I could just use the real ID (Stanton is "00 01 60") to escape non-MIDI HSS1394 messages. Let's add "HSS" to identify this, and to allow the full byte range, each HSS1394 byte is split into two nibbles. So: 00 F9 xx yy zz -> F0 00 01 60 48 53 53 00 00 0F 09 0x 0x 0y 0y 0z 0z F7 13 xx yy zz <- F0 00 01 60 48 53 53 01 03 0x 0x 0y 0y 0z 0z F7 14 xx yy zz <- F0 00 01 60 48 53 53 01 04 0x 0x 0y 0y 0z 0z F7 (0x13 = 0x10 + 3 = kUserTagBase + uUserTag) Regards, Clemens

3 21

Re: [alsa-devel] [sound:for-next 42/42] sound/pci/ice1712/ice1724.c:2366:5: error: 'struct snd_ice1712' has no member named 'pm_suspend_enabled'
by Takashi Iwai 12 Nov '12

12 Nov '12

At Mon, 12 Nov 2012 18:22:00 +0800, kbuild test robot wrote: > > tree: git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git for-next > head: ef8784453d1cd5beedce9d288d56221a898c7ecb > commit: ef8784453d1cd5beedce9d288d56221a898c7ecb [42/42] ALSA: ice1724: enable suspend on unknown ICE1724 cards > config: i386-randconfig-b666 (attached as .config) > > All error/warnings: > > sound/pci/ice1712/ice1724.c: In function 'snd_vt1724_read_eeprom': > sound/pci/ice1712/ice1724.c:2366:5: error: 'struct snd_ice1712' has no member named 'pm_suspend_enabled' Fixed now like below. Thanks! Takashi --- From 063f603c8c1039f576405bb98c1b6c94262e5806 Mon Sep 17 00:00:00 2001 From: Takashi Iwai <tiwai(a)suse.de> Date: Mon, 12 Nov 2012 11:38:10 +0100 Subject: [PATCH] ALSA: ice1724: Fix build error without CONFIG_PM_SLEEP Bah, forgot this again... Signed-off-by: Takashi Iwai <tiwai(a)suse.de> --- sound/pci/ice1712/ice1724.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/sound/pci/ice1712/ice1724.c b/sound/pci/ice1712/ice1724.c index 4c52a31..ea99e56 100644 --- a/sound/pci/ice1712/ice1724.c +++ b/sound/pci/ice1712/ice1724.c @@ -2362,8 +2362,10 @@ static int __devinit snd_vt1724_read_eeprom(struct snd_ice1712 *ice, } printk(KERN_WARNING "ice1724: No matching model found for ID 0x%x\n", ice->eeprom.subvendor); +#ifdef CONFIG_PM_SLEEP /* assume AC97-only card which can suspend without additional code */ ice->pm_suspend_enabled = 1; +#endif found: ice->eeprom.size = snd_vt1724_read_i2c(ice, dev, 0x04); -- 1.8.0

1 0

[alsa-devel] [PATCH] snd-ice1712: enable suspend on unknown ICE1724 cards
by Ondrej Zary 12 Nov '12

12 Nov '12

Assume that unknown ICE1724-based cards are AC97-only that can suspend without any additional card-specific code. This fixes suspend on Gainward Hollywood@Home 7.1. Signed-off-by: Ondrej Zary <linux(a)rainbow-software.org> --- sound/pci/ice1712/ice1724.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/sound/pci/ice1712/ice1724.c b/sound/pci/ice1712/ice1724.c index 5cc3fa5..aebd584 100644 --- a/sound/pci/ice1712/ice1724.c +++ b/sound/pci/ice1712/ice1724.c @@ -2363,6 +2363,8 @@ static int __devinit snd_vt1724_read_eeprom(struct snd_ice1712 *ice, } printk(KERN_WARNING "ice1724: No matching model found for ID 0x%x\n", ice->eeprom.subvendor); + /* assume AC97-only card which can suspend without additional code */ + ice->pm_suspend_enabled = 1; found: ice->eeprom.size = snd_vt1724_read_i2c(ice, dev, 0x04); -- Ondrej Zary

2 1

[alsa-devel] ALSA with dmix performance issue...
by Sandulescu Bogdan 12 Nov '12

12 Nov '12

Hello all, While implementing a multiple sounds playback using 'dmix' plugin, I've encountered several performance issues. Here they are: 1. The snd_pcm_open(&pPcmPlayHandle, "plug:'dmix:RATE=8000'" , SND_PCM_STREAM_PLAYBACK, 0) - used to playback multiple sounds with dmix pluging, it is taking around 70ms to complete. This is a very long period, considering there are some sounds to be played which have 50ms lenght! Is it possible to decrease this value? 2. Same issue with the "setting Parameters" sequence. It is also taking around 80ms to complete; Is it possible to decrease this value? 3. The architecture of my module is done as follows: - MainThread() -> receives sound play requests and creates new thread/threads based on such requests * PlayThreads() -> created whenever a sound playback is needed; it opens() the dmix, setting parameters; output data; close dmix; exit thread at playback completion; multiple PlayThreads() could be active at the same time! I have tried to move all 'common' sound settings and the pcm_open() - in order to optimize runtime - into the MainThread (operation done only once), and the PlayThreads are responsible just of outputing data. However, this resulted in incorrect ALSA functionality: when more than two playbacks are active at the same time, all Play threads , except the first activated one, cannnot access the PCM handle correctly: returned code -77 (EBADFD), in some other cases returned -5 (EIO)... Are there any other methods I can optimize the runtime performance? Thank you in advance for any answers, Bogdan

1 0

[alsa-devel] Non-blocking snd_pcm_drain?
by Daniel Sanz 11 Nov '12

11 Nov '12

Hello, I'm new to the ALSA API and I have a question: I've developed a small program that plays audio from a buffer using snd_pcm_writei and snd_pcm_drain but I noticed that the snd_pcm_drain call blocks until the buffer is completely drained. Is there any way to drain the buffer without a block? I've tried calling snd_pcm_nonblock(handle, 1) before the call to snd_pcm_drain but it does not work. The context is that this is an application that plays a particular WAV sound repeatedly, so I don't want to wait until the sound is played completely before it is played again. What would be the best way to achieve this? Thanks,

2 3

Re: [alsa-devel] Possible problem with cmipci driver
by Takashi Iwai 11 Nov '12

11 Nov '12

At Sat, 10 Nov 2012 11:20:06 -0700, Jake Edge wrote: > > > Hi Takashi, Jaroslav, and other sound developers, > > Maybe I am way off base, but I think there may be a bug relatively > recently introduced into the cmipci driver. I note that Takashi has > made some changes in July (commit: > 68cb2b559278858ef9f3a7722f95df88797c7840 ) that might (?) be relevant. If the above commit is the culprit, does the patch below help? Takashi --- diff --git a/sound/pci/cmipci.c b/sound/pci/cmipci.c index 22122ff..ae41982 100644 --- a/sound/pci/cmipci.c +++ b/sound/pci/cmipci.c @@ -3368,7 +3368,7 @@ static int snd_cmipci_suspend(struct device *dev) pci_disable_device(pci); pci_save_state(pci); - pci_set_power_state(pci, PCI_D3hot); + pci_set_power_state(pci, pci_choose_state(pci, PMSG_SUSPEND)); return 0; }

1 0

[alsa-devel] [PATCH] ALSA: ASoC: cs4271: free allocated GPIO
by Daniel Mack 10 Nov '12

10 Nov '12

In case of probe deferral, the allocated GPIO line is not freed, which prevents it from being claimed and properly asserted in later attempts. Fix this by freeing the GPIO in case of errors. Signed-off-by: Daniel Mack <zonque(a)gmail.com> Reported-by: Michael Hirsch <hirsch(a)teufel.de> Cc: Alexander Sverdlin <subaparts(a)yandex.ru> --- sound/soc/codecs/cs4271.c | 17 +++++++++++++---- 1 file changed, 13 insertions(+), 4 deletions(-) diff --git a/sound/soc/codecs/cs4271.c b/sound/soc/codecs/cs4271.c index e5a7ea4..ea57014 100644 --- a/sound/soc/codecs/cs4271.c +++ b/sound/soc/codecs/cs4271.c @@ -505,7 +505,7 @@ static int cs4271_probe(struct snd_soc_codec *codec) ret = regulator_enable(cs4271->vd_supply); if (ret < 0) { dev_err(codec->dev, "unable to enable regulator\n"); - return ret; + goto err; } } @@ -548,22 +548,31 @@ static int cs4271_probe(struct snd_soc_codec *codec) cs4271->bus_type); if (ret) { dev_err(codec->dev, "Failed to set cache I/O: %d\n", ret); - return ret; + goto err_free_gpio; } ret = snd_soc_update_bits(codec, CS4271_MODE2, CS4271_MODE2_PDN | CS4271_MODE2_CPEN, CS4271_MODE2_PDN | CS4271_MODE2_CPEN); if (ret < 0) - return ret; + goto err_free_gpio; ret = snd_soc_update_bits(codec, CS4271_MODE2, CS4271_MODE2_PDN, 0); if (ret < 0) - return ret; + goto err_free_gpio; /* Power-up sequence requires 85 uS */ udelay(85); return snd_soc_add_codec_controls(codec, cs4271_snd_controls, ARRAY_SIZE(cs4271_snd_controls)); + +err_free_gpio: + if (gpio_is_valid(cs4271->gpio_nreset)) + gpio_free(cs4271->gpio_nreset); + + cs4271->gpio_nreset = -EINVAL; + +err: + return ret; } static int cs4271_remove(struct snd_soc_codec *codec) -- 1.7.11.7

2 2

[alsa-devel] snd_pcm_wait function
by Enno Fennema 10 Nov '12

10 Nov '12

The documentation says this functions waits for the pcm to become ready for I/O. I am not sure what ready means in this context. I assume entering the PREPARED state. Is that correct? Is there a function to wait for entering the SETUP state. In particular I would like to wait for pcm_snd_drain to finish. Appreciate any help. Enno Fennema

2 1