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

Re: [alsa-devel] MOTU development
by Jonathan Woithe 29 Jun '07

29 Jun '07

Hi Per > I'd like to know more about the health on the connections to MOTU, if > they give any information about their products and how the development > has proceeded over the years. It kind of depends which MOTU devices you're asking about. There is, for example, an alsa driver for the MOTU Midi Timepiece AV (MTPAV) which presumedly makes the midi side of this available via the ALSA sequencer system. I can't speak for any of MOTU's PCI/PCIe cards. However, in connection with their more recent outboard interfaces MOTU have been, to put it mildly, extremely unhelpful. Some on the net go so far as to say they are hostile to Linux. The facts are that despite multiple people requesting information from MOTU on how to drive their firewire interfaces MOTU have responded every time with a very terse non-negotiable "no, never". I don't know if anyone's ever asked about their USB-equipped devices but I can't imagine the answer would be any different. Despite this, some progress is being made in supporting MOTU firewire devices under linux. For various reasons this support is not through ALSA but instead as part of the FFADO project. FFADO provides a userspace library for driving firewire audio devices in general and a JACK backend allowing such devices to be used by any jack-enabled software. An ALSA backend is planned but no work has been done towards this yet. Check out www.ffado.org for information on this project. Device support in FFADO varies. Some interfaces for which we have vendor support are doing very well, while supporting an interface such as the MOTUs without any documentation is challenging. However, the MOTU control protocol is pretty well understood at this point in time and it is possible to actually use the MOTU firewire devices for real work under Linux (as I have been for about 9 months now). The trap is that one needs to use an earlier revision of ffado at present. Back in February some key FFADO infrastructure changed. From before that until the last week or so I've been busy with production projects and so haven't had a chance to update the MOTU FFADO driver and restore its functionality. I'm back on the case now though and hope to make progress in the next month or so. If you want further details about all this please contact me off-list and I'll fill you in. Best regards jonathan

1 0

[alsa-devel] ALSA Application Programming Questions
by Paul Kavan 28 Jun '07

28 Jun '07

Hello all: I have been working on getting ALSA to work on my at91sam9260 with a simple voice codec for a few weeks. For the most part, I have my ARM board producing nice audio with aplay/arecord. Now I need a custom application that will allow me to create an 'intercom' like device with my ARM board. I am planning on writing the application as I do not think there is something out there that will accomplish what I want. I am really new to ALSA--as some of you know--and, as such, have never written an application for ALSA. I have found the ALSA driver api page on the alsa site. Wondering if there is any other good documentation on writing alsa applications? Any advice is greatly appreciated as well. One of my concerns is building the applications against the libs. I have the libs on my target machine. As my host machine has a version of my rfs on it, the libs are there as well. Just wondering how to accomplish cross-compiling new apps. I suppose I could copy the libs into the directory with my cross-compiling tools. Again, any advice would be great. Thanks. Paul -- *************************************** Paul David Kavan Project Engineer GRH Electronics, Inc. 402-734-4900 pkavan(a)gmail.com ***************************************

1 0

[alsa-devel] sound on SMDK2410 working
by Jose Henrique Spahn Torres 28 Jun '07

28 Jun '07

Hi all, I was able to get sound on smdk2410 to work. I can play .wav files with the following asound.conf file: /etc $ more asound.conf pcm.!default { type hw card 0 } ctl.!default { type hw card 0 } However the sound is distorted, in the sense that it sounds as played with a lower rate. I tried force a rate with -r 44100 or other rates, with no success. Can anyone point me to the right direction? Thanks, Henrique

1 0

[alsa-devel] SALSA-Lib: snd_pcm_hw_params_any clobbers memory
by J. Scott Merritt 28 Jun '07

28 Jun '07

Dear list, Using SALSA-Lib 0.0.2, I call snd_pcm_open snd_pcm_hw_params_malloc snd_pcm_hw_params_any The call to snd_pcm_hw_params_any appears to clobber memory beyond the end of the hw_params allocated by snd_pcm_hw_params_malloc (as reported by linking in -lmcheck). The code is being cross-compiled and tested on an ARM processor (PXA270) which is running linux kernel 2.6.21. This same code sequence -does- operate properly (in the same ARM test environment) when compiled against AlsaLib 1.0.13. I got "lost" somewhere around the hw_refine IOCTL .... Any suggestions appreciated :) Thanks, Scott.

2 2

[alsa-devel] MOTU development
by Per Eriksson 28 Jun '07

28 Jun '07

Dear list, My name is Per Eriksson, working as a musician with music and interactive content in Sweden. I'd like to know more about the health on the connections to MOTU, if they give any information about their products and how the development has proceeded over the years. I am thankful for any input. Best Regards Per Eriksson per(a)erinet.se

