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

[alsa-devel] aplay - memory leak
by Appalayagari Sreedhar 04 Nov '11

04 Nov '11

Hi, I am working with DM368 based custom board. we have external codec interfaced to McBSP. when we run aplay command i am observing memory leak. the leak is around 12k everytime i do aplay. if i get any underruns the leak is more than 12k the kernel version i am working is "Linux-2.6.32.17-davinci1". The codec driver is in alsa model. Could you please help to resolve this problem. Thanks in advance, Sreedhar.

1 1

Re: [alsa-devel] ALSA firewire kernel branch: snd_dice enhancements
by Rolf Anderegg 04 Nov '11

04 Nov '11

On 02.11.2011, at 21:19, Clemens Ladisch <clemens(a)ladisch.de> wrote: >> To get samplerate switching working via ALSA's driver API I have made >> a few changes, especially within the dice_hw_params callback method. >> Plus, I enhanced the rate constraints for the pcm settings. > > On the DICE, the playback and capture streams must use a common rate, so > I thought I'd avoid handling this in the driver and just use whatever > was configured. Isn't common rate for playback & capture stream often required? This could be guaranteed by adapting the pcm rate constraints when acquiring one or the other stream. > Do you have a requirement that the sample rate must be selected > automatically, instead of being configured with a control panel or with > a CLI tool like amixer? Yes, this is quite crucial as we are attempting a playback system without any local GUI/control panel/CLI interaction, using jackd as audio backend I/O plugin. E.g. starting jackd with jackd -d alsa -d hw1:0 -r <rate> should incorporate switching the samplerate automatically, as this is done with most alsa devices. Given that the ALSA driver API provides for such functionality (snd_xxx_hw_params & snd_xxx_prepare) I thought that such an objective was self-evident. I could think of several other usecases where this would be desired/required. Why _shouldn't_ the application which acquires the DICE device at least be able to dictate the initial samplerate and/or syncsource? What do you (and others) think? Any way we can reach a mutual consent on this? >> I hope that some of these enhancements will make it to your alsa-kernel branch, >> if not even to the 3.x kernel tree (is this being considered for the near future?). > > This branch will land in the kernel when it's reasonably complete. > The plan is for this kernel driver to replace FFADO's streaming > component. If this is the case it would appear that automatical samplerate switching, as is provided by FFADO, is a crucial requirement that should also be transferred to this new kernel driver. >> I noticed that amdtp_out_stream offers support for "dualwire" >> streaming at high rates, which is applied for dice's stream. Has this >> already been considered in FFADO? > > Not by anyone who understands the FFADO internals and has the time. Ok, I'll have a look at it. >> 2.) support DICE capture streams > > I'm working on this right now (modulo the amount of time available). Excellent, we're happy to serve as guinea pigs, whenever you're ready ;-) >> 3.) DICE clock source (CLOCK_SOURCE_*) selectable via ALSA driver API; how could >> this be done? > > If not done by a control panel, this could be done with a mixer control. > This is not yet implemented because any clock source except ARX* > requires synchronization from the capture stream. > >> I have changed the default clock source to INTERNAL, since I was >> experiencing "slips" with ARX1; as far as I know ARX1/2 is reasonably applicable >> only if there is another clock sync master on the Firewire bus. > > The timing of the stream from the computer to the DICE is synthesized > according to the rules in the AMDTP spec (I hope); this was originally > written for devices based on the OXFW970 chip. (It's synchronized to > the FireWire bus clock.) It's possible that DICE devices want to use > a different value for the transfer delay or some other timing parameter; > a stream whose timing is derived from another DICE's capture stream > would have whatever timing is required. > > ARX1 appears to work fine with my DesktopKonnekt6, but I've never looked > at the error counters. Right, hmm, having scanned the AMDTP (IEC 61883-6) in detail raises some confusion now. Up till now I was under the impression that using AVS-SYT as DICE's clock source is only an option to sync firewire bus slave devices to a clock master device on the same bus. After all, the DesktopKonnekt6 manual mentions that in standalone setup INTERNAL syncsource is selected per default and can not be altered. Citing from DICE's users guide (chapter 6: AVS (Audio Video System)): "[...] All nodes on a 1394 network must be synchronized to one clock called the cycle timer, which is determined by the master node on the network. One cycle of the master nodes‘ cycle timer defines a 1394 cycle. At the beginning of each 1394 cycle the master node transmits a clock sync signal that allows all nodes on the 1394 network to be synchronized to the cycle timer. This maintains synchronicity among all the 1394 nodes. Each 1394 node receives the clock sync signal and uses it to update or correct its local timer. However, this clock correction can cause the local timer to jump forward or backward as it is updated by the clock sync signal, which can reduce the performance of the system. The format of a quadlet of audio data passing through the AVS is configurable. The AVS can be configured to be transparent for 32-bit audio data. In this case the data will not be touched as it passes through the AVS. The AVS can also be configured to support the IEC61883-6 (AM824) steaming model. This allows the AVS to either source AM824 labels from another location, or build its own AM824 labels for the 24-bit data. The AVS can take the various label fields (block sync, user bits, channel status bits, etc) that make up each AM824 label, from different sources, and then pack them together into an AM824 label. [...]" Still confused... any enlightenment or recommendation, perhaps from TCAT, on this? Regards, Rolf

