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

[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

[alsa-devel] Bug in alsa-lib causes high CPU with rate plugin
by Trent Piepho 10 Nov '12

10 Nov '12

There is a bug in the way alsa-lib sleeps when using a plugin that can cause very high CPU usage for PCM playback with using rate conversion. I've attached a simple test program. It simply uses blocking mode and calls snd_pcm_writei() with a buffer of zeros one thousand times and then exits. One would think the CPU usage would be very low. And indeed when the write sized passed to snd_pcm_writei is equal to the period size it is quite low (i5 with HDA): lucid@Dashboard:~$ /usr/bin/time ./a.out > /dev/null period size 352, write size 352 done, wrote 1000 buffers of 352 frames 0.10user 0.15system 0:09.01elapsed 2%CPU (0avgtext+0avgdata 9360maxresident)k But, with one small change to have snd_pcm_writei() write buffers one frame larger than the period size, one gets this: period size 352, write size 353 done, wrote 1000 buffers of 353 frames 1.92user 2.00system 0:09.04elapsed 43%CPU (0avgtext+0avgdata 9360maxresident)k Simply increasing the write size by one caused the CPU usage to jump to 43% from 2%! Because more software writes in chunks equal to the period size it doesn't see this problem. That's why it wasn't found and fixed long ago. I've figured out why this is happening. The problem is caused by how alsa-lib decides to sleep when waiting for available buffer space and the way the rate plugin can only process complete periods at a time. Suppose we have the rate plugin with hw as its slave. Both have a ring buffer that is 3+ periods in size. Allowing for the rate conversion, the buffers and periods are the same size for both. avail_min is set to the normal value of one period for both. Suppose there are two empty periods in the buffer and we call snd_pcm_writei() to write 1.5 periods. That fits in the empty space in the rate plugin's buffer and so gets written immediately. The rate plugin's buffer now has 0.5 empty periods of space. The rate plugin will resample just one period of the newly written data, because it can only process complete periods at a time, and write that to the hw buffer. So the hw buffer now has one free period. This means the rate plugin has less free space in its buffer than the hw has, because the rate plugin has half a period of data it can't yet resample and pass to the slave. Now we write another one period of data with another snd_pcm_writei() call. This gets to snd_pcm_write_areas() in pcm.c and triggers this code (edited for brevity): if ((state == SND_PCM_STATE_RUNNING && (snd_pcm_uframes_t)avail < pcm->avail_min && size > (snd_pcm_uframes_t)avail)) { err = snd_pcm_wait(pcm, -1); goto _again; } avail is the available space in the rate plugin's buffer, which is half a period. pcm->avail_min is also for the rate plugin. size is the amount remaining in the writei() call, which is one period in this example. As we can see, the conditions of the if() statement are true. avail of 0.5 periods is less than avail_min of 1 period and the size of the write (1 period) is greater than avail. So we call snd_pcm_wait() and then go back to the top when it returns. avail will get updated to the current value and this code runs again. Eventually snd_pcm_wait() will call poll() and try to sleep in the kernel while waiting for more room to be available. But remember the hw buffer had one full period free! That's more than tghe half period that's free in the rate buffer and, and this is the key here, it is *more than avail_min*. So poll() will not sleep at all! That's where the 43% CPU comes from. alsa-lib is in a tight loop inside snd_pcm_write_areas() calling snd_pcm_wait() over and over again. snd_pcm_wait() doesn't sleep, because it's based on the status of the hw buffer and that buffer does have free space. snd_pcm_write_areas() would write to the hw buffer and not try to sleep. But it's not looking at the hw buffer when it decides to sleep or write, it's looking at the rate buffer. And the rate buffer's fill level says to sleep, not write. And if snd_pcm_wait() was looking at the rate buffer, it would sleep. We have the rate buffer that's current fill level says, "sleep first, then write" and the HW buffer that says the opposite, "write first, then sleep". The code that writes looks at the former and decides to sleep but the code that sleeps looks at the latter and decides it's not time sleep. A trivial patch that stops this behavior is below, which simply forces the rate plugin's avail_min to 1. diff --git a/src/pcm/pcm_rate.c b/src/pcm/pcm_rate.c index 41089d7..86f57c4 100644 --- a/src/pcm/pcm_rate.c +++ b/src/pcm/pcm_rate.c @@ -1142,6 +1142,7 @@ static int snd_pcm_rate_start(snd_pcm_t *pcm) return 0; } rate->start_pending = 0; + pcm->avail_min = 1; return snd_pcm_start(rate->gen.slave); } I think it would be better to have the rate plugin decrease avail_min by how much unresampled data it has yet to pass to the slave. This preserves the idea of avail_min if it were set to more than one period. This also fixes the problem. I've attached a real patch to do that. For the test program to show the problem YOU MUST USE THE RATE CONVERT PLUGIN! It seems obvious but people keep missing this. I found the easiest way to do that was to create a custom device in ~/.asoundrc that forced rate converting to 48kHz. Like this: pcm.foo { type plug; slave { pcm "hw:0,0"; rate 48000; } }

2 3