1 0

Re: [alsa-devel] [Pkg-alsa-devel] Bug#430833: libasound2: PCM plugin `lfloat' not built
by Elimar Riesebieter 28 Jun '07

28 Jun '07

forwarded 430833 alsa-devel(a)alsa-project.org -- On Wed, 27 Jun 2007 the mental interface of Mark Wooding told: > Package: libasound2 > Version: 1.0.14a-1 > Severity: normal > Tags: patch > > The PCM plugin `lfloat' isn't compiled into libasound. In particular, > this prevents the `plug' plugin from doing linear<->float conversion, > and in turn this means that hardly any ALSA clients can use the JACK > plugin from libasound2-plugins, because JACK uses FLOAT_LE format > throughout. > > The reason for this is quite simple: the configure script is broken! In > particular, the sense of the `softfloat' check used to decide whether to > disable the plugin is wrong! (That's aside from the question of whether > it's sensible to fail to build the thing just because it might be slow.) > We should solve this in general. It's not a Debian specific wish so forwarded upstream. > > Index: alsa-lib-1.0.14a/configure.in > =================================================================== > --- alsa-lib-1.0.14a.orig/configure.in 2007-06-27 16:24:58.000000000 > +0100 > +++ alsa-lib-1.0.14a/configure.in 2007-06-27 16:25:19.000000000 > +0100 > @@ -416,7 +416,7 @@ > build_pcm_share="no" > fi > > -if test "$softfloat" != "yes"; then > +if test "$softfloat" = "yes"; then > build_pcm_lfloat="no" > fi > > Index: alsa-lib-1.0.14a/configure > =================================================================== > --- alsa-lib-1.0.14a.orig/configure 2007-06-27 16:25:23.000000000 > +0100 > +++ alsa-lib-1.0.14a/configure 2007-06-27 16:25:38.000000000 +0100 > @@ -20946,7 +20946,7 @@ > build_pcm_share="no" > fi > > -if test "$softfloat" != "yes"; then > +if test "$softfloat" = "yes"; then > build_pcm_lfloat="no" > fi > > Elimar -- Experience is something you don't get until just after you need it!

2 1

[alsa-devel] Sound disappears after a long run, pcm_rate plugin maybe
by Dave Airlie 28 Jun '07

28 Jun '07

