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

[alsa-devel] alsa-devel on vger
by Takashi Iwai 22 Nov '07

22 Nov '07

Hi, What about the plan to move alsa-devel to vger? Shouldn't we do that soon? Takashi

6 5

[alsa-devel] [PATCH 2/2] caiaq/NativeInstruments: control support
by Daniel Mack 21 Nov '07

21 Nov '07

Hi, This patch adds support for input controllers on "Kore controller" and uses ALSA's control API to enable LED switching on several hardware products as well as some internal audio related functions of "Audio 8 DJ". Subject: SOUND: caiaq - add control API and more input features From: Daniel Mack <daniel(a)caiaq.de> SOUND: caiaq - add control API and more input features - added support for all input controllers on Native Instrument's "Kore controller". - added ALSA controls to switch LEDs on "RigKontrol 2", "RigKontrol3", "Audio Kontrol 1" and "Kore controller". - added ALSA controls to switch input mode, software lock and ground lift features on "Audio 8 DJ". Signed-off-by: Daniel Mack <daniel(a)caiaq.de>

2 3

[alsa-devel] [PATCH 1/2] caiaq/NativeInstruments: input handling fixes
by Daniel Mack 21 Nov '07

21 Nov '07

Hi, I'm re-posting a patch from Dmitry Torokhov which cleans up some input layer related things. It hasn't made its way to any repository yet but my subsequent patch needs it as dependency. I Cc'ed Dmitry to avoid confusion. Subject: SOUND: caiaq - misc input handling fixes From: Dmitry Torokhov <dmitry.torokhov(a)gmail.com> SOUND: caiaq - misc input handling fixes - link input device with its parent so that it placed in proper spot in sysfs hierarchy - drivers that allow changing their keymaps should use private copy of the keymap so that one instance of a device does not affect another instance - it is preferred for drivers to properly set up input_dev->phys to help userspace locate devices - drivers should use usb_to_input_id(), or perform endianess conversion, themselves, otherwise ID is not correct on big-endian boxes - whitespace and formatting cleanup Signed-off-by: Dmitry Torokhov <dtor(a)mail.ru> Acked-by: Daniel Mack <daniel(a)caiaq.de>

3 5

[alsa-devel] ASoC merge
by Mark Brown 21 Nov '07

21 Nov '07

The following patch series merges some of the outstanding changes in the linux-2.6-asoc tree. It updates the core and existing drivers and adds some of the new drivers currently in the tree.

9 62

Re: [alsa-devel] Broken playback
by Clemens Ladisch 21 Nov '07

21 Nov '07

Gabriele Melia wrote: > > Try non-blocking mode (see the snd_pcm_nonblock function). In non- > > blocking mode, the writei call will only write as much data as can be > > written without waiting (or returns -EAGAIN if the buffer is already > > full at the moment). > > I'm already in this case Then the problem is not that the writei call takes too long. An underrun can happen only when your code takes too much time between two consecutive calls to writei. > How to set the buffer size of the circular buffer in which i store the > pcm that is then called by alsa? snd_pcm_hw_params_set_buffer_size_near(), but the allowed values are hardware dependent. You might want to add your own circular buffer that is bigger than ALSA's. HTH Clemens

1 0

Re: [alsa-devel] Broken playback
by Clemens Ladisch 21 Nov '07

21 Nov '07

Gabriele Melia wrote: > i have already tried to read and decode some data in order to accumulate > 1 second of data to prevent broken audio, > but nothing change, analysing the issue i have found that broken audio > comes when the snd_pcm_writei is called with a size that is 5000. So it > takes time to dispach all this size. Try non-blocking mode (see the snd_pcm_nonblock function). In non- blocking mode, the writei call will only write as much data as can be written without waiting (or returns -EAGAIN if the buffer is already full at the moment). HTH Clemens

1 0

[alsa-devel] Latency and timestamps
by Claudio Matsuoka 21 Nov '07

21 Nov '07

Hi, I'm adding latency control to an application and didn't find much documentation about the pcm status functions aside from a very brief description and the latency.c example. What exactly are the "trigger timestamp" and "now timestamp" returned by snd_pcm_status_get_trigger_tstamp() and snd_pcm_status_get_tstamp()? I collected both from my output pcm handle to find values (in tv_sec.tv_usec format) such as 1195518180.938427 938427.557702 1195518180.938441 938441.557702 1195518181.300395 300395.557702 1195518181.300441 300441.557702 where the "trigger" tv_sec matches the "now" tv_usec, and the "trigger" tv_usec varies in large steps. Also the example latency.c says: 00703 showinmax(in_max); 00704 if (p_tstamp.tv_sec == p_tstamp.tv_sec && 00705 p_tstamp.tv_usec == c_tstamp.tv_usec) 00706 printf("Hardware sync\n"); 00707 snd_pcm_drop(chandle); In line 704, shouldn't it be p_tstamp.tv_sec == c_tstamp.tv_sec? My final goal is to sync on-screen events with the sound output. I'd like to do something like storing output metadata associated with a certain timestamp and collecting it back based on the timestamp of the currently playing pcm data (like the OSS sequencer echoback events), is that possible, or is there a better way to do this?