2 1

[alsa-devel] [PATCH 0/2] OMAP2+: DMA: fix src/dst position reporting
by Peter Ujfalusi 03 Nov '11

03 Nov '11

Hello, If the user asks for the sDMA current position before the first data has been transmitted (before the first DMA request has been generated), the reported position is not valid: src position: CSAC is uninitialized dst position: CDAC is 0 The return values in both case considered invalid. This sitation can be identified by checking if the CDAC register is 0 (it is initialized to 0 in omap_dam_start call). In this case return the programmed source/destination address. The affected omap_get_dma_src_pos/omap_get_dma_dst_pos functions are used by the audio stack mainly for checking the current position of the audio stream. Regards, Peter --- Peter Ujfalusi (2): OMAP2+: DMA: Workaround for invalid source position OMAP2+: DMA: Workaround for invalid destination position arch/arm/plat-omap/dma.c | 25 ++++++++++++++++++++++--- 1 files changed, 22 insertions(+), 3 deletions(-) -- 1.7.7.1

3 5

[alsa-devel] QasConfig 0.3 released
by Sebastian H. 03 Nov '11

03 Nov '11

QasConfig version 0.3 is now available. QasConfig is a browser for the ALSA configuration tree. Changes: * Changes in /etc/asound.conf or ~/.asoundrc trigger a refresh * Localizations moved to a separate package: qasconfig-l10n * Version code shortened to two numbers instead of three Homepage with more information http://xwmw.org/qasconfig Project page http://sourceforge.net/projects/qasconfig/ Happy configuration browsing! -- Sebastian Holtermann

1 0

[alsa-devel] QasMixer 0.15 released
by Sebastian H. 03 Nov '11

03 Nov '11

QasMixer version 0.15 is now available. QasMixer is an ALSA mixer with a size adaptive Qt GUI. Changes: * New simpler device selection view * New user setting: Mixer device on startup * ALSA configuration view moved to a separate application: QasConfig * Localizations moved to a separate package: qasmixer-l10n * Default fallback translation * Code merges and cleanups * Version code shortened to two numbers instead of three Homepage with more information http://xwmw.org/qasmixer Project page http://sourceforge.net/projects/qasmixer/ Happy volume changing! -- Sebastian Holtermann

1 0

[alsa-devel] ASoC and regmap trees have moved back to kernel.org
by Mark Brown 03 Nov '11

03 Nov '11

Hi Stephen, Please update my git trees in -next to use kernel.org again: ASoC: git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next regmap: git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git for-next Please leave the regulator tree where it is for now, Liam's kernel.org account will hopefully be being restored shortly so he can take that over again. Thanks, Mark

2 1

[alsa-devel] [PATCH] ASoC: Update git repository URL
by Mark Brown 02 Nov '11

02 Nov '11

Remove the -2.6 from the name. Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- MAINTAINERS | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index bbf42cd..63b58dd 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -6001,7 +6001,7 @@ F: sound/ SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEMENT (ASoC) M: Liam Girdwood <lrg(a)ti.com> M: Mark Brown <broonie(a)opensource.wolfsonmicro.com> -T: git git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound-2.6.git +T: git git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git L: alsa-devel(a)alsa-project.org (moderated for non-subscribers) W: http://alsa-project.org/main/index.php/ASoC S: Supported -- 1.7.7