Hi, I've been debugging this bug which I first noticed close to a year ago but worked around by disabling dmix. Now I've had to enable dmix and try and fix it. My system is SDL on alsa-lib-1.0.13 on 2.6.21 on intel 810 with a Realtek ALC655. I'm using SDL to open a 22050 16-bit stereo stream, and dmix is set to 48000. When I run sound in my single app (only one app running for testing purposes) around 20-24 hours later (I haven't got exact timings as I can't sit in front of the pc for so long) the sound stop s happening just in that app. I can run aplay separately and it plays fine. If I stop my app (ctrl-C and cont in gdb) or attach/detach strace, I get an XRUN and my SDL code calls snd_pcm_prepare and the sounds comes back. Now I can't tell you how much it sucks to only get a single debugging run every 24 hours for 1 break point and if gdb stuffs it up you lose big time. I think I've tracked it down to pcm_rate.c as in if I open the sound card at 48000 instead of 22050 it doesn't happen and I've added a lot of printfs to the rate code in 1.0.13 and gotten huge log file traces of it.. In a normal rate trace when things are working I get traces like this: snd_pcm_rate_sync_playback_area: 442023720 442023720 525 986185728 snd_pcm_rate_sync_playback_area: 442023720 442023720 1549 986185728 snd_pcm_rate_sync_playback_area: 442023720 442023720 1549 986185728 snd_pcm_rate_sync_playback_area: 442024660 442023720 1549 986185728 snd_pcm_rate_commit_area: 6 940 1024 1881 snd_pcm_rate_sync_playback_area: 940 442023720 1881 snd_pcm_rate_sync_playback_area: 442024660 442024660 525 986185728 snd_pcm_rate_sync_playback_area: 442024660 442024660 1549 986185728 snd_pcm_rate_sync_playback_area: 442024660 442024660 1549 986185728 snd_pcm_rate_sync_playback_area: 442025595 442024660 1549 986185728 snd_pcm_rate_sync_playback_area: 442025600 442024660 1549 986185728 snd_pcm_rate_commit_area: 946 940 1024 1881 snd_pcm_rate_sync_playback_area: 940 442024660 1881 snd_pcm_rate_sync_playback_area: 442025600 442025600 525 986185728 snd_pcm_rate_sync_playback_area: 442025600 442025600 1549 986185728 snd_pcm_rate_sync_playback_area: 442025600 442025600 1549 986185728 snd_pcm_rate_sync_playback_area: 442026540 442025600 1549 986185728 snd_pcm_rate_commit_area: 5 940 1024 1881 snd_pcm_rate_sync_playback_area: 940 442025600 1881 snd_pcm_rate_sync_playback_area: 442026540 442026540 525 986185728 snd_pcm_rate_sync_playback_area: 442026540 442026540 1549 986185728 snd_pcm_rate_sync_playback_area: 442026540 442026540 1549 986185728 snd_pcm_rate_sync_playback_area: 442027476 442026540 1549 986185728 snd_pcm_rate_sync_playback_area: 442027480 442026540 1549 986185728 playback are debug code slave_size = snd_pcm_avail_update(slave); if (slave_size < 0) return slave_size; fprintf(stderr,"%s: %u %d %u %u\n", __func__, appl_ptr, rate->last_commit_ptr, slave_size, pcm->boundary); if (appl_ptr < rate->last_commit_ptr) xfer = appl_ptr - rate->last_commit_ptr + pcm->boundary; else xfer = appl_ptr - rate->last_commit_ptr; while (xfer >= pcm->period_size && (snd_pcm_uframes_t)slave_size >= rate->gen.slave->period_size) { err = snd_pcm_rate_commit_next_period(pcm, rate->last_commit_ptr % pcm->buffer_size); fprintf(stderr, "%s: %u %u %u\n", __func__, xfer, rate->last_commit_ptr, pcm->buffer_size); if (err == 0) commit area debug fprintf(stderr,"%s: %u %u %u %u\n", __func__, appl_offset, size, slave_size, pcm->buffer_size); areas = snd_pcm_mmap_areas(pcm); if (cont >= size) { In the not so good case (with different debug - two sites and I hadn't access to my debug code from one so I wrote it again) you get large numbers of snd_pcm_rate_sync_playback_area: 152605942 912 152385750 snd_pcm_rate_sync_playback_area: 152605942 912 152385750 snd_pcm_rate_sync_playback_area: 152606412 912 152385750 snd_pcm_rate_sync_playback_area: 152606412 912 152385750 snd_pcm_rate_sync_playback_area: 152606705 912 152385750 snd_pcm_rate_sync_playback_area: 152606882 912 152385750 snd_pcm_rate_sync_playback_area: 152606882 912 152385750 snd_pcm_rate_sync_playback_area: 152607352 912 152385750 snd_pcm_rate_sync_playback_area: 152607352 912 152385750 ...... snd_pcm_rate_sync_playback_area: 152769972 912 152385750 snd_pcm_rate_sync_playback_area: 152770381 1936 152385750 snd_pcm_rate_commit_area: 1411 572 470 snd_pcm_rate_sync_playback_area: 384631 1 1936 152385750 739770368 snd_pcm_rate_sync_playback_area: 152770442 912 152386220 .... more of these.... snd_pcm_rate_sync_playback_area: 152910502 912 152386220 snd_pcm_rate_sync_playback_area: 152910502 912 152386220 snd_pcm_rate_sync_playback_area: 152910972 912 152386220 snd_pcm_rate_sync_playback_area: 152910972 912 152386220 appl ptr is 152910972 recalc: 3022344724 1411 3072 470 1024 snd_pcm_rate_sync_playback_area: 152910972 1936 152386220 snd_pcm_rate_commit_area: 1411 1042 470 snd_pcm_rate_sync_playback_area: 524752 1 1936 152386220 739770368 snd_pcm_rate_sync_playback_area: 152910972 1936 152386690 snd_pcm_rate_commit_area: 1411 101 470 snd_pcm_rate_sync_playback_area: 524282 1 1936 152386690 739770368 snd_pcm_rate_sync_playback_area: 152910972 1936 152387160 ... this pattern repeats one commit per two playbacks until it goes back in the top... the debug code for these are recalc: fprintf(stderr,"%s: %lu %lu %lu %lu %lu\n", __func__, val, pcm->buffer_size, slave->buffer_size, pcm->period_size, slave->period_size); commit area areas = snd_pcm_mmap_areas(pcm); fprintf(stderr,"%s: %u %u %u\n", __func__, pcm->buffer_size, appl_offset, size); if (cont >= size) { playback area: fprintf(stderr,"%s: %u %d %d\n", __func__, appl_ptr, slave_size, rate->last_commit_ptr); if (appl_ptr < rate->last_commit_ptr) xfer = appl_ptr - rate->last_commit_ptr + pcm->boundary; else xfer = appl_ptr - rate->last_commit_ptr; while (xfer >= pcm->period_size && (snd_pcm_uframes_t)slave_size >= rate->gen.slave->period_size) { err = snd_pcm_rate_commit_next_period(pcm, rate->last_commit_ptr % pcm->buffer_size); fprintf(stderr,"%s: %u %d %d %u %u\n", __func__, xfer, err, slave_size, rate->last_commit_ptr, pcm->boundary); I'm hoping it is just some calculation in the rate plugin overflowing and I was blaming SDL but I've fixed up the codepaths to look like aplay and it still happened.. any hints would be appreciated on a) what that rate code is actually doing in the fail case, b) what the rate code is doing in the non-fail case :-) Dave.

