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

[alsa-devel] XRUN happens too often.
by Rong-Jhe 10 Apr '08

10 Apr '08

I use "default" pcm and open it in block mode. Then, I set the this pcm to perform 16-bit, two channels, and 44100 bps sampling rate audio data. The number of periods per buffer is 10. The follows are the parameters that I read from the pcm. sampling rate = 44100 bps period time = 21333 us period size = 940 frames buffer time = 213330 us buffer size = 9408 frames A sample in 16-bit, two channels is 4 bytes. I allocate a audio data of 9408x4=37632 bytes. audio_data=malloc(buffer_size*4); This audio_data buffer will receive audio data from the network. If this buffer is full, I use snd_pcm_writei( ) to put the buffer into the pcm. snd_pcm_sframes_t frames; snd_pcm_t *handle; while((frame=snd_pcm_writei(handle, audio_data, buffer_size))<0) { if(frames==-EPIPE) snd_pcm_prepare(handle); else printf("snd_pcm_writei error %d\n", frames); } The codes states that I put the entire buffer into the pcm at each time. The pcm use 10 periods to perform this buffer. The program can work normally. If the sampling rate is changed, the program will encounter XRUN frequently. The follows are the parameters that I read from the pcm after setting sampling rate to 48000. sampling rate = 48000 bps period time = 21333 us period size = 1024 frames buffer time = 213330 us buffer size = 10240 frames audio_data=malloc(buffer_size*4); //10240x4=40960 I also put the entire buffer into the pcm at each time, but snd_pcm_writei( ) will return -PIPE frequently. What is the problem?

5 12

[alsa-devel] M-Audio Fast Track Ultra USB
by knoxit.etc＠gmail.com 10 Apr '08

10 Apr '08

Hello, I was wondering if any user had experiences with the M-Audio Fast Track Ultra USB unit and ALSA. I'm not sure if its supported, it doesn't show up on the soundcard matrix. If not, is there any development taking place right now? Thanks.

2 1

[alsa-devel] [PATCH] snd_usb_caiaq: correct input channel order
by Daniel Mack 09 Apr '08

09 Apr '08

This patch corrects the input channel order of hardware supported by snd_usb_caiaq. Signed-off-by: Daniel Mack <daniel(a)caiaq.de>

1 0

[alsa-devel] HDSP maintainer
by Florian Faber 07 Apr '08

07 Apr '08

Hi there, is there a current maintainer for the RME drivers? I have several patches and additions for the hdsp driver and the user space applications, and there will be much more coming. Flo -- Machines can do the work, so people have time to think. public key 6C002249 x-hkp://wwwkeys.eu.pgp.net

1 0

[alsa-devel] Sound card question.
by Tobin Davis 07 Apr '08

07 Apr '08

Are there any alsa supported sound cards that do hardware audio decoding for MP3/WMA and otehr formats? I'd like to look at the mechanism used to connect the cards to the data stream. Also, is there any block diagrams I can look at for the AOA and SOC drivers? Particularly the I2S bus support. I'm ramping up support for a new project that will be Alsa based, and would like to combine it with already established APIs if possible. -- Tobin Davis The relative importance of files depends on their cost in terms of the human effort needed to regenerate them. -- T.A. Dolotta

3 2

[alsa-devel] which fonction ?
by Dsant 07 Apr '08

07 Apr '08

I would like to implement this, but I don't know which fonction to use : LOOP START begin acquire some long stuf... (about 1-2 seconds) copy buffer to ram or into file LOOP END Dsant

2 1

[alsa-devel] Is there a list of alsa error codes?
by Wolfgang Woehl 06 Apr '08

06 Apr '08

Hi, For the life of me I can't find a list of alsa error codes in order to understand what, in this case, "sound/usb/usbaudio.c:352: frame 0 active: -18" means. A hint, anyone? Wolfgang

1 0

[alsa-devel] Loop sequencer
by Guillaume Dupré 06 Apr '08

06 Apr '08