1 0

[alsa-devel] ALSA firewire kernel branch: snd_dice enhancements
by Rolf Anderegg 02 Nov '11

02 Nov '11

Hi Clemens, hi Stefan, I recently stumbled upon your alsa-kernel branch (firewire-kernel-streaming: http://git.alsa-project.org/?p=alsa-kprivate.git;a=shortlog;h=firewire-kern…) and have finally found the time to play around with it. First of all I was impressed to see that it easily worked in conjunction with our DICE-based devices, even in high samplerate mode (>96kHz), provided that the clockselection of the DICE had been done beforehand via TCAT's drivers. To get samplerate switching working via ALSA's driver API I have made a few changes, especially within the dice_hw_params callback method. Plus, I enhanced the rate constraints for the pcm settings. You can find these changes in the attached patch (applicable to http://git.alsa-project.org/?p=alsa-kprivate.git;a=commit;h=f29bf150b7ba062…). I hope that some of these enhancements will make it to your alsa-kernel branch, if not even to the 3.x kernel tree (is this being considered for the near future?). I am happy to say that this solution will fit our needs for the time being, while we still have not given up on FFADO as a longterm alternative, provided it is stable at all rates. I noticed that amdtp_out_stream offers support for "dualwire" streaming at high rates, which is applied for dice's stream. Has this already been considered in FFADO? I wasn't able to pinpoint the appropriate entities within the FFADO sources yet. In order for snd_dice to make it upstream for generic DICE support there appear to remain a few minor issues: 1.) wait for NOTIFY_CLOCK_ACCEPTED notification bit after writing GLOBAL_CLOCK_SELECT within dice_hw_params. For the time being I introduced a "childish" msleep(500) in order for DICE to potentially switch its ratemode before starting the stream. I didn't quite figure out how to wait/poll for a particular notification. Do you have a hint how this would be done (using hwdep)? 2.) support DICE capture streams 3.) DICE clock source (CLOCK_SOURCE_*) selectable via ALSA driver API; how could this be done? I have changed the default clock source to INTERNAL, since I was experiencing "slips" with ARX1; as far as I know ARX1/2 is reasonably applicable only if there is another clock sync master on the Firewire bus. Thanks again for this cool branch and let us know whether we can be of further assistance. Cheers, Rolf Anderegg, Weiss Engineering Ltd.

2 1

[alsa-devel] Out of date email address for Jaroslav Kysela on wiki
by Andrew Eikum 02 Nov '11

02 Nov '11

I just sent a documentation patch to alsa-devel and received the following bounce. Looks like <perex(a)suse.cz> is no longer valid. Since the wiki page requests users wanting to work on ALSA docs should send an email to Jaroslav Kysela at that address, I had it in the To: field. I'm happy to update the wiki, but I'm not sure what the best address for Jaroslav is these days. Anyone? Andrew ----- Forwarded message from Mail Delivery System <Mailer-Daemon(a)mail.codeweavers.com> ----- Date: Wed, 02 Nov 2011 12:40:58 -0500 From: Mail Delivery System <Mailer-Daemon(a)mail.codeweavers.com> To: aeikum(a)codeweavers.com Subject: Mail delivery failed: returning message to sender This message was created automatically by mail delivery software. A message that you sent could not be delivered to one or more of its recipients. This is a permanent error. The following address(es) failed: perex(a)suse.cz SMTP error from remote mail server after RCPT TO:<perex(a)suse.cz>: host mx1.suse.de [195.135.220.2]: 550 <perex(a)suse.cz>: Recipient address rejected: User unknown in virtual alias table

2 2

[alsa-devel] [alsa-lib PATCH] Remove docs for snd_names_list and snd_names_list_free
by Andrew Eikum 02 Nov '11

02 Nov '11

"Deprecated," to me, doesn't necessarily imply "completely useless," especially if there are complete docs attached. To prevent future confusion, make it clear that these functions are now unimplemented. --- src/names.c | 13 ++----------- 1 files changed, 2 insertions(+), 11 deletions(-)

1 0