2 1

[alsa-devel] SoC multiple streams
by Steve Longerbeam 28 Jun '07

28 Jun '07

Hi all, I'm developing an SoC driver for a sound engine that supports playing up to 64 simultaneous substreams, all mixed in h/w to a stereo DAC. But it doesn't appear that the SoC framework supports multiple substreams, according to soc_new_pcm(). Am I missing something, or is this on the asoc development roadmap? Thanks, Steve

3 3

[alsa-devel] SoC Machine Code Suggestions
by Paul Kavan 27 Jun '07

27 Jun '07

First, thanks to all for helping me get the at91 soc stuff working with my board and codec. It now plays telecom quality audio using aplay and records it as well using arecord. For those who were following my trials and did not hear what the solution was, essentially, when the at91-ssc code goes into playback mode, it only activates the TX side of the SSC (PCM) bus. Similarly, when it is in capture mode, it only activates the RX side of the bus. This certainly makes sense and works in most situations I am sure. However, I needed both the RX and TX frames operating in both playback and capture. As such, I had to modify at91-ssc slightly to accomplish this. Now that I have decent audio, I want to clean up around the edges of the audio and determine the best way to proceed with my application code. First. when the pcm interface starts/stops, I get a pop that comes from the codec analog output transitioning some. Now, there may be some hardware fixes to this, but what I would like to do it mute the amp until the last possible second before audio is played. I can accomplish this with a simple gpio call, but am not sure where best to turn the mute on and off. Any suggestions with that would be appreciated. Also, my next phase of development is to determine whether I need to write my own application to accomplish what I want to do, or if there is an application out there that will do the trick--and that I can cross-compile to an ARM. What I would like is an application I will stream audio (half-duplex) between two ARM boards connected via ethernet. I would need to be able to control the start/stop of the audio. Sometimes this control will depend on the state of the machine and other times it will be activate with a button press by the user. I hope that makes sense. Obviously it would have to seamlessly stream to the codec via ALSA. Also, there may be times when it streams to a pc. Now, the codec uses 8-bit ulaw, so this code if it were on a pc, would need to be able to play that on the pc in its native state or some type of conversion on the fly. I guess you can think of the application as similar to voip, but half duplex instead of full duplex. Does anyone know if something like this exists that I might use. If not, how hard would it be to code this for ALSA? Thanks again and I look forward to your responses. Paul -- *************************************** Paul David Kavan Project Engineer GRH Electronics, Inc. 402-734-4900 pkavan(a)gmail.com ***************************************

2 2

Re: [alsa-devel] SALSA-Lib version 0.0.1 release
by Takashi Iwai 27 Jun '07

27 Jun '07

At Mon, 25 Jun 2007 23:32:39 +0100, Adrian McMenamin wrote: > > > You can check ldd to the app which shlib it's linked with. > > It should be linked with libsalsa, not libasound. > > > > > > Takashi > > > > I expect I am being a bit thick here but what app? I use mpg123 and > it's not linked with any alsa libs. > > / # ldd ./mpg123 > libm.so.0 => /lib/libm.so.0 (0x2956d000) > libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x2958b000) > libc.so.0 => /lib/libc.so.0 (0x295aa000) > ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0x29558000) mpg123 is an OSS app. > / # ldd aplay > libasound.so.2 => /usr/lib/libasound.so.2 (0x2956d000) > libm.so.0 => /lib/libm.so.0 (0x29652000) > libdl.so.0 => /lib/libdl.so.0 (0x29670000) > libpthread.so.0 => /lib/libpthread.so.0 (0x29683000) > libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x296a4000) > libc.so.0 => /lib/libc.so.0 (0x296c3000) > ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0x29558000) It's liekly linked with the old libasound. SALSA-lib is a source-level compatible library and it's _not_ binary-level compatible. Thus, it's no drop-in replacement. After installing salsa-lib (better use --enable-everything option to make a libasound symlink), then you'll have to rebuild the other apps linked with alsa-lib again. Takashi

1 0