Hello I try to program a loop midi sequencer with libasound . For the moment, I have this : #include <alsa/asoundlib.h> #include <unistd.h> using namespace std; int main() { int aa; snd_seq_t* seq; int port,port2, queue; snd_seq_queue_tempo_t* tempo; snd_seq_event_t ev; snd_seq_open(&seq, "default", SND_SEQ_OPEN_DUPLEX, 0); snd_seq_set_client_name(seq, "monprog"); port = snd_seq_create_simple_port(seq, "port1",SND_SEQ_PORT_CAP_READ | SND_SEQ_PORT_CAP_SUBS_READ,SND_SEQ_PORT_TYPE_APPLICATION); queue = snd_seq_alloc_queue(seq); //TEMPO snd_seq_queue_tempo_alloca(&tempo); snd_seq_queue_tempo_set_tempo(tempo, 60000000 / 120); snd_seq_queue_tempo_set_ppq(tempo, 4); snd_seq_set_queue_tempo(seq, queue, tempo); snd_seq_connect_to(seq, port, 130, 0); snd_seq_start_queue(seq, queue, NULL); // write 2 notes snd_seq_ev_clear(&ev); snd_seq_ev_set_subs(&ev); snd_seq_ev_set_source(&ev, port); snd_seq_ev_schedule_tick(&ev, queue, 0, 0); snd_seq_ev_set_note(&ev, 0, 60, 127, 3); snd_seq_event_output(seq, &ev); ev.time.tick = 4; ev.data.note.note = 67; snd_seq_event_output(seq, &ev); snd_seq_drain_output(seq); sleep(4) ; return 0; } It works, no problem . But now, I want to do a loop with my two notes . I searched on the Internet but I didn't find . Thanks Guillaume Dupré

2 1

Re: [alsa-devel] 2.6.25-rc8-mm1 -- INFO: possible circular locking dependency detected (while using iw to debug a wireless issue)
by Johannes Berg 04 Apr '08

04 Apr '08

On Thu, 2008-04-03 at 10:41 -0400, Miles Lane wrote: > After collecting the wireshark log, I found this in my messages log: Below is a better version of the trace Miles sent me privately, but I have no idea what would be causing it. I don't think it's related to wireless. ======================================================= [ INFO: possible circular locking dependency detected ] 2.6.25-rc8-mm1 #15 ------------------------------------------------------- iw/9417 is trying to acquire lock: (genl_mutex){--..}, at: [ctrl_dumpfamily+0x37/0xda] ctrl_dumpfamily+0x37/0xda but task is already holding lock: (nlk->cb_mutex){--..}, at: [netlink_dump+0x39/0x22e] netlink_dump+0x39/0x22e which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (nlk->cb_mutex){--..}: [__lock_acquire+0xa02/0xbaf] __lock_acquire+0xa02/0xbaf [lock_acquire+0x76/0x9d] lock_acquire+0x76/0x9d [snd_mixer_oss:mutex_lock_nested+0xd5/0x67b] mutex_lock_nested+0xd5/0x274 [netlink_dump_start+0xbd/0x15a] netlink_dump_start+0xbd/0x15a [genl_rcv_msg+0x9d/0x13a] genl_rcv_msg+0x9d/0x13a [netlink_rcv_skb+0x30/0x75] netlink_rcv_skb+0x30/0x75 [genl_rcv+0x1e/0x2e] genl_rcv+0x1e/0x2e [cfg80211:netlink_unicast+0x1c1/0x1867] netlink_unicast+0x1c1/0x293 [netlink_sendmsg+0x21f/0x22c] netlink_sendmsg+0x21f/0x22c [sock_sendmsg+0xca/0xe1] sock_sendmsg+0xca/0xe1 [sys_sendmsg+0x14d/0x1a8] sys_sendmsg+0x14d/0x1a8 [sys_socketcall+0x163/0x17e] sys_socketcall+0x163/0x17e [sysenter_past_esp+0x6d/0xc5] sysenter_past_esp+0x6d/0xc5 [<ffffffff>] 0xffffffff -> #0 (genl_mutex){--..}: [__lock_acquire+0x929/0xbaf] __lock_acquire+0x929/0xbaf [lock_acquire+0x76/0x9d] lock_acquire+0x76/0x9d [snd_mixer_oss:mutex_lock_nested+0xd5/0x67b] mutex_lock_nested+0xd5/0x274 [ctrl_dumpfamily+0x37/0xda] ctrl_dumpfamily+0x37/0xda [netlink_dump+0x51/0x22e] netlink_dump+0x51/0x22e [netlink_recvmsg+0x156/0x203] netlink_recvmsg+0x156/0x203 [sock_recvmsg+0xd1/0xe9] sock_recvmsg+0xd1/0xe9 [sys_recvmsg+0xf2/0x17f] sys_recvmsg+0xf2/0x17f [sys_socketcall+0x16f/0x17e] sys_socketcall+0x16f/0x17e [sysenter_past_esp+0x6d/0xc5] sysenter_past_esp+0x6d/0xc5 [<ffffffff>] 0xffffffff other info that might help us debug this: 1 lock held by iw/9417: #0: (nlk->cb_mutex){--..}, at: [netlink_dump+0x39/0x22e] netlink_dump+0x39/0x22e stack backtrace: Pid: 9417, comm: iw Not tainted 2.6.25-rc8-mm1 #15 [print_circular_bug_tail+0x5b/0x66] print_circular_bug_tail+0x5b/0x66 [print_circular_bug_header+0xa5/0xb0] ? print_circular_bug_header+0xa5/0xb0 [__lock_acquire+0x929/0xbaf] __lock_acquire+0x929/0xbaf [lock_acquire+0x76/0x9d] lock_acquire+0x76/0x9d [ctrl_dumpfamily+0x37/0xda] ? ctrl_dumpfamily+0x37/0xda [snd_mixer_oss:mutex_lock_nested+0xd5/0x67b] mutex_lock_nested+0xd5/0x274 [ctrl_dumpfamily+0x37/0xda] ? ctrl_dumpfamily+0x37/0xda [ctrl_dumpfamily+0x37/0xda] ? ctrl_dumpfamily+0x37/0xda [ctrl_dumpfamily+0x37/0xda] ctrl_dumpfamily+0x37/0xda [netlink_dump+0x51/0x22e] netlink_dump+0x51/0x22e [mac80211:kfree_skb+0x40/0x45] ? kfree_skb+0x40/0x45 [netlink_recvmsg+0x156/0x203] netlink_recvmsg+0x156/0x203 [sock_sendmsg+0xca/0xe1] ? sock_sendmsg+0xca/0xe1 [sock_recvmsg+0xd1/0xe9] sock_recvmsg+0xd1/0xe9 [<c01313d9>] ? autoremove_wake_function+0x0/0x30 [snd_pcm_oss:copy_from_user+0x3b/0x236] ? copy_from_user+0x3b/0x5e [verify_iovec+0x40/0x70] ? verify_iovec+0x40/0x70 [sys_recvmsg+0xf2/0x17f] sys_recvmsg+0xf2/0x17f [snd_hda_intel:_spin_unlock_irqrestore+0x56/0x6c] ? _spin_unlock_irqrestore+0x56/0x6c [paravirt_get_lazy_mode+0xe/0x1b] ? paravirt_get_lazy_mode+0xe/0x1b [crypto_algapi:kunmap_atomic+0x9e/0x2e8e] ? kunmap_atomic+0x9e/0xbb [handle_mm_fault+0x7aa/0x7bb] ? handle_mm_fault+0x7aa/0x7bb [sys_socketcall+0x16f/0x17e] sys_socketcall+0x16f/0x17e [processor:trace_hardirqs_on+0xf0/0x5d38] ? trace_hardirqs_on+0xf0/0x12c [sysenter_past_esp+0x6d/0xc5] sysenter_past_esp+0x6d/0xc5