3 6

[alsa-devel] latency issues
by paul blakeley 21 Nov '07

21 Nov '07

I am currently trying to measure the latency through my alsa application. I will briefly explain my application and set-up. The application has a test harness which sends audio data to my application. To measure the latency the test harness reads in a .wav file(one which I have generated. This contains a short pulse of a sine wave. The rest being zero data.) and also drives the serial port at the point were it detects the sine pulse. As previously explained the audio data is passed through my application and the alsa driver. The difference then between the start of the sine pulse and the output from the sound card is the latency through the system. I measure this with an oscilloscope. Also just to note the test harness is driven from the same sound card as the application, so there should be no difference clocks. Now that I have explained the test scenario, I will explain the behaviour that I am experiencing. To start off, starting the test harness at different instances revealed that the latency measurement is different by maybe 20ms or so, although the alsa buffer levels indicate all is correct. Once started the behaviour is such that the difference drifts ever so slightly. After around 10 minutes the output flips to the beginning and the process starts again. This happens continuously. Without establishing the cause of this problem will ultimately mean the measurement is useless. Could this issue be related to the serial port, alsa buffering, kernel scheduling etc. Can somebody with the relevant experience help. Please.

1 0

[alsa-devel] Broken playback
by Gabriele Melia 21 Nov '07

21 Nov '07

Hi All, i'm new so sorry in advance if i do any errors. I have integrated my hw decoder inside ffmpeg that is working fine, but while playing through alsa the sound comes broken in the sense that it is playing for 3 seconds, stops for 1 plays again for 3 sec and stop again and so on. How I can delay the palyback in order to accumulate some decoded buffers to prevent this and to not afflict the decoder when playback is stopping? Thanks, Gabriele _________________________________________________________________ Scarica GRATIS le emoticon della tua squadra del cuore e il calendario di serie A! http://www.emoticons-livemessenger.com/pages/msnitcalcio/index.htm

2 1

[alsa-devel] multi pcm and mmap problem
by terminator356＠users.sourceforge.net 21 Nov '07

21 Nov '07

After 2 years I've finally traced and fixed a problem which was preventing me from using anything after ALSA 1.0.9b ! In ALSA lib 1.0.9b: pcm/pcm_generic.c: int snd_pcm_generic_channel_info() { snd_pcm_generic_t *generic = pcm->private_data; return snd_pcm_channel_info(generic->slave, info); } But in ALSA lib 1.0.15: pcm/pcm_generic.c: int snd_pcm_generic_channel_info() { snd_pcm_generic_t *generic = pcm->private_data; if (pcm->mmap_shadow) { /* No own buffer is required - the plugin won't change * the data on the buffer, or do safely on-the-place * conversion */ return snd_pcm_channel_info(generic->slave, info); } else { // Tim: TESTED: This is now called instead of the other one! /* Allocate own buffer */ return snd_pcm_channel_info_shm(pcm, info, -1); } } My multi PCM consists of a plughw:0,2 and a hw:1,0 In ALSA 1.0.9b, all five PCMs ALSA creates for this arrangement create their areas with mmap(). And it works. But in ALSA 1.0.15 my hw:1,0 and its multi PCM areas are created with mmap(), and my plughw:0,2 and its PCMs areas are created with malloc(). Can't hear/record any sound from the plughw:0,2 part of the multi. I have verified that ALSA 1.0.15 is copying the plughw:0,2 HW PCM areas to its LINEAR PCM areas, but NOT finally to its multi PCM areas. It just copies all zeros. That's the reason I hear/record no sound from the plughw:0,2 part of the multi PCM. So I reverted the function's code back to 1.0.9b and presto! It works now, the same as in ALSA 1.0.9b So please tell me, am I missing something? Should I add something more to my .asoundrc ? I see that besides {type multi ... }, there is a {type share ...} defined. *** Does the 'share' have any use here? Can't find any docs on it. Also: Yes, I can see now, why you made this code change. mmap() has limits, so you switched over to malloc(). Those limits force the user to use small buffers and/or reduce the number of channels created. Otherwise aplay, arecord, and jack etc complain mmap() failed. In ALSA 1.0.9b, and after my change to ALSA 1.0.15, I tried ulimit() -l, and editing /etc/security/limits.conf I quadrupled the available locked memory, but aplay, arecord etc still won't let me increase the buffer size beyond what it was BEFORE I edited limits.conf *** What am I doing wrong? Thanks Tim.

2 1