4 3

[alsa-devel] Edirol M-16 DX
by James Trevelyan 04 Apr '08

04 Apr '08

I recently bought an Edirol M-16DX and am trying to get it working with Linux. I'm almost there but would appreciate some help in getting it over the line. The M-16DX (http://www.rolandus.com/products/productdetails.aspx?ObjectId=860&ParentId= 114) is a fairly new and pretty neat piece of kit - it works as a standalone 16-channel hardware mixer, with a USB2.0 connection which can send each separate input to the computer, with the ability also to send a stereo stream back to the mixer. In addition it can be put in a DAW controller mode where it acts a control surface with almost all the mixer knobs usable. It's set up as a vendor specific device so at first nothing happens when the usb cable connected. The usb configuration has three interfaces, like some of the other Edirol devices. So I put a new quirk in usbquirks.h for the appropriate device id, with a QUIRK_AUDIO_STANDARD_INTERFACE on interfaces 1 and 2, and a QUIRK_MIDI_FIXED_ENDPOINT on interface 3. Accodring to lsusb -v, each interface provides what looks like a proper class-specific descriptor. Having recompiled, the system now detects the device and loads the usb-audio module when the device is plugged in. It successfully creates alsa devices for capture and playback, as well as midi, with the correct sample rate (44.1, 48 or 96 as set on the device), correct number of channels (18 in and 2 out). All looks as it should. When I aplay an audio file to the device, it plays fine - almost. Everything sounds good, except that every 9-10 seconds, there is a kind of nasty high pitched digital distortion which lasts for a second. (definitely not in the audio file!) This seems to be synchronised to the start of the stream - when I aplay a file, it opens a new stream and the distortion is always in the same places in the song. If I open the ports on jack so the stream stays open, and play music through it on ardour, the distortion is at different points in the song (always about 9-10 seconds apart). I haven't tried capture yet. It all runs fine under windows in the same configuration. I'm at a bit of a loss as to the problem here - perhaps there is something wrong with the detection, and I haven't yet tried creating an AUDIO_FIXED_ENDPOINT quirk to play with the settings manually. But I would have thought in that case it just wouldn't work at all. I know the sample rate and # channels is correct. My system's pretty up to date (2.6.24.3 kernel, alsa-libs 1.0.16). I can provide full lsusb and /proc/asound information as necessary. Suggestions welcome! James

1 0